x window system's architecture and understanding of its design

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Here we have discussion about X Window System's architecture and try to give a better understanding of its design, which components integrate with X and fit together to provide a working graphical environment and what choices are there regarding such components as window managers, toolkits and widget libraries and desktop environments.

This document aims to provide an brief overview of the X Window System's architecture and description about tk-toolkit as well GNOM using gtk+ toolkits, hoping to give a better understanding of why it's designed the way it's designed, which components integrate with X and fit together to provide a working graphical environment and what choices are there regarding those components. Also try to demonstrate the concept of tcl and tk through linux.

It would extend the world that cognitive models can see if models could interact based on an interface language. We introduce a system designed to allow cognitive models to interact with any display written in Tcl/Tk, a common interface creation language. This approach can be viewed as extending cognitive architectures to include eyes and hands that exist in the world of Tcl/Tk. This system is most naturally used by Soar because Soar includes Tcl/Tk, but the eye/hand could be used by other architectures. We demonstrate an initial model that uses independently created on-screen phones. This model does the task itself and more accurately predicts a task time than GOMS. Findings from the implementation of Soar/Tcl-PM are used to explore current limitations of GOMS-type task analysis methodologies, possibilities for enhancing the communication between Soar and Tcl/Tk, and data gathering requirements for future cognitive modelling in this area.


Before taking a look at X's architecture, a really brief tour of its history, and how it ended up on your Linuxsystem, is in order.

X was developed by the Athena project, and released in 1984. In 1988 an entity called the "X Consortium" took over X, and to this day handles its development and distribution. The X specification is freely available, this was a smart move as it has made X almost ubiquitous. This is how XFree86 came to be. XFree86 is the implementation of X we use on our Linux computers. XFree86 also works on other operating systems, like the *BSD lineage, OS/2 and maybe others. Also, despite its name, XFree86 is also available for other CPU architectures.

Unix has been a multiuser, multitasking, timesharing operating system since its beginnings. Also, since the incorporation of networking technologies, it's had the ability to allow a user to connect remotely and perform work on the system. Previously this was accomplished either via dumb serial terminals, or network connections

When the time came to develop a GUI system that could run primarily under Unix, these concepts were kept in mind and incorporated into the design. Actually, X has a pretty complex design, which has often been mentioned as a disadvantage. However, because of its design, it's also a really versatile system, and this will become quite clear as we explain how all the parts comprising a GUI under Unix fit together.

The X Window System Architecture:

X was designed with a client−server architecture. The applications themselves are the clients; they communicate with the server and issue requests, also receiving information from the server.

The X server maintains exclusive control of the display and services requests from the clients. At this point, the advantages of using this model are pretty clear. Applications (clients) only need to know how to communicate with the server, and need not be concerned with the details of talking to the actual graphics display device. At the most basic level, a client tells the server stuff like "draw a line from here to here", or "render this string of text, using this font, at this position on screen".

This would be no different from just using a graphics library to write our application. However the X model goes a step further. It doesn't constrain the client being in the same computer as the server. The protocol used to communicate between clients and server can work over a network, or actually, any "inter process communication mechanism that provides a reliable octet stream". Of course, the preferred way to do this is by using the TCP/IP protocols. As we can see, the X model is really powerful; the classical example of this is running a processor intensive application on a Cray computer, a database monitor on a Solaris server, an e−mail application on a small BSD mail server, and a visualization program on an SGI server, and then displaying all those on my Linux workstation's screen.

Since the widget library is the one actually drawing the elements on screen, as well as interpreting user's actions into input, the library used is largely responsible for each client's aspect and behavior. From a developer's point of view, a widget library also has a certain API (set of functions), and that might define which widget library want to use.

Toolkits or Widget Libraries

