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

From: John Torjo (john.lists_at_[hidden])
Date: 2004-08-26 10:24:32

Mathew Robertson 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.
>>    
>>
>
>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 
>

couldn't agree more ;)
That's why in win32gui I hold a map of all windows. Then when you want 
to find some windows that match a criteria (like, children, descendants, 
having a certain type, etc.), you ask for them (find_wnd_range<>) and 
simply iterate them.

Best,
John

-- 
John Torjo
Freelancer
-- john_at_[hidden]
Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.3beta released - check out splitter/simple_viewer, 
   a File Explorer/Viewer all in about 200 lines of code!
Professional Logging Solution for FREE
-- http://www.torjo.com/code/logging.zip (logging           - C++)
-- http://www.torjo.com/logview/         (viewing/filtering - Win32)
-- http://www.torjo.com/logbreak/        (debugging         - Win32)