Misplaced Pages

#9990

39-556: Few applications use Xlib directly; rather, they employ other libraries that use Xlib functions to provide widget toolkits : Xlib appeared around 1985, and is used in GUIs for many Unix-like operating systems . A re-implementation of Xlib was introduced in 2007 using XCB . The main types of data in Xlib are the Display structure and the types of the identifiers. Informally, a display

78-673: A cascading manner, with graphical control elements being added directly to on top of one another. Most widget toolkits use event-driven programming as a model for interaction. The toolkit handles user events , for example when the user clicks on a button . When an event is detected, it is passed on to the application where it is dealt with. The design of those toolkits has been criticized for promoting an oversimplified model of event-action, leading programmers to create error-prone, difficult to extend and excessively complex application code . Finite state machines and hierarchical state machines have been proposed as high-level models to represent

117-446: A main loop. The get_next_message() routine is typically provided by the operating system, and blocks until a message is available. Thus, the loop is only entered when there is something to process. Under Unix , the " everything is a file " paradigm naturally leads to a file-based event loop. Reading from and writing to files, inter-process communication, network communication, and device control are all achieved using file I/O, with

156-406: A program, as it often does, it may be termed the main loop or main event loop . This title is appropriate, because such an event loop is at the highest level of control within the program. Message pumps are said to 'pump' messages from the program's message queue (assigned and usually owned by the underlying operating system) into the program for processing. In the strictest sense, an event loop

195-432: A signal arrives immediately between checking the flag and calling select() , it will not be handled until select() returns for some other reason (for example, being interrupted by a frustrated user). The solution arrived at by POSIX is the pselect () call, which is similar to select() but takes an additional sigmask parameter, which describes a signal mask . This allows an application to mask signals in

234-510: A single- threaded web browser process. The browser process deals with messages from a queue one at a time. A JavaScript function or another browser event might be associated with a given message. When the browser process has finished with a message, it proceeds to the next message in the queue. On the Microsoft Windows operating system, a process that interacts with the user must accept and react to incoming messages, which

273-400: A specific channel. Operations of this kind include for example operations on the event queue, which is described below. Windows, colormaps, etc. are managed by the server, which means that the data about their actual implementation is all stored in the server. The client operates on these objects by using their identifiers . The client cannot directly operate on an object, but can only request

312-444: A visible effect on the screen. The request buffer is guaranteed to be flushed (i.e., all requests done so far are sent to the server) after a call to the functions XSync or XFlush , after a call to a function that returns a value from the server (these functions block until the answer is received), and in some other conditions. Xlib stores the received events in a queue. The client application can inspect and retrieve events from

351-406: A window with a little black square in it: The client creates a connection with the server by calling XOpenDisplay . It then requests the creation of a window with XCreateSimpleWindow . A separate call to XMapWindow is necessary for mapping the window, that is, for making it visible on the screen. The square is drawn by calling XFillRectangle . This operation can only be performed after

