Mercurial > MadButterfly

comparison dox/event_dispatching.h @ 191:18f8c3126cdb

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Refine installation instructions and document event dispatching by wycc.
author Thinker K.F. Li <thinker@branda.to>
date Tue, 18 Nov 2008 13:55:09 +0800
parents
children
comparison
equal deleted inserted replaced
190:0a924eb9ccab 191:18f8c3126cdb
1 /*! \page event_dispatching Event Dispatching Mechanism in MadButterfly
2 *
3 * by wycc
4 *
5 * \section evt_intro Introduction
6 *
7 * Event dispatching is an important job for the GUI system. Usually,
8 * we need to handle the following events in the GUI
9 *
10 * - Mouse/pointer events
11 * - Key event
12 * - timer event
13 * - IO event
14 * - Repaint event
15 *
16 * In the rest of this article, I will discuss the event mechanism of
17 * the MadButterfly and provide a design of event API.
18 *
19 * First thing go first. We will start from the most important event -
20 * mouse evnets.
21 *
22 * \section evt_mouse Mouse/point events
23 *
24 * MadButterfly use observer design pattern to implement the event
25 * dispatching. In this pattern, observer and subject are used to
26 * handle events. The subject is a specific type of events. For
27 * example, mouse events or keyboard events. Each subject can have zero
28 * or more observers. When the system send events related to the subject,
29 * it will call the subject_notify function of the subject, which will
30 * notify every registered observers.
31 *
32 * In this way, we can decouple the components which send the events and
33 * the components which need the events. For example, if we implement the
34 * X and GTK backend, both of them will call subject_notify when it
35 * receive the mouse events from the X or GTK. The observers don't
36 * care whether the notification coming from X or GTK. The X and GTK
37 * backend are responsible to translate the X or GTK mouse events into
38 * the mouse subject.
39 *
40 * Therefore, we can use the subject as the astraction layer between
41 * MadButterfly clients and the backend.
42 *
43 * To be more specific, in the current X backend. When it receive a
44 * MotionNotify mouse event from the X server, it will send an mouse
45 * event to the mouse event subject ob type OBJT_GEO.
46 * \code
47 * mouse_event.event.type = etype;
48 * mouse_event.x = x;
49 * mouse_event.y = y;
50 * mouse_event.but_state = state;
51 * mouse_event.button = button;
52 * subject = sh_get_mouse_event_subject(shape);
53 * factory = rdman_get_ob_factory(rdman);
54 * subject_notify(factory, subject, (event_t *)&mouse_event);
55 * \endcode
56 *
57 * The shape above is determined by the mouse position and the etype
58 * is determined the shape under the mouse and the last shape which
59 * receive mouse event.
60 *
61 * - If the mouse is on any shape,
62 * - If the new shape is the same as the last shape, we will send the
63 * EVT_MOUSE_MOVE events to it to notify it the mouse is moving inside it.
64 * - If the new shape is not the same as the last shape, we will send the
65 * EVT_MOUSE_OVER to notify it the mouse is just touch it.
66 * - If the current shape is not the same as the last shape, send the
67 * EVT_MOUSE_OUT to the last shape to tell it the mouse have left it.
68 * \code
69 * mevt = (XMotionEvent *)&evt;
70 * x = mevt->x;
71 * y = mevt->y;
72 * state = get_button_state(mevt->state);
73 *
74 * shape = find_shape_at_pos(rdman, x, y,
75 * &in_stroke);
76 * if(shape != NULL) {
77 * if(rt->last != shape) {
78 * if(rt->last)
79 * notify_shapes(rdman, rt->last, x, y,
80 * EVT_MOUSE_OUT, state, 0);
81 * notify_shapes(rdman, shape, x, y,
82 * EVT_MOUSE_OVER, state, 0);
83 * rt->last = shape;
84 * } else
85 * notify_shapes(rdman, shape, x, y,
86 * EVT_MOUSE_MOVE, state, 0);
87 * } else {
88 * if(rt->last) {
89 * notify_shapes(rdman, rt->last, x, y,
90 * EVT_MOUSE_OUT, state, 0);
91 * rt->last = NULL;
92 * }
93 * }
94 * \endcode
95 *
96 * Please remember that the subject will relay the the events to all of
97 * its parents.
98 *
99 * PS. Currently, the MadButterfly does not have mechanism to stop
100 * propogation based on the result of the observer.
101 *
102 * \section evt_key Key event
103 *
104 * The key events is send as subject type OBJT_KB. Each key object has
105 * the following fields code: The original raw keycode. sym: The symbol ID
106 * of the raw keycode. * event.type: EVT_KB_PRESS or EVT_KB_RELEASE
107 *
108 * \section evt_timer Timer event
109 *
110 * The timer use different mechanism. It does not use the observer pattern.
111 * Instead, it is registered as separate timer queue. Do we want to change
112 * the implementation?
113 *
114 * \section evt_io IO event
115 *
116 * Currently, no IO events is available in the MadButterfly yet. W should
117 * add the following IO subjects. OBJT_FD: We need to provide some function
118 * to generate subject for file description. It will send events when teh
119 * file descriptor become available for read/write or error. OBJT_XMLIO:
120 * Provides functions similiar to the XMLSocket in actionscript.
121 *
122 * \section evt_repaint Repaint
123 *
124 * The repaint event is not sent directly. Instead, the X backend call
125 * rdman_redraw_area directly to handle the repaint event. This function
126 * will send EVT_RDMAN_REDRAW out.
127 *
128 * \section evt_summary Summary
129 *
130 * The observer pattern can be used to be the abstraction layer of the
131 * MadButterfly. The current implementation has effectively seperate the
132 * backend and the core engine. There is no direct call to the engine
133 * from the backend. All messages are deliver to the MadButterfly through
134 * the observer.
135 */