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

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2004-08-25 18:57:29

> <mathew.robertson_at_[hidden]> wrote:
> 
> 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.
> 

I see tab ordering as a property, but I see your point.  I can imagine
plugging a composite component into a structure and accepting its
children's tab ordering within the context of the parent tab ordering
but allowing for the changing of it.

Sure 1 and 3 can be arbitrary.  Model-View is arbitrary.  Thought
keeping 1 and 3 together seems necessary to keep the ui simply
composable.  You can still support external items via sinks and
sources.  I think that to keep the component drag/droppable and
composable within context, with a minimum of fuss and without too much
explicit code to hook it up, you need it to be in the form of such a
structural package.  A more general model-view style can still be
accomplished by having data items, "blackboards", higher in the
hierarchy simply accept property changes and propagate them down to
clients conceptually.  This is framed conceptually, there is no reason
why the links can't be explicit via boost::signal or some such.  The
implementation details can be quite different to the conceptual view.

Perhaps allowing arbitrary mappings between things in the ui, like
model-view allows, makes implies natural, what I call, blackboards
(old ai term) at common parent levels which also determines "natural"
cut points for sensible composability of the interface...

At the end of the day I want to be able to add a stock charting
doo-dad to a ui which a simple process of

some_composition_point.add( new_ui< stock_chart_thingo>() );

it expects to "inherit" from its context stock information and its
widgets will perform appropriately without additional information,
including adopting the appropriate fonts etc...

Allow for remapping of context...
some_composition_point.alias("*.stock.close", "series.point");
some_composition_point.add( new_ui<generic_grapher>() );

A smarter gui might allow the dragging and dropping of components into
composition points where they make sense...

$0.02

matt hurd.