<mathew.robertson@redsheriff.com> 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.