I think I've finally fixed the f.warpring problem. I did not want to get into the hairy code in HandleEnterNotify(), but I did realize that the reason the problem came up in the first place was that the code in iconmgr.c was set up to generate events when the icons in the icon manager were entered/exited. If we don't have IconManagerFocus enabled, there is no reason to generate the events that eventually (!) cause the problem. My patch will thus disable the creation of these events when IconManagerFocus is disabled.
This seems to fix the problem, but I invite comments and corrections. My patch is included below. I've put up a page with all of my currently unapplied CTWM patches at http://www.cis.upenn.edu/~bjornk/ctwm/ /Björn Web: http://www.cis.upenn.edu/~bjornk/ -------------------------------------------------------------------------------- diff -cwr /tmp/ctwm-3.6/iconmgr.c /usr/local/src/ctwm-3.6/iconmgr.c *** /tmp/ctwm-3.6/iconmgr.c 2001-12-11 10:38:52.000000000 -0500 --- /usr/local/src/ctwm-3.6/iconmgr.c 2003-01-25 13:55:21.000000000 -0500 *************** *** 634,642 **** --- 634,647 ---- valuemask = (CWBackPixel | CWBorderPixel | CWEventMask | CWCursor); attributes.background_pixel = tmp->cp.back; attributes.border_pixel = tmp->cp.back; + if (Scr->IconManagerFocus) { attributes.event_mask = (KeyPressMask | ButtonPressMask | ButtonReleaseMask | ExposureMask | EnterWindowMask | LeaveWindowMask); + } else { + attributes.event_mask = (KeyPressMask | ButtonPressMask | + ButtonReleaseMask | ExposureMask); + } attributes.cursor = Scr->IconMgrCursor; tmp->w = XCreateWindow (dpy, ip->w, 0, 0, (unsigned int) 1, (unsigned int) h, (unsigned int) 0, -------------------------------------------------------------------------------- On 16 Jan 2003 21:59, Bjorn Knutsson wrote: > 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. > >
