Gnome is a trailblazer. Desktop icons? Using the Win/Cmd/Super key as a shortcut key? Getting rid of backwards compatibility? The Gnome developers are always eager to try new things...
There was once a time when the KDE (kwin) folks and the GNOME (mutter) folks appeared to get along quite well, and jointly created several versions of the
wm-spec of the FreeDesktop.org Specifications. Collectively, the FreeDesktop specifications are why application developers can create apps that work across various types of Linux desktops.
Many parts of the spec are frequently updated, but sadly the
wm-spec portion of the FreeDesktop.org specifications hasn't gotten gotten an update since November, 29th 2011.
wm-spec defines "Extended Window Manager Hints". Messages that applications, window managers, pagers (navigation aids like virtual desktop selectors), and automation applications such as xdotool and wmctrl.
The wl-roots project that provides the foundation for SwayWM, basically the Wayland port of the i3 tiling window manager, may eventually become a sort of successor to
wm-spec, giving other desktops a common platform to build for Wayland on top of, however, I don't think GNOME or KDE are building on top of wl-roots. The future best case scenario may be code that works for wl-roots, KDE and GNOME... So for anyone that thought using
xcb, the C interface directly to the X11 protocol, was difficult, there's not even a consistent layer to write to once everything moves to Wayland. Hopefully Arcan or something else comes out and surprises us, as I think Wayland could be a significant step backwards for the most sophisticated users. That said, the WL-ROOTS author seems to be optimistic on Wayland...
X11 has been updated periodically since it's initial release in 1987. Lots of things change over the years... The MOTIF_ related proprieties aren't used very often any more.
You can read all of the properties for any window you're interested in with
xprop. For example:
# use -len 80 to drop X11's archaic icon info xprop -len 80
_GTK_FRAME_EXTENTS, the next most recent window sizing method was to check
left, right, top, bottom, CARDINAL/32
The Window Manager MUST set _NET_FRAME_EXTENTS to the extents of the window's frame. left, right, top and bottom are widths of the respective borders added by the Window ManagerEWMH (Extended Window Manager Hints) spec
GNOME released a new property called
_GTK_FRAME_EXTENTS that usually have a value close to
25, 25, 25, 25... In 20202, KDE's KWin window manager was updated to automatically handle _GTK_FRAME_EXTENTS, so if you're a user or developer who's trying to understand how this property works on Kwin, it's even more confusing, because Kwin takes these values into account, and then gets them out of your way. This is the ideal behavior. Congratulations to the Kwin team. However, don't expect to understand this property if you're using a version of Kwin that already effectively hides it.
I had been searching for documentation on how exactly `_GTK_FRAME_EXTENTS` worked for a few weeks, but on KDE I just couldn't make any sense of it. I even found this video and though "isn't that just doing what it was supposed to do? what did it look like before?"
Today when I was using Gnome for a while, it finally all came together.
# &! to launch and disconnect from the terminal gnome-calculator &! kcalc &! # give your windows a moment to open sleep 1 # -x to use a window class, not window title # 100,100 should now be top left of window (X,Y) # 300,300 is less than window minimum, ignored wmctrl -x -r "gnome-Calculator" -e 0,100,100,300,300 wmctrl -x -r "kcalc" -e 0,100,100,300,300
Ideally, these two windows would now be in the same X, Y position... Just looking at this image (taken on Gnome on X11) and you can probably figure out how
Here's a screenshot of
gnome-calculator with a 10x10 pixel grid in the background...
And when we run
xprop on this gnome-calculator window, we get:
_GTK_FRAME_EXTENTS(CARDINAL) = 26, 26, 23, 29
Just to make sure that we don't have any ambiguity, let's try the same thing on
kcalc and see what we get.
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 37, 0
ðŸŽ Putting a bow on it...
So GTK creates a large buffer around the edges of every window. I presume this could be used for dropshadows and other eyecandy. As a result, window is actually much larger than you expect the window to be. The
_GTK_FRAME_EXTENTS values (Left, Right, Top, Bottom) communicate how much of the window should be cropped off when considering things like window "snap to edges".
Meanwhile the KDE Kcalc window is using
_NET_FRAME_EXTENTS (Left, Right, Top, Bottom), and the actual Window that you would use for placement and alignment extends that much BEYOND the size of the window.
_NET_FRAME_EXTENTS tell you how much EXTRA SPACE add to your Window Size calculations.
_GTK_FRAME_EXTENTS tell you how much EXTRA SPACE to REMOVE from your Window Size calculations.
Here I wrote a Xlib program that just displays a 3pixel, red frame window in the top left, starting at point 0,0. It's 100 x 100 pixels.
You can see, the top left of the Kcalc window (x=100, y=100) is just inside of the titlebar.
Meanwhile, the top left of the of the Gnome-Calculator window using
_GTK_FRAME_EXTENTS is actually fully outside of the GTK window..
_GTK_FRAME_EXTENTS should work the same on Wayland, but
wmctrl surely will not since they're directly based on X11.
Hopefully Wayland will soon have command line tools like
xdotool and hotkey tools like
sxhkd that can work on any Linux or BSD desktop environment on top of Wayland...