[Xcb-commit] tutorial

XCB site xcb at freedesktop.org
Sun Mar 16 10:21:00 PDT 2008


 tutorial/events.mdwn |   24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

New commits:
commit f908f39f13e8f2dc39cf6f08c467b9d45f0b05d2
Author: XCB site <xcb at freedesktop.org>
Date:   Sun Mar 16 10:21:00 2008 -0700

    web commit by Peter

diff --git a/tutorial/events.mdwn b/tutorial/events.mdwn
index f13b4c5..8d50e5d 100644
--- a/tutorial/events.mdwn
+++ b/tutorial/events.mdwn
@@ -1,8 +1,8 @@
-# 10. X Events
+# X Events
 
 In an X program, everything is driven by events. Event painting on the screen is sometimes done as a response to an event (an Expose event). If part of a program's window that was hidden, gets exposed (e.g. the window was raised above other widows), the X server will send an "expose" event to let the program know it should repaint that part of the window. User input (key presses, mouse movement, etc) is also received as a set of events.
 
-###10.1 Registering for event types using event masks
+### 1. Registering for event types using event masks
 
 During the creation of a window, you should give it what kind of events it wishes to receive. Thus, you may register for various mouse (also called pointer) events, keyboard events, expose events, and so on. This is done for optimizing the server-to-client connection (i.e. why send a program (that might even be running at the other side of the globe) an event it is not interested in ?)
 
@@ -63,7 +63,7 @@ If the window has already been created, we can use the xcb\_configure\_window()
 
 Note: A common programmer oversight is adding code to handle new event types while forgetting to add the masks for these events in the creation of the window. This leads to programmers debugging for hours, wondering "Why doesn't my program notice that I released the button?", only to find that they reigstered button press events but not button release events.
    
-### 10.2 Receiving events: writing the events loop
+### 2. Receiving events: writing the events loop
 
 After we have registered for the event types we are interested in, we need to enter a loop of receiving events and handling them. There are two ways to receive events: a blocking way and a non-blocking way:
 
@@ -131,7 +131,7 @@ Comparison Xlib/XCB:
 
 
 
-### 10.3 Expose events
+### 3. Expose events
 
 The Expose event is one of the most basic (and most used) events an application may receive. It will be sent to us in one of several cases:
 
@@ -157,11 +157,11 @@ Expose event definition:
 			uint16_t     count;
 		} xcb_expose_event_t;
 
-### 10.4 Getting user input
+### 4. Getting user input
 
 User input traditionally comes from two sources: the mouse and the keyboard. Various event types exist to notify us of user input (a key being presses on the keyboard, a key being released on the keyboard, the mouse moving over our window, the mouse entering (or leaving) our window, and so on.
 
-###10.4.1 Mouse button press and release events
+##### 4.1 Mouse button press and release events
 
 The first event type we will deal with is a mouse button-press (or button-release) event in our window. In order to register to such an event type, we should add one (or more) of the following masks when we create our window:
 
@@ -210,7 +210,7 @@ Their names are self explanatory, where the first 5 refer to the mouse buttons t
 
 TODO: Problem: it seems that the state does not change when clicking with various buttons.
 
-##### 10.4.2 Mouse movement events
+##### 4.2. Mouse movement events
 
 Similar to mouse button press and release events, we also can be notified of various mouse movement events. These can be split into two families. One is of mouse pointer movement while no buttons are pressed, and the second is a mouse pointer motion while one (or more) of the buttons are pressed (this is sometimes called "a mouse drag operation", or just "dragging"). The following event masks may be added during the creation of our window to register for these events:
 
@@ -240,7 +240,7 @@ These all generate events of this type:
 			uint8_t         same_screen;
 		} xcb_motion_notify_event_t;
 
-##### 10.4.3 Mouse pointer enter and leave events
+##### 4.3. Mouse pointer enter and leave events
 
 Another type of event that applications might be interested in, is a mouse pointer entering a window the program controls, or leaving such a window. Some programs use these events to show the user that the application is now in focus. In order to register for such an event type, we should add one (or more) of the following masks when we create our window:
 
@@ -268,11 +268,11 @@ The structure to be checked for in our events loop is the same for these two eve
 
                   typedef xcb_enter_notify_event_t xcb_leave_notify_event_t;
 
-##### 10.4.4 The keyboard focus
+##### 4.4. The keyboard focus
 
 There may be many windows on a screen, but only a single keyboard attached to them. How does the X server then know which window should be sent a given keyboard input ? This is done using the keyboard focus. Only a single window on the screen may have the keyboard focus at a given time. There is a XCB function that allows a program to set the keyboard focus to a given window. The user can usually set the keyboard focus using the window manager (often by clicking on the title bar of the desired window). Once our window has the keyboard focus, every key press or key release will cause an event to be sent to our program (if it regsitered for these event types...).
 
-##### 10.4.5 Keyboard press and release events
+##### 4.5. Keyboard press and release events
 
 If a window controlled by our program currently holds the keyboard focus, it can receive key press and key release events. So, we should add one (or more) of the following masks when we create our window:
 
@@ -301,7 +301,7 @@ These generate events of the same type, which goes by two names:
 
 TODO: Talk about getting the ASCII code from the key code.
 
-### 10.5 X events: a complete example
+### 5. X events: a complete example
 
 As an example for handling events, we show a program that creates a window, enters an events loop and checks for all the events described above, and writes on the terminal the relevant characteristics of the event. With this code, it should be easy to add drawing operations, like those which have been described above.
 
@@ -396,7 +396,7 @@ As an example for handling events, we show a program that creates a window, ente
 					break;	
 				case XCB_BUTTON_RELEASE: 
 					xcb_button_release_event_t *br = (xcb_button_release_event_t *)event;
-					print_modifiers(release->state);
+					print_modifiers(br->state);
 
 					printf ("Button %d released in window %ld, at coordinates (%d,%d)\n",
 							br->detail, br->event, br->event_x, br->event_y );


More information about the xcb-commit mailing list