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

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2004-08-25 05:09:28

On Wed, 25 Aug 2004 12:08:21 +0200, John Torjo <john.lists_at_[hidden]> 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.