Re: [boost] Re: Re: Re: GUI/GDI template library

From: Scott Woods (scottw_at_[hidden])
Date: 2003-07-28 17:19:02

> > Sometimes you want your events to be called
> > instantaneously (clear
> > paintdevice before drawing on it) and sometimes you
> > will want to catch and
> > forward them elsewhere (i.e. keystrokes).  You need
> > both.
> 
> I guess what I am trying to say is that I'd prefer a
> single underlying event generation/dispatching
> mechanism.  You could have both (instaneous and asynch
> behaviors) with just one underlying mechanism.
> If we are to use threads then the instant event would
> be emulated by waiting on the completion.  If we are
> to use single-thread message pumps (like Win32), the
> asynch event would be emulated by a post function. If
> we select the first option, the gui library must be
> thread safe.
> 

Yes. The single technology that delivers both behaviours
sounds easier to deal with.

A couple of thoughts on event generation/dispatching and
some previous comments to do with lack-of-developer-
commitment-to-state-machines.

1. events are very much part of the state machine issue.
i mean, what is receiving the events and how do they
respond to the events (at different times)? i think you
stated intention to avoid state machines (laudable) but
getting tangled in event generation/dispatch is possibly
the same thing.

2. is there potential to identify a "generic state machine"
that can be part of your gui templates/library without
getting tangled in the application specific machines. i
wondered about this because MFC implements (very
loosely) a state machine but it doesnt know anything
about actual app-events, i.e. it builds and dismantles
dialogs with controls (a stately process), but it doesnt
itself know what needs to be done on click of some
application button entitled "Run".

SW