7 ms·
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 i
by gue5t 14y ago
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 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.
- hollerith 14y ago>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?
- gue5t 14y agoIt 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.
- hollerith 14y ago>As the saying goes, we live in exciting times. Users of desktop Linux live in exciting times, you means.
- lubutu 14y agoWayland 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.