Boost logo

Boost :

From: Brian Braatz (brianb_at_[hidden])
Date: 2004-09-23 13:13:26


> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Noah Stein
 [Brian Braatz] (Snip)_
> > Yes..As I have touched in in a previous post this should be
accessible
> at
> > the 'device layer'. OTOH Another way to look at a pixel is as a
> > rectangular
> > box that is *currently*, *on this device*, (say) 0.25 mm wide and
0.25
> mm
> > high or whatever, the next layer up.
>
> What does "accessible at the device layer" mean in this context? A
pixel
> is
> a fundamental unit in any graphics context. I don't think that an
> application programmer should be forced to jump through hoops to get
at
> it.
>
[Brian Braatz]
I have been watching this one for a bit now and it is time for me to
weigh in.

I have 2 perspectives to share:

** Encapsulation of common functionality in UI frameworks***

I am working on a framework that sits on top of boost for the purpose of
making Thick Client DB apps. One of the things that I am going to be
needing is a *light* layer over the various windowing libraries out
there. What I need is about 20% of the common functionality between MFC\
Winforms\ Qt\ WxWindows in standard wrapper classes. This will allow me
to write "most" of my applications to that interface and select the
underlying platform\ framework as a build target.

I mention my problem domain, because I believe it to be a rather common
one. I also agree with the notion that it takes *alot* of effort to
fully encapsulate a GUI.

What I would LIKE would be a simple windowing system that I can use,
maybe it is not the most robust, but it is "boost standard". This would
then allow me to write portable Gui applications.

In so far as paradigm, this would mean choosing between the common model
features of the above libraries.

I will be developing this, and may eventually submit it to boost, but if
someone does before me, all the better. I just eventually want something
that is "standard" in some way that gives me platform \framework
isolation.

*** Simple windowing layer needed for Boost **

I would like to also develop some GUI tools that do things like allow
one to:
* "step through" bjam files interactively \ debug
* Show a "report" of my command line configuration outlining what
appears to be set correctly (i.e. doxygen will not work in your config
because variable XX is not set to a valid path) (maybe even a little
cartoon dog that wags his tail if your vars are set properly) (<< JUST
KIDDING)

I believe simple gui tools along those lines would help the usage and
spread of boost in general, and would help those who use boost on a day
to day basis.

To support that concept- I suggest something along the lines of the
TinyXML library buried somewhere in boost. It is a bare bones lib that
gets the job done.

If we were to have:

* Ability to create dialogs
* make buttons and respond to them
* make edit controls and read and write to them
* make list boxes and manipulate them
* make a tree control and manipulate it

As a *very* simple and light library, this would allow me to make simple
GUI apps that were "boost standard". The above functionality should be
simple enough to do with Raw API calls on the various platforms.

I would ask that those considering GUI libs take my perspective
seriously, as the greatest value that can be had is "having something
simple that is standard", more than it is in making something do
everything.

This would also provide a small incremental step to address many of the
interesting ideas that have been put forth on this thread.

:)

(my 2 cents)

Brian Braatz


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk