Linux Display Software Hierarchy

The X Window System is comprised of a server and one or more clients. The X server generally talks to the hardware (through drivers or otherwise), telling the hardware what to draw and relaying input on to the client. The client is an application, it requests that the server draw output and it receives notification of input from the X server.

A window manager is a client that tends to be the root window, with other windows becoming its children. A window manager generally draws helpful borders and input widgets around many of the child windows to aid distinction of windows and enable user interaction.

GTK+ and Qt are libraries that an application may link that, when running in a X Window System environment, provide a higher level interface to communicating with the X server. In general, your program will create a "tree" of user interface widgets and GTK+ or Qt will communicate (through another library, such as Xlib) with the server to describe how to draw your windows. When input is received from the X server, GTK+ or Qt will convert it into their own widget metaphor and hand it off to your program. Both GTK+ and Qt provide theme mechanisms that actually handle much of the what-pixel-goes-where and unless both theme mechanisms are using a similar style, applications using one will often contrast with applications using the other.

Does that help any?

Great explanation, that even cleared things up for me :)

Yes, that helped immensely. Let me just make sure I understand - the application is programmed using GTK+ and Qt for UI objects like text boxes or buttons or what have you. The application is opened in a window, which is a child object of the window manager that draws the border and controls placement of the window and things like that. The window manager then sends the data on how to draw this border, along with a forwarding of the data on how to draw the application inside the window, to the X server with a request to draw it. The X server then talks to the hardware, writes the data to the area of memory that maps to the screen display, and then lets the display hardware draw it to the screen.

Am I correct? Or have I missed something? I'm most nervous about my interpretation of what GTK+ and Qt do.

Quote:

Original post by EmrldDrgn Yes, that helped immensely. Let me just make sure I understand - the application is programmed using GTK+ and Qt for UI objects like text boxes or buttons or what have you. The application is opened in a window, which is a child object of the window manager that draws the border and controls placement of the window and things like that. The window manager then sends the data on how to draw this border, along with a forwarding of the data on how to draw the application inside the window, to the X server with a request to draw it. The X server then talks to the hardware, writes the data to the area of memory that maps to the screen display, and then lets the display hardware draw it to the screen. Am I correct? Or have I missed something? I'm most nervous about my interpretation of what GTK+ and Qt do.

Your interpretation of what the toolkits (gtk/qt) do is correct: They implement the controls (or widgets, or whatever you want to call them) like buttons, menus, toolbars, etc.

However, the window contents of an application do not go through the window manager. The window manager really only draws the window borders (including the window title) and is responsible for "mapping" windows (i.e. putting them where they belong on the screen).

You can observe this on a slow (or overloaded) machine by how the window contents and the window border are drawn at different times.

Things have become a little more complicated since the introduction of compositing managers. When a compositing manager is active, the window contents and everything the window manager does is drawn into off-screen pixmaps. It is then the compositing manager's job to blit those pixmaps onto the screen. In other words, when a compositing manager is active, the compositing manager is the *only* application that draws directly onto the screen. (This is different from the situation when only a window manager is active.)

It makes sense to have window manager and compositing manager in a single application, and I expect that eventually that will be the only relevant mode of operation; however, it technically need not be the case.

Note that the window manager may also do stuff in addition to drawing the root window and window borders. For example, a window manager may implement Alt+Tab-behaviour and the like.

Quote:

Original post by Prefect However, the window contents of an application do not go through the window manager. The window manager really only draws the window borders (including the window title) and is responsible for "mapping" windows (i.e. putting them where they belong on the screen). You can observe this on a slow (or overloaded) machine by how the window contents and the window border are drawn at different times.

I see. How does this take place? Does the application ask the window manager for acceptable coordinates or something? How does the window manager know where to draw the borders?

That is the responsibility of the X-server. Applications can ask for a new window of a specific size. The X-server creates a new drawing area (window) and gives a reference to that window to the window manager and the application. The window manager puts in in the best spot it can and draws the borders around that area. The application uses the widget toolkit like Qt or GTK to fill the inside of the area.

Just to be clear: the window manager, the X server, and all other GUI applications are all clients. They are peer processes within the OS. A typical X Window appliction (client) knows nothing about the server or the window manager. There is not normally interaction between the window manager and any other X client application.

A window manager is a special X client application, but you only need to know that if you're writing a window manager.

It can and should be possible to run any X client application without a window manager. After all, window managers themselves are just X clients.

Qt and Gtk application should also not know anything about X. Those toolkits are portability layers. Youcan, for example, build and run a Qt-based application on Mac OS X (under Quartz, as opposed to X on X or some other X Window system) or Microsoft Windows (under the native GUI, as opposed to X Windows).

Quote:

Qt and Gtk application should also not know anything about X.

Yes and no. From an application developer point of view this is correct. You use Qt or GTK so you don't have to bother with X.org at all. Under the hood, the Linux versions of Qt and GTK deal a lot with X.org of course.