I've been looking some more at this, but there is stuff going on that
I don't quite understand. Here's a summary of what seems to cause the
problem:
The problem occurs when we are warped to the icon manager. This is the
point where the warp ring starts taking shortcuts. Now, if the window
button in the icon manager that the warped pointer happens to land on
(the middle one, it seems) is iconified, you're fine. But if it is a
regular window, then the following line in HandleEnterNotify() in
events.c is triggered:
Scr->RingLeader = Tmp_win;
where Tmp_window is the window that the button in the icon manager
represents. Now, the problem for me is that Tmp_win is a global
variable, and I have no idea when and why it is set to a window, and
why this should cause the Scr->RingLeader to change.
I've noticed this line being triggered (twice!) if I enter a window,
but if that window is the icon manager, it is first triggered twice
with the icon manager window as the Tmp_win, but then it is triggered
a third time with the window represented by the button in the icon
manager. It is triggered (once) if you move the pointer over another
button representing a non-iconified window in the icon manager.
I have NoIconManagerFocus set, so focus is (should not be) given to
windows based on where mt pointer is in the icon manager, but
apparently Tmp_win is still changed, and this causes it to change the
position in the warpring.
There is code earlier in HandleEnterNotify() that checks for
IconManagerFocus, and perhaps it's as easy as some flag that should be
set in the else-case for this test, but not knowing exactly what's
going on, I thought I'd ask you.
/Bj�rn
On 14 Nov 2002 08:52, Claude Lecommandeur wrote:
>
> Hello,
>
>
> You are right, this is a plain bug. If no one else do it, I'll try to find
> some time to fix it.
>
> Claude.
>
> On Wed, 13 Nov 2002 02:36:06 -0500
> Bjorn Knutsson <[EMAIL PROTECTED]> remarque astucieusement:
>
> > I have configured my ctwm with an empty window ring, thus making
> > f.warpring "next"/"prev" circle through all windows.
> >
> > This works in some workspaces, some of the time. In a lot of cases, it
> > does, however, not. It will usually circle forward ("next") through
> > the windows which occupy all workspaces (icon/workspace manager +
> > clock), but then all bets are off. If circling is limited, then
> > circling backwards ("prev") will also be restricted to a subset of the
> > windows in the workspace, but not necessarily the same windows, or
> > even the same number of windows.
> >
> > In the workspace in which I'm writing this, I have the "basic" three
> > windows, plus an Emacs and three xterms. Circling forwards will circle
> > throught the basic windows plus one of the xterms. Circling backwards
> > will circle through the two other xterms and the icon manager.
> >
> > Has anyone else experienced this problem? It should not be something
> > in my configuration, but possibly my config might trigger something
> > (the first line of my configuration file is "NoDefaults", go
> > figure...).
> >
> > I'm running ctwm 3.6 with my workspace manager key binding patch
> > applied, but this problem actually predates both 3.6 and my patch.
> >
> > /Bj�rn
>
>
> --
> Claude Lecommandeur [EMAIL PROTECTED]
> EPFL - SIC +41 21 693 22 97
> 1015 Lausanne (Switzerland)
> http://slwww.epfl.ch/SIC/SL/info/Claude.html
>
> This signature intentionally left boring.
>
