The different sorts of 'iconification' of windows in X

January 5, 2023

In X, application windows can be in a variety of states. They can be on the screen, they can not have been 'mapped' yet, they can be mapped but located off the currently visible area of the screen (many of my windows spend a lot of time in other pages of my virtual desktop), and pretty much since the beginning they can be what was originally called 'iconified' but which these days is often called 'minimized' in documentation that ordinary people read.

(Things like the Inter-Client Communication Conventions Manual (ICCCM) and Extended Window Manager Hints tend to use 'iconify' and similar terminology, but very few people read the ICCCM. Desktop environments and programs generally describe the state and the action as 'minimize'.)

In the usual X manner, what happens when an application is iconified varies a lot between window managers, and there are two general versions. The original window manager approach, still in use by things like fvwm, is that an iconified window is represented as an icon on the root window (the 'desktop'), using an icon that can come from a variety of places, and generally has a little title below it. You can see a number of these iconified windows in this tour of my (2011) desktop, including a use of the default 'X' icon for two iconified windows.

Because everything in X is a window, these icons are windows (as are the title bars); they're protocol level window entities that are managed internally by the window manager. When a regular window is iconified, the window manager creates or re-maps an appropriate window entity for the icon and for the title and puts it in the right spot. If you have such a window manager around, you can see these protocol level window entities with tools like xwininfo. The icon windows are generally using the Shape extension so they don't have to be rectangles.

However, this 'icons on the desktop' approach has been out of fashion since people started building X desktop environments that used the same general ideas as macOS and Windows. Both of those have always used icons on the desktop for passive objects that had yet to be opened or activated, not active applications; active application windows were collected together in a taskbar. In X window managers that follow this general approach, 'iconifying' an application window doesn't involve materializing a second X window entity; it simply updates the visual appearance of some existing X window.

I believe that basically all modern X desktop environments operate this way with some sort of a taskbar; this definitely includes Cinnamon and modern GNOME. Even the modern default configurations of old school window managers like fvwm often come set up to imitate this (the Fedora default fvwm configuration is set up this way, for example).

(Fvwm itself has several ways to do a taskbar equivalent for some or all windows if you want that, and I use one of them for my terminal windows. This shouldn't be a surprise, because the general taskbar approach is a compact and organized way of keeping track of application windows.)

The difference matters to the X server and at the level of the X protocol, because the 'icons on a desktop' approach creates, destroys, and manipulates a lot more top level X window entities than the taskbar approach does, and in some circumstances it may be doing this in a burst (you can have an application start up by creating two iconified top level windows, for example; the window manager will create all four or so icon windows for them basically at once). The natural consequence of this is you can have an X server bug that only shows up with one of these two approaches to iconification.

(At least the condensed reproduction is small enough to fit into a Mastodon post.)

As a side note, I don't know enough about tiling window managers to know how they (or people using them) typically handle iconified (aka minimized) windows. They're not likely to be using the 'icons on root window' approach for the obvious reason that tiling window managers generally don't have any empty space to show the root window (and icons on it). Since iconifying an application window is something the window manager does, the window manager can also just not do it. Applications can ask to be minimized, but the window manager can always ignore them (or treat it as a request for something else, for example to be moved to a secondary off-screen area).


Comments on this page:

Minor correction: Windows didn't have a taskbar or a "desktop folder" until 95. Windows 3 displayed active programs on the desktop and used minimize-to-icon. Early Mac Systems didn't have minimize at all. By MacOS 9 it had "window shade" minimization. It wasn't until OS X that they adopted the Dock from NeXTSTEP.

Had Matt not beaten me to it, I would have left roughly the same comment myself. But because he did, I did not, and instead waited for any response to it. While checking for that, I ended up following the link to Wikipedia’s taskbar article, and so I learned something I otherwise never might have:

To my surprise, Windows actually had a taskbar in 1.0. (Or something close to it anyway – a bar for iconfied program icons, but without the Start menu or tray.)

I had always assumed, as Matt apparently did, that Windows was born with iconification to the desktop, and only introduced the taskbar in Windows 95. Because that’s how I experienced it: the first version of Windows I encountered was 3.0, which is typical, because that was the first version to gain real traction.

I wouldn’t have guessed that Windows had a taskbar and lost it (by 2.0, according to a How-To Geek article, which came out in 1987 – (co?)incidentally, just after X11) before going back to it in Win95. Looking back now, it actually only had iconification to the desktop during a 7-year period – albeit an important one.

By Thomas Adam at 2023-01-14 07:43:05:

It's worth mentioning that the X11 bug with iconified windows causing the XServer to crash shouldn't be conflated with how the ICCCM2 expects icons to work with window managers.

Fvwm is perhaps the only exemplar on how to handle iconified windows. There's several historical "hacks" in its iconification code to work around other proprietary XServer implementations, as well as optimisations in rendering iconified windows. Such as caching the pixmap used for the icon itself, the GraphicsContext its using (to avoid round-trips to talking to the XServer). Other things include unmapping transient windows first so that when you deiconify, the stacking order is preserved. Transient windows need interaction from the user, so having them in the same stacking order transitioning from an iconified state, keeps that correct.

There's two main parts to an iconified window -- the icon itself, and the icon title. They're separate windows but share the same XEvent hints so that the operation on the icon itself is the same no matter where you click on it.

I think you mentioned about rectangles around icons (which are actually borders in X11 parlance) -- it's not true that you won't see them when not using the SHAPE extension -- all SHAPE does is mask out the region of the window so that clicking close enough to it reaches the root window and not the icon itself.

There's other considerations as well -- in other WMs/DEs which treat iconification via a taskbar, there's no interim state that needs to be tracked in terms of the relationship between iconified window and parent window. If the icon moves between pages in fvwm, where does the parent get remapped when it leaves the iconified state? What about desks? Currently, fvwm has logic for all of this.

I should probably write all of this up in much more technical detail at some point.

From 125.235.62.241 at 2023-02-02 10:08:38:

The X11 bug is very likely caused by https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/126 which enables Xlib thread-safe mode by default. This could cause deadlocks with some programs that aren't compatible with Xlib thread-safe mode (e.g. calling Xlib functions inside an Xlib callback). https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/176 tries to mitigate some of the incompatibilities and should be in Xlib 1.8.4 but the only way to eliminate all compatibility issues is to rebuild Xlib with the `--disable-thread-safety-constructor` configure flag.

Written on 05 January 2023.
« Finding people's use of /usr/bin/python with the Linux audit framework
Setting alerts is a chance to figure out what you really care about »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Jan 5 23:11:54 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.