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

From: John Torjo (john.lists_at_[hidden])
Date: 2004-08-21 06:22:18

> 
> Some rambling thoughts on things I'd like to see are:
> 
> 1. run-time and compile-time configurability, especially with some like
> compile time specification language like layout capability.  There was
> some talk about this and some suggestions previously on this list.
> Marrying this to run-time would be interesting.  
> 
> Perhaps at compile time you can decide if there is an explicit handling
> method and if not call something with your source and event type that
> will dispatch.  However this would lock you in at run-time if did this
> as a compile time metaprogramming thing that ending up optimizing to a
> function call equivalent but perhaps both options are appropriate...  

that's more or less what win32gui does.

And more to the point, when you extend a window class, you can add your 
own handlers into the picture.

Thus, you can end up with more event handlers for the same 
event/command/notificiation.

This is TOTALLY ok.
Whenever a handler for an event/command/notification gets called, it can
decide what to consider this event:
- event_not_handled: I consider this handler did not handle this event. 
If more handlers exist, call them. If no more handlers, call default (in 
our case, DefWindowProc)

- event_is_handling. I did handle his event, but it's ok if other 
handlers handle it too. So, if there are other handlers, call them too. 
After all handlers are called, DO NOT call default (in our case, 
DefWindowProc).

- event_handled: I handled this event. DO NOT call other handlers, nor 
the default( DefWindowProc).

I thinks this handles most (if not all) cases.

> 
> 2. reverse structural inheritance of events handler equivalents.
> Widgets are composed of other widgets.  A window may handle the click,
> or prevent it, for a child.  You can attach a handler for a named event
> at any point in the composition / structural hierarchy, it doesn't have
> to be the source, but is aware of it.  Handling goes down the hierarchy
> to source.

In fact, I think it should be quite reversed.
If a window cannot handle a command/notification, forward it to its 
parent and so on - until someone handles it or reaches top.

> 
> 3. get rid of the distinction between properties, events and methods.
> Consider a widget a functor with visual side affects.  Consider it like
> a dataflow where properties being set, events and method calls are just
> messages coming into this node.  Allows you to interpose handlers,
> recorders, do nice testing and all sorts.  

That is such a funny thing. That's exactly what Win32 API does with its 
messages. However, I think a wrapper over is quite ok.

> 
> 4. Structural context sensitivity, 
> 
> 4a inherit properties from your run-time structural parents, fonts,
> colours, whatever, perhaps from theme packages that are higher in the
> tree.  The structural tree is used to find the appropriate handler for
> properties, events and methods (all one in the same)

That would indeed be great ;)

> 
> 4c Context sensitive addressing.  Want to be able to get the properties
> / sources of siblings, i.e. children of parents of yours.  "Instrument"
> -> "maturity".  You find the parent and then lock into its context for a
> piece of detail.

If I understood correcly, you want to easily find siblings???
Easy with win32gui:
find_wnd[<some_type>](some_wnd,search_siblings);

example:
// finds all sibling Edit boxes.
find_wnd<edit>(some_wnd,search_siblings);

> 
> 5.  must be multiplatform, leveraging off something like wxwidgets like
> notus does for its implementation layer would probably be a good idea.

I don't agree with multiplatform for GUI.
(note: I totally agree with multiplatform console applications)
Of course, in an ideal world, yes - that would be the case. Every OS 
would have a similar GUI, etc. But our world is far from ideal.

A lot of things are different from OS to OS - appearance, events, etc. 
Some features don't exist on a OS - what do you do? Do you either ignore 
that, or emulate it on all other OSs?

> 
> 6.  must have a wysiwyg designer (though I could live without it) (self
> hosting would be a neat goal) - integrating the compiler into this and
> being an ide would be nice - perhaps something like eclipse could help
> 

Indeed. That would be great ;)
> 
> 7.  Should support run time type conversions to allow easy hooking up of
> stuff.  Not sure how explicit or implicit this should be.  A while ago I
> did something like this that also supported the dimensionality of the
> data so you could cut, slice and aggregate stuff easily between widgets.
> E.g. use the entire list, the selected items, etc...  would take some
> kind of multidimensional iterator thing I guess.  Allows some
> sophisticated run-time modelling capabilities.  See the data in a grid,
> or a list control, a combo, ....
> 
> With this kind of structure you should be able to compose widgets
> hierarchies that have awareness of the others around them and will have
> reasonable normal functionality without too much coding at all.
> Supporting this at run time as well allows you to have some nice drag /
> drop or otherwise dynamic configurability.
> 
> Have some that get a list of strings, displays it in a list.  Click on a
> list item and a chart and grid automatically updates.  A detailed pane

Just a thought - I'll soon (hopefull on Tue ;)) finish save_dlg class - 
which allows binding of data to controls. Of course, it does not work 
for list view/tree view - this is way too complex for now. But time will 
come ;)

> 
> Side issue:  resizing / device independence.  Problem with swing /
> wxwidget sizers and the like is that you can end up with some ugly
> looking screens with lots of space, things that are too small on screen
> sizes that are inappropriate.  A lot of the time it doesn't matter too
> much, but often enough to irk me the screens just don't look "sharp"
> enough compared to an explicitly designed screen.  This is often the
> issue with smaller screen sizes like portable devices.  Something I've
> done in the past is to give components fractions of resizing for top,
> left, height and width which allows a tight design, to the pixel ( I
> really like the compile time unit dimensioning of the co-ords by the
> way, positioning by mm dimensions is great) with easier control on how
> the thing will resize.  Also for device independence you might be able
> to target a different device by using a capability set where controls
> map to other controls for that device, they just have to handle the same
> sources and sinks for their node, i.e. have the same conceptual support.

That's exactly what the (Win32) Dialogs are for ;) One of the gooals 
(http://www.torjo.com/win32gui/goals.html) of win32gui is to increase 
dialog programming - so that you can set as many properties at design time.

> 
> Perhaps that be a nice level of indirection to solve problems.  Use a
> tree control, grid or list or whatever, just don't specific which.  The
> platform configuration maps in the explicit control.  Is you use a more

Much like auto-mapping facility from win32gui ;) ?

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)