Event Dispatching Mechanism in MadButterfly

Introduction

Event dispatching is an important job for the GUI system. Usually, we need to handle the following events in the GUI

In the rest of this article, I will discuss the event mechanism of the MadButterfly and provide a design of event API.

First thing go first. We will start from the most important event - mouse evnets.

Mouse/point events

MadButterfly use observer design pattern to implement the event dispatching. In this pattern, observer and subject are used to handle events. The subject is a specific type of events. For example, mouse events or keyboard events. Each subject can have zero or more observers. When the system send events related to the subject, it will call the subject_notify function of the subject, which will notify every registered observers.

In this way, we can decouple the components which send the events and the components which need the events. For example, if we implement the X and GTK backend, both of them will call subject_notify when it receive the mouse events from the X or GTK. The observers don't care whether the notification coming from X or GTK. The X and GTK backend are responsible to translate the X or GTK mouse events into the mouse subject.

Therefore, we can use the subject as the astraction layer between MadButterfly clients and the backend.

To be more specific, in the current X backend. When it receive a MotionNotify mouse event from the X server, it will send an mouse event to the mouse event subject ob type OBJT_GEO.

 mouse_event.event.type = etype;
 mouse_event.x = x;
 mouse_event.y = y;
 mouse_event.but_state = state;
 mouse_event.button = button;
 subject = sh_get_mouse_event_subject(shape);
 factory = rdman_get_ob_factory(rdman);
 subject_notify(factory, subject, (event_t *)&mouse_event);

The shape above is determined by the mouse position and the etype is determined the shape under the mouse and the last shape which receive mouse event.

Please remember that the subject will relay the the events to all of its parents.

PS. Currently, the MadButterfly does not have mechanism to stop propogation based on the result of the observer.

Key event

The key events is send as subject type OBJT_KB. Each key object has the following fields code: The original raw keycode. sym: The symbol ID of the raw keycode. * event.type: EVT_KB_PRESS or EVT_KB_RELEASE

Timer event

The timer use different mechanism. It does not use the observer pattern. Instead, it is registered as separate timer queue. Do we want to change the implementation?

IO event

Currently, no IO events is available in the MadButterfly yet. W should add the following IO subjects. OBJT_FD: We need to provide some function to generate subject for file description. It will send events when teh file descriptor become available for read/write or error. OBJT_XMLIO: Provides functions similiar to the XMLSocket in actionscript.

Repaint

The repaint event is not sent directly. Instead, the X backend call rdman_redraw_area directly to handle the repaint event. This function will send EVT_RDMAN_REDRAW out.

Summary

The observer pattern can be used to be the abstraction layer of the MadButterfly. The current implementation has effectively seperate the backend and the core engine. There is no direct call to the engine from the backend. All messages are deliver to the MadButterfly through the observer.
SourceForge.net Logo