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