390-418: Is a physical or virtual device where graphical operations are done. The Display structure of the Xlib library contains information about the display, but more importantly it contains information relative to the channel between the client and the server. For example, in a Unix-like operating system, the Display structure contains the file handle of the socket of this channel (this can be retrieved using

429-403: Is almost inevitably done by a message loop in that process. In Windows, a message is equated to an event created and imposed upon the operating system. An event can be user interaction, network traffic, system processing, timer activity, inter-process communication, among others. For non-interactive, I/O only events, Windows has I/O completion ports . I/O completion port loops run separately from

SECTION 10

#1732797640010

468-463: Is an alternative to Xlib. Its two main aims are: reduction in library size and direct access to the X11 protocol. A modification of Xlib has been produced to use XCB as a low-level layer. Widget toolkit A widget toolkit , widget library , GUI toolkit , or UX library is a library or a collection of libraries containing a set of graphical control elements (called widgets ) used to construct

507-455: Is intended to avoid. An alternative, more portable solution, is to convert asynchronous events to file-based events using the self-pipe trick , where "a signal handler writes a byte to a pipe whose other end is monitored by select() in the main program". In Linux kernel version 2.6.22, a new system call signalfd() was added, which allows receiving signals via a special file descriptor. A web page and its JavaScript typically run in

546-436: Is no event in the queue. Xlib does not provide support for buttons, menus, scrollbars, etc. Such widgets are provided by other libraries, which in turn use Xlib. There are two kinds of such libraries: Applications using any of these widget libraries typically specify the content of the window before entering the main loop and do not need to explicitly handle Expose events and redraw the window content. The XCB library

585-503: Is not safe to call Xlib functions from a signal handler, because the X application may have been interrupted in an arbitrary state, e.g. within XNextEvent . See [1] for a solution for X11R5, X11R6 and Xt. The GLib event loop was originally created for use in GTK but is now used in non-GUI applications as well, such as D-Bus . The resource polled is the collection of file descriptors

624-490: Is one of the methods for implementing inter-process communication . In fact, message processing exists in many systems, including a kernel-level component of the Mach operating system . The event loop is a specific implementation technique of systems that use message passing . This approach is in contrast to a number of other alternatives: Due to the predominance of graphical user interfaces , most modern applications feature

663-404: Is therefore made inside the loop handling the events . Before entering this loop, the events the application is interested in are selected, in this case with XSelectInput . The event loop waits for an incoming event: if this event is a key press, the application exits; if it is an expose event, the window content is drawn. The function XNextEvent blocks and flushes the request buffer if there

702-466: The ConnectionNumber macro.) Most Xlib functions have a Display structure as an argument because they either operate on the channel or are relative to a specific channel. In particular, all Xlib functions that interact with the server need this structure for accessing the channel. Some other functions need this structure, even if they operate locally, because they operate on data relative to

