FVWM: Re: Re: moving windows patch

From: Mark Borges <mdb_at_cdc.noaa.gov>
Date: 11 Mar 1996 13:20:43 -0700

>> On Mon, 11 Mar 1996 12:09:10 EDT+4,
>> Grant McDorman(GM) wrote:
GM> On 11-Mar-96, Mark Borges wrote:
>> >> On Wed, 06 Mar 1996 23:22:48 -0800,
>> >> Henrique Martins(HM) wrote:
HM> This new patch, implemented somewhat differently, does seem to
HM> behave properly for moving icons, and windows of course. To
HM> accomplish this,
>>
>> It was running fine, then FvwmPager died (i.e., it disappeared from
>> the screen). I forget precisely what I was doing just before I noticed
>> it's absence. I then checked my .xsessionlog file and found:
>>
>> ------------------------------------------------------------------------------
>> X Error of failed request: BadMatch (invalid parameter attributes)
>> Major opcode of failed request: 42 (X_SetInputFocus)
>> Serial number of failed request: 41231
>> Current serial number in output stream: 41266
>> ------------------------------------------------------------------------------
>>
>> right after it went away (I know, this is probably useless, but on the
>> off chance it helps...)

GM> This is a timing problem in FvwmPager. I posted a patch some time ago,
GM> but either it didn't make it to the list or it has not been applied.

GM> It will happen when you drag a window - in the pager, of course -
GM> from another desk to the current page of the current desk.

Ah, yes. Now I remember. That is exactly what I was doing at the
time. But, I can't reproduce the bug consistently on my platform
(Solaris-2.3, Sparc10), presumably because it is a timing problem that
only shows up sporadically.

GM> Dragging the window *out* of the pager doesn't cause the problem.

Yes, I've never noticed a problem dragging out.

>> On Mon, 11 Mar 1996 13:51:40 -0500 (EST),
>> Grant McDorman(GM) wrote:

GM> Incidentally, I reduced the delay from 50,000 to 5,000 (microsec)
GM> when installing 2.0.41 and it still seems to work fine. I agree,
GM> though, that it would be nice to have something other than a
GM> delay. About the only thing I can think of, though, is to wait for
GM> an event, such as ReparentNotify, which would be a pain (and would
GM> also, presumably, have to time out to prevent the pager from
GM> locking up if something goes wrong).

That seems like an acceptable delay if it does cure the problem. I
agree, though, that a solution without this sleep delay would be
desireable. Perhaps a compile-time option to enable the work-around if
sites notice the timing problem on a sufficiently regular basis (I've
tried to get FvwmPager to quit pretty hard the last hour or so,
dragging many windows to the current page of the current desk and
changing focus like crazy, and the pager refuses to die again).

  -mb-

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Mon Mar 11 1996 - 14:21:01 GMT

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:37:58 BST