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

From: Mathew Robertson (mathew.robertson_at_[hidden])
Date: 2004-08-25 18:11:58

> > I could really use some examples here ;) Because I really can't think of
> > any. Maybe we are mis-reading eachother ;)
> > 
> 
> What about considering a generic tree structure that represents
> composition of nodes, where that represents a model of hierarchy /
> containment of widgets.
> 
> Have a nice way of name/referring to things in a relative sense to
> support re-composing without drama.  This gives a way of addressing
> nodes.   Sometime referred to as subject addressing.  Needs to support
> implicit or explicit wild cards.
> 
> Each node has sources and sinks.  Read a property by attaching to the
> source.  Write a property by sending a value to a sink.  Calling a
> method is sending a property to a sink.  Events handlers attached to
> items in the hierarchy.
> 
> The event handler should be at the source node or higher in the hierarchy. 
> 
> An event handler is propagated down the composition hierarchy until it
> reaches a handler.  That handler may allow the propagation to
> continue.
> 
> Also method call equivalents, sending a message to a sink at a
> particular level, could be propagated down the hierarchy.  For
> example, setting a font for all composed items.
> 
> So there is a work flow between nodes a bit like the intensional style
> of programming with clocks.  The structural composition adds a
> richness in allowing events to be handled at many sites and methods to
> have greater context.
> 
> Add the context of getting a property from any parent, what is my
> parent font, colour, stock symbol, warehouse location and you end up
> with a richness of contextually aware widgets that can be composed
> with limited programming.
> 
> This conceptual framework for me forms a significant aspect for the
> basis for an ideal gui.  Most gui frameworks kind of work in this
> manner to some extent.

One main problem with this is that (generally speaking) there are at more than one heirachy that needs to be maintained:
1. The parent-child window relationship (eg this is needed for setting font on all children, hiding all children, etc)
2. Tab-order relationship
3. Event propogation heirachy

...just to name a few.  From the description above, point 2 is definately not handled.  And points 1 and 3 seem to be considered the same thing, which (in practise) they arn't.

[ Another heirachy could be needed to provide the ability to replay events - for testing.  I have been involved in discussions which say that its just a matter of overlaying the test framework on top of the event propogation heirachy.  There were technical discussions at to whether this would always work. ]

> On cross platformness...  a thought: 
> 
> Wrapping widgets to be nodes in this framework can give you
> portability.  Have different levels of specialization for the widgets
> to support more refined aspects improves functionality but makes it
> more difficult to support on many platforms.  I can imagine having a
> standard for a grid, say different levels, level 0 supports setting
> string values all of the same font in two d structure with control
> over fonts, level one adds row and column labels, level two support
> has sorting on clicking on labels, etc... specific controls will
> support different generic levels plus their own specialities.  A
> standardisation should exists for the differing levels of controls. 
> Perhaps levels is the wrong approach, perhaps aspects and combining
> aspects (as per policies) is a better way of thinking of this. 
> Supports interfaces / aspects / concepts (A,B,E,F for grids) plus
> these custom things on Panther...

wxWindows / wxWidgets has already tried this.  The end result is that they now have a layer which implements the widgets non-natively, as well as wrapping native widgets.  At compile time, you choose which method you want to use.

Mathew