|
Boost : |
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]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk