Learning to Use X11
To understand the next few lines, we have to reconsider one of the basic tenets of X11: it is a networked graphics framework in which the client (such as the program in Listing 1) and the graphics server might reside on physically remote machines. In such a situation, the failure of the network is a possibility that has to be anticipated. The XMapWindow command is issued on the client but executed on the server (note how X11's way of using those terms makes much more sense in the present context), which might not be available when the command is issued. The solution to this situation is to make the client/server communication asynchronous or event-driven. That is, XMapWindow sends its request to the server and returns immediately, without waiting for the completion of the server process. It is then up to the client to poll the server for successful execution of the previous command. The following lines do exactly that.
Lines 24 and 25: first, we need to select what kinds of events (such as mouse clicks, mouse movements, key strokes, etc.) we are interested in. Xlib.h defines a number of bit masks for the different kinds of events that can be bitwise ORed, if we are interested in several kinds of events. Here we are interested in the success of the previous mapping operation, and we therefore select the appropriate bit mask and inform the server of our choice, using XSelectInput. This function overwrites any previous setting with each new call.
Lines 27-30: XNextEvent blocks until an event occurs, sending the program to sleep so it does not consume CPU time while waiting. As a side effect, all non-empty output buffers are flushed with each call to XNextEvent, obviating explicit calls to XFlush. Since the StructureNotifyMask combines several events that are structural changes to the window and not just mapping events, we have to loop until the proper type of event has been reported. (If this presentation leaves questions, don't despair: hopefully a fuller treatment of X11 events will be the subject future articles.)
Lines 33-36: now that we can be certain the window is actually visible on the screen, we are finally ready to draw something to it. First, we define a GraphicsContext (GC), a struct that comprises information about the appearance (such as color, linestyle, etc.) of the graphical elements. Attributes of the GraphicsContext can be set at creation by providing a bit mask specifying the attributes as the third and an array of values as the fourth argument. Alternatively, attributes of the GC can be set individually by calling the appropriate functions.
Lines 39 and 40: draw two lines, forming an X on the screen. There are similar functions to draw points, arcs and rectangles, all taking coordinates relative to the current window. Remember to use these functions only with windows that you know are actually visible, not hidden or minimized. Drawing to an invisible window has no effect.
Lines 43-48: now that the graph (as it is) is complete, the program should wait for the user to click on the window to terminate it. Accordingly, we set the appropriate event mask and wait for the desired event. Note again that XNextEvent flushes all output buffers, so we are certain that the two lines indeed appeared before the mouse-click event occurred.
Lines 51 and 52: part of well-behaved C programming is responsible resource management. We therefore explicitly free the allocated resources, rather than let the program fall off the end and have the operating system clean up after us. As a side effect, XDestroyWindow unmaps the window in question automatically, so it disappears from the screen.
This concludes our analysis of the example program. If the source file is called x1.cc, the compile command would take the form:
g++ -I /usr/X11/include -L /usr/X11/lib -o x1 x1.cc -lX11
I have been using C++ throughout, so that I could use end-of-line comments and define variables wherever I needed them. The compiler option -I instructs the compiler where to look for the include files, while the -L option tells the linker where to find the libraries. The argument -lX11 (which has to go last on the command line) finally instructs the linker to link the library named libX11.so. Depending on your installation, the paths may be different.
The program should compile and run successfully. You may want to experiment with some of the parameter values or add further functionality. Don't be afraid to browse the Xlib documentation for additional functions or obtain more information on those functions used in the example program.
Two crucial issues that I had to omit in this article concern the handling of errors generated by X11, as well as the behavior of the window's contents when the window is resized, or minimized and maximized again (try it out). We will cover them and much more in future articles, when we take a closer look at X11 events.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide