From: Christopher D. Russell (cdr_at_[hidden])
Date: 2004-12-23 09:48:48
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!
Message routing:
signals / slots?
Window / subwindow hierarchy:
Given that typical GUI applications have many "windows" that are typically
created and destroyed in response to (a) user input (b) non-graphical
subsystem events, a succinct mechanism is needed to keep track of parent /
child windows hierarchies. This information is used to calculate / transform
drawing coordinates, and affect changes to message dispatching / routing /
filtering. I think this information should be modeled using the BGL so we can
customize the overall behavior of the system using graph algorithms. One
could go a step further even and use a top-level graph to model the windowing
hierarchy and another graph associated with vertex properties to encode an
arbitrary closed polyline to represent non-rectangular windows.
Threads:
It's useful to be able to associate a "window" with a thread for
high-performance GUI drawing. This is somewhat of a pain under Windows for
legacy reasons but it's possible (I've done it within the context of the
WTL). Here you simply blast the video subsystem with draw requests from
multiple threads and place the onus of optimizing the call sequence on the
driver and the underlying hardware. It would be useful to take this into
account explicitly and build multithread support directly into the library.
Placing the burden of this on the library user will invariably limit the
portability of any application written against the lib I think.
Just my two cents worth - Chris