741-422: The event loop (also known as message dispatcher , message loop , message pump , or run loop ) is a programming construct or design pattern that waits for and dispatches events or messages in a program . The event loop works by making a request to some internal or external "event provider" (that generally blocks the request until an event has arrived), then calls the relevant event handler ("dispatches

780-420: The graphical user interface (GUI) of programs. Most widget toolkits additionally include their own rendering engine . This engine can be specific to a certain operating system or windowing system or contain back-ends to interface with multiple ones and also with rendering APIs such as OpenGL , OpenVG , or EGL . The look and feel of the graphical control elements can be hard-coded or decoupled, allowing

819-520: The GLib event loop include GStreamer and the asynchronous I/O methods of GnomeVFS , but GTK remains the most visible client library. Events from the windowing system (in X , read off the X socket ) are translated by GDK into GTK events and emitted as GLib signals on the application's widget objects. Exactly one CFRunLoop is allowed per thread, and arbitrarily many sources and observers can be attached. Sources then communicate with observers through

SECTION 20

#1732797640010

858-518: The Message loop, and do not interact with the Message loop out of the box. The "heart" of most Win32 applications is the WinMain() function, which calls GetMessage() in a loop. GetMessage() blocks until a message, or "event", is received (with function PeekMessage() as a non-blocking alternative). After some optional processing, it will call DispatchMessage() , which dispatches the message to

897-416: The application is interested in; the polling block will be interrupted if a signal arrives or a timeout expires (e.g. if the application has specified a timeout or idle task). While GLib has built-in support for file descriptor and child termination events, it is possible to add an event source for any event that can be handled in a prepare-check-dispatch model. [2] Application libraries that are built on

936-464: The client for requesting other operations on the same window to the server. The identifiers are unique to the server. Most of them can be used by different applications to refer to the same objects. For example, two applications connecting with the same server use the same identifier to refer to the same window. These two applications use two different channels, and therefore have two different Display structures; however, when they request operations on

975-566: The event queue, whereupon the application processes it appropriately. The Xlib event loop only handles window system events; applications that need to be able to wait on other files and devices could construct their own event loop from primitives such as ConnectionNumber , but in practice tend to use multithreading . Very few programs use Xlib directly. In the more common case, GUI toolkits based on Xlib usually support adding events. For example, toolkits based on Xt Intrinsics have XtAppAddInput() and XtAppAddTimeout() . Please note that it

1014-475: The event"). It is also commonly implemented in servers such as web servers . The event-loop may be used in conjunction with a reactor , if the event provider follows the file interface , which can be selected or 'polled' (the Unix system call, not actual polling ). The event loop almost always operates asynchronously with the message originator. When the event loop forms the central control flow construct of

1053-400: The few things in Unix that does not conform to the file interface are asynchronous events ( signals ). Signals are received in signal handlers , small, limited pieces of code that run while the rest of the task is suspended; if a signal is received and handled while the task is blocking in select() , select will return early with EINTR ; if a signal is received while the task is CPU bound ,

1092-400: The graphical control elements to be themed / skinned . Some toolkits may be used from other languages by employing language bindings . Graphical user interface builders such as e.g. Glade Interface Designer facilitate the authoring of GUIs in a WYSIWYG manner employing a user interface markup language such as in this case GtkBuilder . The GUI of a program is commonly constructed in

1131-515: The interactive state changes for reactive programs. A window is considered to be a graphical control element. In some windowing systems, windows are added directly to the scene graph (canvas) by the window manager , and can be stacked and layered on top of each other through various means. Each window is associated with a particular application which controls the widgets added to its canvas, which can be watched and modified by their associated applications. Event loop In computer science ,

1170-400: The main task, then remove the mask for the duration of the select() call such that signal handlers are only called while the application is I/O bound . However, implementations of pselect() have not always been reliable; versions of Linux prior to 2.6.16 do not have a pselect() system call, forcing glibc to emulate it via a method prone to the very same race condition pselect()

1209-463: The order that they were perceived by the system and its peripherals. This guarantee is essential when considering the design consequences of multithreaded applications. However, some messages have different rules, such as messages that are always received last, or messages with a different documented priority. X applications using Xlib directly are built around the XNextEvent family of functions; XNextEvent blocks until an event appears on

Xlib - Misplaced Pages Continue

1248-419: The queue. While the X server sends events asynchronously, applications using the Xlib library are required to explicitly call Xlib functions for accessing the events in the queue. Some of these functions may block; in this case, they also flush the request buffer. Errors are instead received and treated asynchronously: the application can provide an error handler that will be called whenever an error message from

1287-594: The relevant handler, also known as WindowProc . Normally, messages that have no special WindowProc() are dispatched to DefWindowProc , the default one. DispatchMessage() calls the WindowProc of the HWND handle of the message (registered with the RegisterClass() function). More recent versions of Microsoft Windows guarantee to the programmer that messages will be delivered to an application's message loop in

1326-420: The same identifier, these operations will be done on the same object. The Xlib functions that send requests to the server usually do not send these requests immediately but store them in a buffer, called the request buffer . The term request in this case refers to the request from the client that is directed to the server: the request buffer can contain all kinds of requests to the server, not only those having

1365-408: The server is received. The content of a window is not guaranteed to be preserved if the window or one of its parts are made not visible. In this case, the application is sent an Expose event when the window or one part of it is made visible again. The application is then supposed to draw the window content again. The functions in the Xlib library can be grouped in: The following program creates

1404-444: The server to perform the operation specifying the identifier of the object. The types Windows , Pixmap , Font , Colormap , etc. are all identifiers, which are 32-bit integers (just as in the X11 protocol itself). A client 'creates' a window by requesting that the server create a window. This is done via a call to an Xlib function that returns an identifier for the window, that is, a number. This identifier can then be used by

1443-421: The target identified by a file descriptor . The select and poll system calls allow a set of file descriptors to be monitored for a change of state, e.g. when data becomes available to be read. For example, consider a program that reads from a continuously updated file and displays its contents in the X Window System , which communicates with clients over a socket (either Unix domain or Berkeley ): One of

1482-404: The task will be suspended between instructions until the signal handler returns. Thus an obvious way to handle signals is for signal handlers to set a global flag and have the event loop check for the flag immediately before and after the select() call; if it is set, handle the signal in the same manner as with events on file descriptors. Unfortunately, this gives rise to a race condition : if

1521-399: The window is created. However, performing it once may not be enough. Indeed, the content of the window is not always guaranteed to be preserved. For example, if the window is covered and then uncovered again, its content might require being redrawn. The program is informed that the window or a part of it has to be drawn by the reception of an Expose event. The drawing of the window content

#9990