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

From: Christopher D. Russell (cdr_at_[hidden])
Date: 2004-12-23 12:53:42

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_at_[hidden]> wrote in message 
news:20041223161132.GA6689_at_maribor.izzy.net...
>* Christopher D. Russell <cdr_at_[hidden]> [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_at_[hidden]
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>