X windows tutorial programı

Abstract

Bu projenin amacı, en basit şekliyle bir X kullanıcısına X'in yapısı ve programlanması hakkında bilgi sunan bir X Windows tutorial programının tasarlanıp gerçekleştirilmesidir. Projenin içerdiği konular şu şekilde özetlene bilir: X Windows için genel kavramların verilmesi, X rutinleri, grafik içeriği, pencerede yazı çizimi, ekranda karakterlerin basımı, olaylar ve renk kullanımı

In September 1987, the Massachuttes.Instute of Technology released the first snapshot of what may well become one of the most significant software technologies of the 1990s: Version 11 of the X Window System, commonly referred to as Xll. Xll may not change the world, but it is likely to change the world of workstations. The X Window System is being adopted as a standard by nearly every workstation manufacturer and should eventually replace or be supported un der their proprietary windowing systems. Versions will also be available for personal computers and supercomputers. For the first time, portable applications can be written for an entire class of machines rather than for a single manufacturer's equipment. Programmers can write in a single graphics language and expect their applications to work without significant modifications on dozens of different computers. What's more, since X is a network-based windowing system, applications can run in a network of systems from different vendors. Programs can be run on a remote computer, and the results displayed on a local workstation. Pro prietary networks have been around for a while. However, network cooperation of different computers has been held up by the lack of a common applications language. Now there is one. Vendors hope that X will lead to a software explosion similar to the one that occured in response to the PC standard on microcomputers. X Window System Concepts: The X Window System is complex, bur it is based on a few premises that can be quickly understood. This section describes these major concepts. Displays and Screens: The first and most obvious thing to note about X is that it is a win dowing system for bitmapped graphics displays. It supports color as well as monochrome and gray-scale displays. A slightly unusual feature is that a display is defined as a workstation consisting of a keyboard, a pointing device such as a mouse, and one or more screens. Multiple screens can work together, with mouse movement allowed to vi cross physical screen boundaries. As long as multiple screens are controlled by a single keyboard and pointing device, they comprise only a single display. The Server-Client Model: The next thing to note is that X is a network-oriented windowing system. An application need not be running on the same system that actually supports the display. While many applications can execute locally on a workstation, other applications can execute on other machines, sending requests across the network to a particular display and receiving keyboard and pointer events from the system controlling the display.,. At this point, only TCP/IP and DECnet networks are supported by the X consortium and most vendors, though that may change before long. The program that controls each display is known as a server. At first, this usage of the term server may seem a little odd - when you sit a workstation, you tend to think of a server as something across the network (such as a file or print server) rather than the local program that controls your own display. The thing to remember is that your display is accessible to other systems across the network, and for those systems, the code executing in your system does act as a true display server. The server acts as an intermediary between user programs (called clients or applications) running on either the local or remote systems and the resources of the local system. The server (without extensions) performs the following tasks:. Allows access to the display by multiple clients.. Interprets network messages from clients.. Passes user input to the clients by sending network messages.. Does two-dimensional drawing-graphics are performed by the display server rather than by the client.. Maintains complex data structures, including windows, cursors, fonts, and "graphics context" as resources that can be shared between clients and referred to simply by resource IDs;- Server-maintained resources reduce the amount of data that has to be maintained by each client and the amount of data that has to be transferred over the network. Since the X Window System makes the network transparent to clients, these programs may connect to any display in the network if the host thay are running on has permission from the server that controls that display. In a network environment, it is common for a user to have programs running on several different hosts in the netwrok, all invoked from and displaying their windows on a single screen. In practice, each user is sitting at a server and can start applications locally to display on the local server or can start applications on remote hosts for display on the local server, if the remote hosts have permission to connect to vii / ı the local server. All other users in the network are in a similar situation - they can run applications on their own system or on yours, but they will, for the most part, be displaying on their own server. This use of the network is known as distributed processing. Distributed processing helps solve the problem of unbalanced system loads. When one host machine is overloaded, the users of that machine can arrange for some of their programs to run on other hosts. One extreme of this arrangement is the PC server or X terminal. Because these single-task systems can run only the X server (and sometimes a window manager), a user sitting at one of these servers must run all clients on systems across the network, with their results displayed on the PC or X terminal screen. This makes the single-tasking PC or X terminal look and work just like X on a multitasking workstation. Window Management: Another important concept in X programming is that applications do not actually control such things as where a window appears or what size it is. Given multiprocessor, multiclient access to the same workstation display, clients must not be dependent on a particular window configuration. Instead, a client gives hints about how long and where it would like to be displayed. The screen layout or appearance and the style of user interaction with the system are left up to a separate program, called the window manager. The window manager is just another program written with Xlib, except that it is given special authority to control the layout of windows on the screen. The window manager typically allows the user to move or resize windows, start new applicationss, and control the stacking of windows on the screen, but only according to the window manager's window layout policy. A window layout policy is a set of rules that specify allowable sizes and positions of windows and icons. Unlike citizens, the window manager has rights but not responsibilities. Programs must be prepared to cooperate with any type of window manager or with none at all (there are fairly simple ways to prepare programs for these contingencies). The simple window manager twm does not enforce any window layout policy, but clients should still assume that there could be one. For example, the window manager must be informed of the desired size of a new window before the window is displayed on the screen. If the window manager does not accept the desired window size and position, the program must be prepared to accept a diffrent size or position or be able to display a message such as "Too small!" X is somewhat unusual in that it does not mandate a particular type of window manager. Its developers have tried to make X itself as free of window management or user interface policy as possible. And, while the XI 1 distribu tion includes twm as a sample window manager, individual manufactures are expected to write their own window managers and user interface guidelines. In fact, two commercial window managers with user interface guidelines are viii already becoming established. They are olwm, the OPEN LOOK window man ager from AT&T and Sun, and mwm, the Motif window manager from Open Software Foundation. The OSF Motif window manager, mwm, and OPEN LOOK window manager olwm both can be configured to be real-estate-driven or click-to- type. Events: As in any mouse-driven window system, an X client must be prepared to respond to any of many different events. Events include user input (keypress, mouse click, or mouse movement) as well as interaction with other programs. (For example, if an obscured portion of a window is exposed when another overlapping window is moved, closed, or resized, the client must redraw it.) Events of many different types can occur at 'any time and in any order. They are placed on a queue in the order they occur and usually are processed by clients in that order. Event- driven programming makes it natural to let the user tell the program what to do instead of vice versa. The need to handle events is a mojor difference between programming under a window system and traditional UNIX or PC programming. X pro grams do not use the standard C functions for getting charaters, and they do not poll for input. Instead there are functions for receiving events, and then the program must branch according to the type of event and perform the ap propriate response. But unlike traditional programs, an X program must be ready for any kind of event at any time. In traditional programs the program is in control, asking for certain types of input at certain times. In X programs, the user is in control most of the time. Overview of X Windows: The heart of the X Windows system consists of a program called X which runs on a machine with a display, keyboard, and a mouse. It waits for other programs to tell it what to do or for something to happen to the pointer or keyboard. The programs can be running on the same machine as X is or elsewhere on the network, maybe on a machine that hasn't even got a display of its own. This 'network transparency' is one of the strengths of X. Graphics programs only have to know about X, not about the special low level graphics commands for each type of machine. The client programs communicate to X, the server, via a Protocol language that is common across machine types. All a client program needs to do use the X display is to open up a connec tion with the server and then send Protocol requests to it. To simplify sending these, an extensive library of about 200 display subroutines is provided and it is this library, Xlib, which this thesis mainly decribes. Many client programs can simultaneously use the same X server. To save each client having its own copy of fonts, color information, etc, (thereby wasting space and causing more data to be passed via the network), the server stores data on behalf of the clients, allowing sharing wherever possible. In order ix to enable the client to reference these resources the server provides resource codes and these can be used in many of the routines to specify that certain data is to be used. X is 'event driven'. For each window you create you can select what sort of events (key presses, re-exposure, etc) you want it to respond to. Typically, an X program consists of a set-up sequence followed by an 'event-loop' which waits for events to be reported by the server, determines what sort of event has happened and in which window, then processes the event. There are 4 types of messages passing between the client and server;. Requests - the client can ask the server to draw something, or ask for information.. Replies - the server can reply. Events - the server can surprize the client with something. Errors - the server can report an error Both display requests and events are buffered and the server executes asyn chronously much of the time to meximise efficent use of the network. When the client wishes to establish syncronization it often has to ask for it, though working in syncronized mode can be up to 30 times slower. X clients programs should be written mindful of the fact that other clients are likely to be running at the same time. Windows should be prepared to be covered over by others then exposed, and they have to redraw themselves. Nei ther should clients indescriminately use scarce resources like off-screen memory or monopolise the keyboard or pointer. If they can accept cut-and-paste op erations, so much the better. One client that is always likely to be running is a 'window manager'; a program which allows you to resize, move and re-stack windows, pop menus up, etc. Any X application you write will need to work under a window manager. Some window managers are more bossy than others (some won't let you raise windows, for instance), but there are X commands so that a client can at least make suggestions to the window manager. X can support one or more screens containing overlapping (sub)windows and works on many types of hardware but it doesn't provide high level support. If you want to prefabricate dialog boxes form pre-defined scrollbars, buttons, etc then you should use a 'toolkit' that sits on top of X. This thesis has 7 chapters. The information about the chapters are fol lowing: Chapter 1 Introduction: describes about X system concepts, X windows ver sions, displays and screens, client-server models, windows manage ment, events, extension to X, X windows system software architec ture. Chapter 2 X Routins: describes about opening a display server, finding out about the display, creating & destroying windows, mapping, moving & uncovering windows and defining bitmaps and pixmaps. Chapter 3 Graphics Context: describes graphics context and how to use it. Chapter 4 Rectangles, Lines, Dots, Arcs and Text: decribes about drawing rectangles, lines, dots, arcs and text in a window, finding the witdh of characters, printing characters on the screen, creating cursors. Chapter 5 Events: describes about events, event types and keyboard encoding. Chapter 6 Using Color: describes about colors, allocating color and read-only color cells. Chapter 7 XI 1 Tutorial Program: describes about xlltutor program including source code information and how it is used.