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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk