I'm confused as to what software is responsible for what aspect of display in Linux. It seems like the window manager is responsible for the "look 'n feel" of the windows, but I also know (or think I do) that there are two major toolkits for Linux, gtk+ and qt, and I'm not sure what aspects of appearance they affect. Further down the line is the X Window System, and I'm frankly not sure what that actually does at all. And ultimately, everything has to be passed to some sort of unified kernel-level drawing routine, right? Can someone please clarify for me how this works? Thanks.

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.