Re: [boost] Re: [GUI] some random thoughts on GUI libs

From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2004-12-24 10:20:15

* Reece Dunn <msclrhd_at_[hidden]> [2004-12-24 06:25]:
> Christopher D. Russell wrote:
> >Some random thoughts on GUI libraries:
> >
> >Message filtering, dispatch:
> >
> >Somewhere buried in Joel de Guzman's Spirit or Phoenix docs I recall 
> >mention of functional programming techniques being useful for working with 
> >graphical user interface library organization.
> 
> This sounds interesting. I am not sure how it would look, though.
> 
> >This comment stuck in my head as I generally dislike the
> >organization of message dispatch and filtering code in libraries
> >like the MFC and the WTL.
> 
> I have never liked their approach either. I like the Win32GUI approach 
> and have adapted it into my Boost.GUI library.

    [snip]

> The event processor allows you to attach a handler to a component using:

>    signal_type handler_for( event_id );

> for example:

>    frame.handler_for( event::onclose )
>         .connect( &terminate_gui );
> 
> Buttons define a
>    signal_type onpressed()
> method that is an alias for the OS-specific:
>    handler_for( button-pressed-event )
> which in Windows is:
>    handler_for( event_id( WM_COMMAND, BN_PRESSED ))

> I am also considering returning a proxy class to a signal object to 
> allow for:

>    new_.onpressed()
>       .attach( handler_type::handler, this, &mainfrm::onnew );
>    cancel.onpressed()
>       .attach( handler_type::handler, &terminate_gui );

> >In essence, this is just another way to encode complex state machines. But 
> >I think it would be cool to encode the message filtering and dispatch 
> >logic in EBNF!
> 
> This sounds cool. Could you give an example?
> 
> It should be possible to build the state machine logic on top of the 
> event processing outlined above. For example:

>    button quit;
>    quit
>       // handle button presses
>       << state::pressed[ &terminate_gui ]
>       // convert pressing the spacebar into pressing the button
>       << state::keypress( ' ' ).fire( state::pressed )
>       ;

> Is this what you are aiming at? I am not sure on the implementability of 
> the above, but it will most likely be built on top of the event 
> processing/binding that is in place by my library. This would be done my 
> constructing the appropriate function objects and the appropriate calls 
> to handler_for.

> The state machine should allow for successive slots, e.g.:

>    frame
>       // save the state of the application (e.g. position)
>       << state::close[ state::bind( frame, &mainfrm::onsavestate )]
>       // terminate the application
>       << state::close[ &terminate_gui ]
>       ;

    I like both approaches.

    I like Christopher Russell's idea, as best as I can imagine it,
    when I consider the complexity of routing a message through an
    MDI illustration application. IIUC, one could use EBNF to
    describle chords or gestures, and map those to the right
    function in the right object.
    
    A simple message table is not expressive enough to dispatch a
    message for something like Adobe Illustrator.

    At the same time, I think that what Recce has developed is a bit
    for familiar to developers, when they are dealing with a
    control, like a button, that generates a well defined event,
    like a button press. If I were putting together a
    JTable/TableModel sort of program, it is what I'd expect, and I
    wouldn't have to learn a Spirt grammar.

    Furthermore, if all I wanted was a dialog box to configure a
    handful of options, I don't know that I'd want to worry about
    event processing at all. Rather, I'd like to specify a mapping
    from the dialog box to a structure, perhaps attaching valiation
    to some of the controls, and just hand it off to a function that
    would gather the information, and not return until it was
    correct and accounted for.

    An FSM is the right way to look at a Canvas application, but if
    all I need is a Form submission, I don't want to turn on that
    part of my brain. 

    (This is why I put forward a taxonomy.)

    Finally, I've been able to create cool interfaces using the
    event bubbling model of XML DOM, and I'd like to have that
    available. In XML DOM the message is routed to the top-most
    document division in a an XML tree structure, and then the event
    bubbles up the tree until an event handler is found. If you've
    not used this, it might sound like six of one, but it really is
    an economical expression of event handling in a Document. Not
    necessarily an XML document, of course.

    This is all to suggest that either message handling is expressed
    using Christpopher's most expressive method, and these other
    messages are implemented in those terms, or an ungangly yet
    effecient message routing library is developed, and
    Christopher's method is one interface to that library. 

--
Alan Gutierrez - alan_at_[hidden]