I'm working on VICE (the Commodore 8-bit emulator)'s Xaw GUI, and I've
been working on some tricks where it spontaneously de-iconifies windows.
VICE calls XMapRaised() on them.
Of course I've been trying how this behaves if such windows are in
different workspaces.
What happens with ctwm is that if the window in question is iconified
and in another workspace, it gets not only de-iconified, but also
visible in the current workspace. After that, when you switch
workspaces, ctwm is confused about where the window really is. It is
also not properly shown in the WorkspaceManager window.
It turns out that ctwm arrives at the following code:
void HandleMapRequest(void)
{
...
/* If no hints, or currently an icon, just "deiconify" */
else
{
if (1/*OCCUPY (Tmp_win, Scr->workSpaceMgr.activeWSPC)*/) {
if (Tmp_win->StartSqueezed) Squeeze (Tmp_win);
DeIconify(Tmp_win);
SetRaiseWindow (Tmp_win);
}
else {
Tmp_win->mapped = TRUE;
}
You can see that there used to be a check (OCCUPY) if the window ought
to be visible in the current workspace, but that check has been removed.
According to "mtn annotate", this happened in revision 507dd4c8.. aka
3.5.2b. The CHANGES file doesn't seem to indicate why.
As it is, this leaves the window's occupation set incorrectly, very
likely causing the confusion I saw.
I tried a random other workspace manager on another machine, the one
that Xubuntu has. That one doesn't drag the window to the current
workspace.
So, there seem to be 2 possible actions:
- restore former behaviour, so that the window de-iconifies but remains
invisible. Whatever unspecified bug there was here (other than that
somebody may have wanted the window to become visible) should be found
and fixed.
- do drag the window to the current workspace, but update its occupation
properly.
What's best?
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you
\X/ rhialto/at/xs4all.nl -- can't be childish sometimes. -The 4th Doctor
