* Christopher D. Russell <cdr@encapsule.com> [2004-12-23 10:16]:
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 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've been interested in the idea of leveraging Spirit to implement event processing systems for some time (here we parse event streams - not characters, using Spirit's grammar to encode state machine transition logic, and dispatching specific state-bound actions via Spirit's semantic actions). In the context of a GUI library, it's occurred to me that Spirit might be employed to "parse" streams of mouse, keyboard, and graphic subsystem notification events via a custom Sprit scanner. This of course implies that mouse, keyboard, and graphic subsystem hooks are abstracted in some platform independent manner but that's doable.
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 like an interesting idea, but I don't understand it. 1) Treat a stream of events as a lexemes and match them using a parser. 2) Dispatch the message to a control based on the match. Do you do this in order to recognise gestures, like begin drag? Do you use it to recognize any single event? It seems like many events, a menu click, are mapped one-to-one to a procedure, and thus you get those strange macro tables like in MFC. You are saying that Spirt would be a more pleasing representation, and would allow for chords and gestures? Because when I think of a windowing application, I think of it as stateless, ready to handle any request the user generates, and that waiting for a stream of events, strikes me as a hung user interface, so "complex state machine" confuses. -- Alan Gutierrez - alan@engrm.com