RE: [boost] Java style GUI in C++

From: Hurd, Matthew (hurdm_at_[hidden])
Date: 2004-08-19 21:02:57

> Behalf Of David Turner
> Sent: Friday, 20 August 2004 3:32 AM
> To: boost_at_[hidden]
> Subject: RE: [boost] Java style GUI in C++
> 
> > I am currently designing a GUI framework in C++ (initially
> > targeting the
> > Windows platform) that uses a model similar to that which
> > Java uses in it's
> > AWT and Swing libraries. Specifically:
> 
> [snip]
> 
> > I would appreciate comments and ideas as to what people would
> > like out of a
> > GUI framework, especially one that will be multi-platform.
> >
> 
> Boost-style C++ GUI library utilizing boost::signals and with a nice
way
> of handling message loops:
> 
> http://cxxgui.sf.net/

Looks like a very nice conservative approach.  I think you're wise to
keep it simple and take a conservative c++ approach.  Only trouble is it
still feels like a lot of other things just shines a bit brighter and
has cleaner lines.

However I must say I've never seen a UI lib I've been happy with.  Nor
have I written one, or infrastructure that uses one, that I've been fond
of.  I find even 200 lines of code (not cxxgui) for a simple split
windows file explorer-like interface scary, but the sad thing is that it
is a great improvement over the norm.

Some rambling thoughts on things I'd like to see are:

1. run-time and compile-time configurability, especially with some like
compile time specification language like layout capability.  There was
some talk about this and some suggestions previously on this list.
Marrying this to run-time would be interesting.  

Perhaps at compile time you can decide if there is an explicit handling
method and if not call something with your source and event type that
will dispatch.  However this would lock you in at run-time if did this
as a compile time metaprogramming thing that ending up optimizing to a
function call equivalent but perhaps both options are appropriate...  

2. reverse structural inheritance of events handler equivalents.
Widgets are composed of other widgets.  A window may handle the click,
or prevent it, for a child.  You can attach a handler for a named event
at any point in the composition / structural hierarchy, it doesn't have
to be the source, but is aware of it.  Handling goes down the hierarchy
to source.

3. get rid of the distinction between properties, events and methods.
Consider a widget a functor with visual side affects.  Consider it like
a dataflow where properties being set, events and method calls are just
messages coming into this node.  Allows you to interpose handlers,
recorders, do nice testing and all sorts.  

Draw backs are interoperability with initialization requirements of
widgets.  That is, some things are set at widget create time.  But this
might handled by avoiding by not changing such parameters and thus not
needing to change, but if initialization only parameters of legacy
components change, then destroy and recreate the component.

4. Structural context sensitivity, 

4a inherit properties from your run-time structural parents, fonts,
colours, whatever, perhaps from theme packages that are higher in the
tree.  The structural tree is used to find the appropriate handler for
properties, events and methods (all one in the same)

4b Context sensitive addressing and sources.  Just like event handling,
property setting and method calls are sinks that are handled with
structural sensitivity, sources, such as changing properties, data
propagation flow out and can be addressed in a context sensitive manner.
E.g. if you have a widget that is expecting an source for stock code, it
should look up the structural hierarchy to find it, unless it is
provided with an explicit mapping to a different source.  Allow non UI
components that can act as holders for properties (like a root
blackboarding thingo (technical term) ) so that components can reflect
context of non-parental nodes.  

4c Context sensitive addressing.  Want to be able to get the properties
/ sources of siblings, i.e. children of parents of yours.  "Instrument"
-> "maturity".  You find the parent and then lock into its context for a
piece of detail.

5.  must be multiplatform, leveraging off something like wxwidgets like
notus does for its implementation layer would probably be a good idea.

6.  must have a wysiwyg designer (though I could live without it) (self
hosting would be a neat goal) - integrating the compiler into this and
being an ide would be nice - perhaps something like eclipse could help

6a  Because of the run configurability of everything there is nothing to
stop external descriptions of components, including the mapping of
sources to sinks to capture most of the requirements.  Obviously where
code is needed you need code and an xml resource description will not
help.

7.  Should support run time type conversions to allow easy hooking up of
stuff.  Not sure how explicit or implicit this should be.  A while ago I
did something like this that also supported the dimensionality of the
data so you could cut, slice and aggregate stuff easily between widgets.
E.g. use the entire list, the selected items, etc...  would take some
kind of multidimensional iterator thing I guess.  Allows some
sophisticated run-time modelling capabilities.  See the data in a grid,
or a list control, a combo, ....

With this kind of structure you should be able to compose widgets
hierarchies that have awareness of the others around them and will have
reasonable normal functionality without too much coding at all.
Supporting this at run time as well allows you to have some nice drag /
drop or otherwise dynamic configurability.

Have some that get a list of strings, displays it in a list.  Click on a
list item and a chart and grid automatically updates.  A detailed pane
of items relevant to the first click docked at the side updates.  The
exit item in the menu does the default behaviour of shutting down the
application.  

My goal is that this should be possible with out an enormous number of
lines of code.

Structurally specify it.  Use context sensitivity, standardish workflows
and data set handling / iterator capabilities to avoid code.  Thwack
custom events in where needed.

Been thinking about this for years and have implemented various systems
that do bits of this approach.  Enough to know it works pretty well.  It
has always been too much work to chew on as a generic solution though...

$0.005,

Matt.

Side issue:  resizing / device independence.  Problem with swing /
wxwidget sizers and the like is that you can end up with some ugly
looking screens with lots of space, things that are too small on screen
sizes that are inappropriate.  A lot of the time it doesn't matter too
much, but often enough to irk me the screens just don't look "sharp"
enough compared to an explicitly designed screen.  This is often the
issue with smaller screen sizes like portable devices.  Something I've
done in the past is to give components fractions of resizing for top,
left, height and width which allows a tight design, to the pixel ( I
really like the compile time unit dimensioning of the co-ords by the
way, positioning by mm dimensions is great) with easier control on how
the thing will resize.  Also for device independence you might be able
to target a different device by using a capability set where controls
map to other controls for that device, they just have to handle the same
sources and sinks for their node, i.e. have the same conceptual support.

Perhaps that be a nice level of indirection to solve problems.  Use a
tree control, grid or list or whatever, just don't specific which.  The
platform configuration maps in the explicit control.  Is you use a more
refined control that is not available on that specific platform, you can
substitute a generic one based on a substitutability principle (like
Liskov SP), or perhaps it is an error (perhaps the design can specific
the functionality that must exist for the there to be no error).

A thin client approach to this would be even nicer, separate the visual
aspects from the data it refers to by protocol and/or method call so
that interesting thin / thick / adaptive clients can be built.

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.