On Wed, 25 Aug 2004 12:08:21 +0200, John Torjo <john.lists@torjo.com> wrote:
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. 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... A boost ui framework needs to define a lot of interfaces / aspects for common properties, events and methods for various type of widgets. Special interfaces not supported on a different platform should still compile with a different widget that is less or more capable, perhaps with appropriate warnings, if the functionality does not make the program incorrect. What makes a grid a grid and is a must have... What other aspects do grids commonly have, etc... Another key would be iterator-like support for collections that widgets refer to and for access to items, selections that widgets have the state of... $0.001 matt.