On Fri, Oct 05, 2007 at 01:34:00AM +0100, Thomas Adam wrote:
> > $ FvwmCommand 'windowid xevWinId DestroyWindowStyle';
> > $ FvwmCommand 'windowid xevWinId WindowListFunc'; sleep 5;
> > FvwmCommand 'windowid xevWinId windowstyle miniicon vim.png'
>
> Without even looking, I suspect what's happening here is the call to
> WindowListFunc (assuming it's the default function call) is warping
> the pointer, this creating the FocusOut event as it leaves the other
> window and enters into the current window.
Well, I *want* to first focus the Xev window, before changing the Mini
Icon. If you try them you'll see the following:
1. After calling WindowListFunc, the Xev window gets a Focus In
event (as expected).
2. After calling WindowStyle to change the MiniIcon on the (still
focused Xev window), you get a Focus Out event immediately
followed by a Focus In event.
This is probably a bug. Changing the MiniIcon should not generate Focus
Change events. (Again, this has nothing to do with the use of
WindowListFunc. I only use that here to generate a reproducible example
which can be used by the devs to confirm the bug).
> Why are you even using FvwmCommand though, when PipeRead will suffice?
I want to generate an example situation which reproduces the Fvwm bug,
and narrows it down to the miniicon change. So essentially something
like:
- Focus the Xev window.
- Wait long enough so that all events due to that focus change are
processed (the sleep 5 command).
- Change the mini icon of the Xev window (so that the spurious focus
change events generated by Fvwm can be tracked).
Perhaps you can do so with the PipeRead command. But if you do what I
suggest above, you can clearly which X events are generated when the
windows MiniIcon changes.
GI
--
Linux: Because rebooting is for adding new hardware.