The original widget library, developed for the Athena Project, is of course the Athena widget library, also known as Athena Widgets. It's very basic, very ugly, and the usage is not intuitive by today's standards (for instance, to move a scrollbar or slider control, you don't drag it; instead, you click the right button to scroll up and the left button to scroll down). As such, it's pretty much not used a lot these days.

Just as it happens with window managers, there are a lot of toolkits, with different design goals in mind. One of the earliest toolkits is the well known Motif, which was part of the Open Software Foundation's Motif graphical environment, consisting of a window manager and a matching toolkit. The OSF's history is beyond the scope of this document. the Motif toolkit, being superior to the Athena widgets, became widely used in the 1980's and early 1990's. These days, Motif is not a popular toolkit choice. It's not free (speech), and OSF Motif costs money if you want a developer license (i.e. to compile your own programs with it), although it's OK to distribute a binary linked against Motif. Perhaps the best known Motif application, for Linux users at least, is Netscape Navigator/Communicator. For a while Motif was the only decent toolkit available, and there's a lot of Motif software around. Of course people started developing alternatives, and there are plenty of toolkits, such as XForms, FLTK and a few others.

Motif is not heard of much these days, specially in the free software world. The reason is that there are now better alternatives, in terms of licensing, performance (Motif is widely regarded as quite a pig) and features. One such toolkit, the widely known and used Gtk, was specifically created to replace Motif in the GIMP project (one possible meaning of Gtk is "GIMP ToolKit, although, with its widespread use, it could be interpreted as the GNU ToolKit). Gtk is now very popular because it's relatively lightweight, feature rich, extensible and totally free (speech). The 0.6 release of the GIMP included "Bloatif has been zorched" in the changelog. This sentence is a testament to Motif's bloatedness.

Another very popular toolkit these days is Qt. It was not too well−known until the advent of the KDE project, which utilizes Qt for all its GUI elements. We certainly won't get into Qt's licensing issues and the KDE/GNOME disjunctive. Gtk gets a lengthy mention because its history as a Motif replacement is interesting; Qt gets a brief mention because it's really popular. Finally, another alternative worth mentioning is LessTif. The name is a pun on Motif, and LessTif aims to be a free, API−compatible replacement for Motif. It's not clear to what extent LessTif aims to be used in new development, rather than just helping those with Motif code use a free alternative while they (conceivably) port their apps to some other toolkit.

Introduction to tk and tcl:

If we ever rebuilt your Linux kernel inside X using the command make xconfig we surely managed to face the strength of this simple but powerful scripting language.

After executing the first step of kernel rebuilding, a script called kconfig.tk is executed via wish (the Tcl intepreter). The Linux Kernel Configuration wind ow appears. Instead of answering a series of questions, this X−based configuratio n utility allows you to use checkboxes to select which kernel options you want to enable. The system stores your last configuration options so that every time you run it, you need only to add or remove some checks and you don't need to reent er the whole set of option. Moreover you can fill the whole (or part of the) list of kernel option the order you want. After this simplified step you can rebuil d your kernel in the traditional way.

Everything is achieved by using Tcl/Tk as a "glue" between consolidated application and operating with normal Linux configuration files in a visual and interactive window under X−Window. No new application specific commands were written at all.

In order to understand the abc of Tcl/Tk you shouldn't be a programming−guru, command sintax is very Simple. Basically you have to be familiar with:

· simple programming concepts;

· using very common unix commands and/or utilities;

· having access to the Internet;

· using ftp.

Tk/tcl history

Tcl/Tk originated with Dr. John Ousterhout while teaching at University of California, Berkeley, Califor nia. He actually started implementing it when he got back to Berkeley in the spring of 1988; by summer of that year it was in use in some internal applications, but there was no Tk.


· 1989: The first external releases of Tcl and beginning of Tk imp lemention;

· 1991: First release of Tk;

·1994: Dr. Ousterhout was hired by Sun Microsystems, Inc.: he was a Distinguished Engineer and led the Tcl project.

· April/May 1997: the Sun research group responsible for Tcl devel opment were spun off into a Sun business group called SunScript. However, things chan ged again soon afterwards.

· August 1997: a Tcl Consortium was formed.

·February 1998: Dr. Ousterhout left Sun to create Scriptics, a company dedicated to scripting tools, applications, and services. core Tcl and Tk remain free, with the team at Sun continuing work right now on Tcl/Tk 8.1. After the next release, the intention is that work on the core will migrate from Sun to Scriptics, with the Sun team will focus more on Tcl extensions and applications.

· April 23, 1998: the Association for Computing Machinery ACM awarded the 1997 Software System Award to John Ousterhout and Scriptics . This award is given to an institution or individual recognized for developing a software system that has had a lasting influence, reflected in contributions to concept s, in commercial acceptance, or both.

What is Tk?

Tk (pronounced "tee−kay") is an extension to Tcl which provides the programmer with an interface to the X11 windowing system . Note that Tk has been successf ully compiled under X11 R4, X11 R5, X11 R6, as well as Sun's NeWS/X11 environments.

Many users will encounter Tcl/Tk via the "wish" command. Wish is a simple windowing shell which permits the user to write Tcl/Tk applications in a proto typing environment. At present Tcl/Tk cannot handle Japanese, Chinese, Korean, .... language fonts.


Since Tcl is so easy to extend, many try to share extensions, including the popular itcl, [incr Tcl], ObjectTcl, TclX, Tix , and BLT.

These extensions, of course, require an extended Tcl interpreter. Moreover, many Tcl free applications require a particular Tcl extension to run. One of the most popular extension is called Expect. It allows you to place a friendly front−end inside most command−line based UNIX applications, such as ftp, telnet, rlogin, passwd, fsck, and so on.

Supported Platforms

This section contains information about Tcl 8.0 and Tk 8.0, the most recent version of Tcl/Tk. They were originally released on August 18, 1997 and the most recent patch releases (8.0.3) were made on September 3, 1998. When you download Tcl and Tk you get two programs, wish and tclsh, supporting script libraries, and on−line reference documentation. These programs are gene ral purpose platforms for writing applications with Tcl. Wish includes the graphic al user interface toolkit Tk. The packages are ready to use after installation.

Tcl 8.0 and Tk 8.0 run on most releases of the following operating systems:

· Windows 95

· Windows NT

· Solaris and SunOS

· Linux




· Digital Unix


· SCO Unix

· Most other Unix−like operating systems Macintosh (68K and Power Mac)

· Pre−compiled releases are available for different Linux distribution.

Tcl/Tk working module

Tcl is a script based programming language similar to shell, awk, and perl scripts that works well with numerical expressions. Tk is a X like windowing toolkit similar to Xt and Motif Tkinter is the "TK interface" for other languages: Perl, Python, Ruby ... Tcl/Tk ("tickle") is an alternative method for developing X applications. There are ports of tcl/tk to MS Windows and Mac OS...

$ wish < myFile

when wish is not in /usr/local/bin or appropriate PATH set for OS

#!/usr/local/bin/wish -f button .b -text "Hello, world!" -command exit

pack .b

The above script will create a window with a labelled button. Clicking on the button will execute the exit command. wish is a tcl Window Interpretter Shell b is a widget instance of the button widget class, a child of (.) toplevel (assumed) pack "manages/maps" .b as a child of toplevel

See <yourTclPath>\Demos\TK8.4\widgets.tcl

Create Widgets

Each widget occupies a window.Each widget has a class (use) and options frame (group widgets) relief, borderwidth, color, foreground,

background (all widgets have these options)

toplevel (interface with window manager) screen

label (display text, bitmaps) text, font, bitmap

button, checkbutton, radiobutton (respond to button events)

text, variable or value (radiobutton sets),

command (callback procedure)

message (display multiline strings) width, aspect, justify, text

listbox (collection of strings -- entries)

scanning (mouse 2 drag moves entries like scrollbar),

commands (entry insert, delete, get (retrieve)

scrollbar (cont rols view in other widgets) TK 5

yscroll, xscroll, command, orient (default vertical)

scale (edit variable values via slider)

length, from, to, tickinterval, command

entry (text edit) commands (insert, delete) index, icursor, textvariable, width

menubutton (buttons on menubar, menus are added to menubuttons).

menu (menubar selections, entries that can be added) entries are:

command, checkbutton, radiobutton, cascade, separator.

menus also have post. (with dialogs can be pop ups).

underline (keyboard accel), label, text,color, accelerator

canvas (drawing area) create (circles, rectangles,lines, text,

bitmaps, widgets), tags and identifiers (ways to manipulate canvas items with events)

text (text field display and edit multiline text) insert, delete ...

Geometry - pack

Tcl/Tk uses a "master/slave" terminology to describe parent/child window management.

pack is the packer command (do layout mgmt).

Options are:

after or before widget

expand boolean (1, default is false 0) slave absorbs extra space fill describes how to expand (x, y, both, default is none)

in determines who master is (default is widgets parent)

master must be parent or descendant of parent.

ipadx, ipady specifies distance for internal padding inside slave (0)

padx, pady specifies external padding (outside slave inside container)

side specifies attachment (top (default), bottom, left or right)

Frames are used for hierarchical packing layouts.

Events - bind

Events can be bound to widgets.

Key, KeyPress, KeyRelease, Button, ButtonPress, ButtonRelease, Enter, Leave, Motion,

Example button event bindings for .b

bind .b <Enter> {.b config -state active}

bind .b <Leave> {.b config -state normal}

Event Patterns <modifier of event>

Modifiers: Control, Shift, Lock, Any, Meta, Button1..5, B1..5, Double, Triple

<Any-B1-Motion> any button1 motion

<KeyPress-a> pressing key a

Actions bound to event

Script substitution enables event specific information to be returned to application. there are 30 substitutions ..

%x, %y x and y coordinates of event

%W path name of event window

%K keysym from event (KeyPress...)

%A 8 bit iso character value of KeyPress

%% substitute the % character

bind .aCanvas <ButtonPress> {set x point %x set y point %y }

update is a command that enables tcl scripts to escape from a procedure, process all waiting events, and then return to script. tkwait command can be used to force an application to wait for a response from a window before continuing (modality) tkwait window .dlg