Boost logo

Boost :

From: Bronek Kozicki (Brok_at_[hidden])
Date: 2003-07-29 05:02:52


E. Gladyshev <egladysh_at_[hidden]> wrote:
> GUI objects generate events. What is the best design
> for it? Should the events handlers be executed

I do not know what is best design, but here's what I think about it:
- each "window" (or almost each - may it be widget, edit box, dialog,
data view, or main application window, but maybe not static window) may
own (but do not have to) its message thread;
- if window owns its message thread, it will be able to receive UI
events;
- it window does not own its message thread, its UI events will be
passed to its "parent" window (ie. window containing it; there may be
windows, which does not have parents, like main app. window - in such
case compilation error is preferred way to signalize that there's no
thread able to handle window events);
- window events thread must have signal/slots (or callbacks) mechanism,
which will be used to call user-defined functions when particular event
happens (lack of such mechanism should be compile time error)
- user defined functions will be called in context of event thread, and
will receive information about A. window (or widged) which fired event
B. window, whose event thread accepted event (may be the same as A. or
its parent, or its grandpa etc.). This way user will be able to register
single function in multiple event threads (signal/slots mechanisms ?)
and be sure, that while handling event from one window, the function
will be able to accept event from another window (in another thread). On
the other hand, window thread will be able to accept and process only
single event at once, thus user functions should minimize time necessary
to process event.
- if user funtion needs to do some more processing for the event it
received (thus blocking other events in the window which accepted the
event), this function should postpone processing into another thread
(created a priori or pooled ?). There should be some conveniant way of
creating threads for this purpose. Thread function will be started just
when user function leaves, and this separate thread will continue
processing. In the same time, window which accepted event will be able
to receive another event, and also receive (at some later time)
notification about finished event processing.

These are just ideas .... I do not even know how these ideas match to
rules of GUI programming (if there are any).

B.


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