Hacker News Reader

Comment by naner | Hacker News Reader

GTK3 is a widget toolkit. Most window managers, especially tiling window managers, don't draw any widgets (or draw their own simple widgets when necessary). The window managers that are part of the Gnome desktops (Metacity, Gnome Shell, Unity) do link with the respective versions of GTK (GTK2 for Metacity, GTK3 for the other two) to draw menus, etc.

All X11 window managers are capable of managing GTK3 applications.

View on HN

A caveat: GTK3 brought a lot of changes in GTK/GDK internals including how window sizing was handled, both based on widget size requirements and based on user interactions for resizing. This was intended in part to provide better support for WM paradigms like Windows and Wayland where clients have more control of their own size, and resulted in UI additions like resize grips by default in the corner of windows. It also cleaned up the code to be less semantically tied to X11's windowing rules. In many cases it's more efficient to use a single toplevel window and do logic application-side than make the X server work harder (due to context switches and changes in rendering codepaths).

The downside to these changes is that several GTK3 features were horribly broken outside of GNOME's default window manager. I've seen at least five or six window managers that would freeze applications with the mouse grabbed as of GTK3.2: click on the wrong part of a menubar or on the resize corner and you had to resort to the keyboard to kill the offending application before it or your mouse would work. Version 3.4 or thereabouts has fixed these bugs for the most part; even window managers that don't support much in the way of ClientMessage-based window manager protocols should work fine now. But for some time GTK3 did interact very poorly with most window managers.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630972

That this was so hairy and bug-prone is, in my opinion, a symptom of interacting with the ugly beast that is X11. If you read the code of the affected window managers and GTK, you would probably agree.

>the ugly beast that is X11

What's your opinion on Wayland? Specifically, how likely is it that the reliability and consistency of the graphical parts of desktop Linux will improve if the applications I use the most are ported to Wayland?

It looks like it's shaping up very nicely to solve the problems it was designed to solve--namely, making every frame of image on the screen pixel-perfect. However, I don't know if it's going to solve other outstanding problems (or regress on some fronts).

Despite the pains, X allows window managers to arbitrate over window management policy relatively effectively. From what I see so far, it seems that this will be a less clear-cut scheme in Wayland, given its clientside window management and decoration setup. Individual applications will have more freedom to misbehave in terms of custom titlebars etc. and refusing to cooperate with management actions. In an environment where GTK, Qt, wrapped X programs, and other toolkits will be coexisting, there's a lot of room for implementations to behave differently in ways that will confuse and upset users. Whether this will actually be the case is yet to be seen, but I've never seen three different software projects implement a feature in exactly the same way without sharing code.

As the saying goes, we live in exciting times.

>As the saying goes, we live in exciting times.

Users of desktop Linux live in exciting times, you means.

Wayland may improve the speed of compositing on the Linux desktop, but it's very unlikely to improve consistency or reliability. Wayland applications draw their own window decorations (rather than a window manager), which obviously doesn't encourage consistency. And last I heard, when a Wayland application hangs, its window will become completely immovable. No, really.

Reply on news.ycombinator.com