Hi Alan, I have to step out and don't have time to write a complete response just now. But I will later today or tomorrow. One thought to mull over in the interim:
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.
At a high-level of abstraction a GUI is very definitely state machine - a pretty complex one at that. For example, consider the process of clicking a button widget. A stream of mouse events is "parsed" against some set of rules that might encode something like "if window X has the focus AND the mouse cursor is within a 2D region circumscribed by some polyline AND the left button is clicked THEN dispatch drawing code to repaint the button in the depressed position AND relay the information that the button press occurred to handler Y". Or consider the case of the user typing on the keyboard. Is the ALT key depressed. Shift? Which window is focused? Should the keystroke change the focus or be directed to a handler associated with the currently focused window? The challenge is to come up with a succinct ways to encode all these "policies" explicitly as a set of states and state transition vectors (along with associated actions - i.e. handlers). If we can agree that GUIs are inherently state-based, then the discussion becomes how best to encode the various policies so that they are (a) readable and (b) easily extensible. The idea of perhaps adapting Spirit for this task is based on observations that in essence it allows you to succinctly encapsulate extremely complex (often recursive) policy rules and conveniently bind to semantic actions. There are many ways to encode state machine of course. There's a FSM library that at least been put up for review for example. BGL can also be usefully employed to represent state machines. However, there's a lot of work invested in Spirit and maybe it makes sense to leverage it? I'll write more later. I was supposed to be out of here 30 minutes ago ;) - Chris "Alan Gutierrez" <alan-boost@engrm.com> wrote in message news:20041223161132.GA6689@maribor.izzy.net...
* 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost