GNOME Bugzilla – Bug 99625
Window list applet malfunctions when windows are iconified
Last modified: 2004-12-22 21:47:04 UTC
The window list has severe problems dealing with iconified windows in Fluxbox/Openbox (both of which are GNOME-2 compliant) and probably other similar window managers, where iconified windows do not belong to any particular workspace. Whenever a window X is iconified, the window list stops adding new windows, stops removing deleted windows, stops registering iconfied windows.... pretty much stops working and stays in whatever state it was when X was iconified. Even if the window is made sticky and then iconified, the window list applet still has these problems. Perhaps the *box behaviour is a bit weird, but I don't think there's anything in the NETWM or ICCCM specs that says iconified windows can not be treated the way that Blackbox/Fluxbox/Openbox treat them. And anyways, the window list should be more robust than that. :) This also happens for the workspace switcher applet, so this is either a bug in libwnck (soname 4, version 0.18, at least according to the Debian packages I have) -- or some common/similarly-developed code between both applets is the culprit. Other NETWM-compliant pager/windowlist-type applications do not have this problem. Examples: fspanel, fbpanel.
Havoc: is it a bug in Openbox or a bug in GNOME ?
Who knows - sounds like it needs debugging in some detail to figure out what happens.
I've finally gotten some time to dig around the source code of several applications. When I used devilspie with a debugging configuration (print out app names of all windows), it stayed in a loop until I uniconified any iconified windows. Since devilspie uses libwnck, pretty big clue it was definitely a libwnck bug of some sort -- waiting for a client list somewhere. I looked at the libwnck (0.18) code, specifically update_client_list (screen.c). I also looked at the openbox code for 2.2.x, which is still mostly Blackbox code with some updates (and I strongly suspect that it resembles the Fluxbox code or vice-versa, in approach anyways). Here's what's causing the problem (but it's not alone, and is correct code as far as the NETWM specs go): libwnck, screen.c, update_client_list: _wnck_get_window_list (screen->priv->xroot, _wnck_atom_get ("_NET_CLIENT_LIST_STACKING"), &stack, &stack_length); _wnck_get_window_list (screen->priv->xroot, _wnck_atom_get ("_NET_CLIENT_LIST"), &mapping, &mapping_length); if (!arrays_contain_same_windows (stack, stack_length, mapping, mapping_length)) { /* Don't update until we're in a consistent state */ For the Blackbox variants, iconified windows don't have an associated workspace. The code in Openbox, at least, creates a complete _NET_CLIENT_LIST with all windows; but an incomplete _NET_CLIENT_LIST_STACKING (leaving out iconified windows). It is indeed the case that having those two lists not have the same windows in them would be an inconsistent NETWM state -- so I don't think libwnck can sanely handle this kind of case. Looks like a bug in Openbox -- unless I'm mistaken about the construction of _NET_CLIENT_LIST, but I don't think I am. The NETWM specs do state that CLIENT_LIST and CLIENT_LIST_STACKING must be the contain *all* windows managed by the window manager, iconified or not Not sure how to handle the stacking for iconified windows, but they can just be put at the bottom or something like that, everybody happy, etc.
If your analysis is correct, I would agree that libwnck can't do much here and that it's an openbox etc. bug. Thanks for investigating.