Boost logo

Boost :

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
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk