From: Hurd, Matthew (hurdm_at_[hidden])
Date: 2004-03-03 19:19:26
> On Behalf Of Jesse Booher
> Sent: Thursday, 4 March 2004 8:05 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: GUI library - another one
> It is never a bad thing when someone is interested in donating their
> to develop software to share with the world, and if there is a
> of developers here with the time and motivation to develop a full
> GUI library that rises to the high standards of Boost that would be a
> wonderful thing. That said a GUI library is a *HUGE* undertaking and
> other cross platform libraries like wxWidgets have a big head start.
> that this is a race or anything but when it comes to GUI libraries,
> features nearly always trump form. After all an awkward interface is
> developer annoyance, whereas a missing feature can be a show stopper.
> There is a certain allure to clean slate designs and there may very
> be no existing open source user interface projects that you would
> worthy of your time, but I wondered if you have considered any
> less ambitious alternatives such as creating a framework employing
> components from an existing open source project? It seems to me that
> promise of open source development is not served when wheels (or
> need to be reinvented over and over again.
I'd agree with this sentiment. The world is littered with limited cross
platform gui libraries. I'd take a decent free one, such as wxWidgets
(nee wxWindows), and look at wrapping its elements and leverage that
experience. Add new controls/widget later. If it doesn't make boost
maybe it could make wxWidgets...
Building a RAD tool than generates C++ and resource files including
itself in a self hosting way would be an excellent driver.
I've never met a gui lib I've liked and I've met quite a few in the
street. Ugly critters, they all need a big bath in some sheep drench.
Lack of good GUI is a thorn in C++'s side. GUI in C++ is just too hard.
I want something RADically different. Some new, not just neat C++. The
strength of a new approach in C++ could help improve the C++ community.
Firstly, I'd like to see it driven by both a user requirement of
building the gui and the developer requirement of elegant portable c++.
I'd like to see a few things I'd like that are probably a little
different to current approaches:
1. The ability to drap and drop complete panels in the builder where
they are can be aware of their context and automagically hook up to
their context if possible.
This means "inheriting" a context where a property can hook up to a
provider automagically if there is one that makes sense. E.g. you have
a property stock_code, which goes up the structural context of the gui
until it finds a match, or it is mapped. This way you can drag and drop
components with a minimum of fuss. It is a bit like how events
propagate on current windowing systems.
This reminds me a little of spirits closure syntax.
1a. An extension to this is addressing properties where the scope of the
property is found in the structural hierarchy automagically.
Allowing automatic proprogation up and down the hierarchy would be neat.
For example, I change my background colour and my parents do too until a
parent is reached that doesn't with to. That kind of thing. Also being
able to expose data / containers in a similar form so I can just get the
stock_code that is relevant to my context by looking up my structural
heirarchy... That kind of thing.
1c. Being able to address components and data by structure at run time
where that structure may be constructed at run time in a similar way.
2. A natural MVC mechanism where changes flow by default but can have
quality of service parameterisation added, like: stop it; all changes,
but bundle them up; if there is a queue of changes cause I'm slow, just
give me the latest, etc. That kind of thing. QoS is not so important
to me but having the design there to support this is. A lot of systems
I deal with need this feature as I often have torrents of data. Events
would flow down the structural hierarchy similar to point 1. This flow
is how gui toolkits already typically work for events.
3. A good sizing mechanism. Either swing or wxWidget sizer like (which
often doesn't work out well for small devices) or something that is
specifically laid out with pixel accuracy, perhaps with minimum size,
with simple ratios of stretchiness.
Julian Smart's DialogBlocks is going down this track with wxWidgets.
4. An annoyance of current approaches is that some things are fixed at
widget creation time and some things are adaptable properties at run
time. I'd like to see them all as run time properties. This could be
approached wrapping current kits by buffering the display, deleting and
re-creating the widget. Temporary messy implementation for a nice
5. Support Metalayout, with windows draggable to tool bars, tabs.
Docking at the window edges and the like. wxWidgets frame layout
toolkit does this for you.
99. It would be neat to have an abstraction layer where the gui detail
was separated from the functional layer via a pipe which could be local
or remote to support a fat, thin or chunky client approach. Eventually
and approach where the code might migrate from server to client, and
vice versa, to support execution where ever it is optimal... I call
this the smart client approach :-)
These have not much to do with c++, but such an approach in c++ could
If I were to tackle this, I would take wxWindows as my implementation
level so I get linux, win32 and mac with native controls and start
building a gui composition thing that could generate the c++ and
resource files I needed. Concurrently developing the c++ framework. A
goal would be to self hosting where you can generate yourself.
All the other neat c++ mentioned in this thread still holds true, but I
think there needs to be more than just yet another gui toolkit for c++
and the focus needs to be on making a) a nice framework and b) something
a little more innovative or added value than just yet another signal /
slot or event routing thing.
A neat way of simply composing the stuff by taking form of structural
context and with a form of structural addressing (I just made that term
up) might be the basis of such an innovative approach.
A way I like to think of it is a workflow / graph / state machine that
is hierarchically composed where each node can address it children and
parents and some of the nodes / objects have i/o side affects which
might include gui drawing stuff.
Does this make sense or is it more of my typically worthless ramble?
Susquehanna Pacific P/L
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk