Re: FVWM: disappearing windows?

2007-05-02 Thread Viktor Griph

On Tue, 1 May 2007, Tom Horsley wrote:


Having gotten really curious about what was going on, I installed
xmon to watch the protocol messages as the windows appear and
disappear. Everything is relatively similar with no window manager
and with FVWM until a whole batch of expose events happen
in a row, then I see a PropertyNotify that refers to the WM_STATE
atom, then the window gets unmapped.

Anyone know of any funny shenanigans pygtk and/or fvwm (or the
combination) get up to?


Is it possible that the application uses EWMH to trigger a move of the 
window just as it's being mapped (Firefox 2 does that on session recovery, 
which might result in windows being moved off screen if firefox crashed on 
a different page than active when restarted.)


Have You tried to move the window back on screen using the All cammand 
from FvwmConsole?



/Viktor



Re: FVWM: disappearing windows?

2007-05-02 Thread Tom Horsley
 Have You tried to move the window back on screen using the All cammand 
 from FvwmConsole?

Yep, as near as I can tell, the window really does go away (though the
app doesn't exit). There is one window created by the virt-manager
app that acts normal, all the other ones disappear when I try to
bring them up under fvwm (unless I say unmanaged - I tried a vast
collection of other style options with ignore in their name, but none
of them helped :-).

If I understood more about how to read pygtk code I might be able to
guess why the one window is different than the other windows, but
I don't really know gtk or python, much less the combination.



Re: FVWM: disappearing windows?

2007-05-01 Thread Tom Horsley
Having gotten really curious about what was going on, I installed
xmon to watch the protocol messages as the windows appear and
disappear. Everything is relatively similar with no window manager
and with FVWM until a whole batch of expose events happen
in a row, then I see a PropertyNotify that refers to the WM_STATE
atom, then the window gets unmapped.

Anyone know of any funny shenanigans pygtk and/or fvwm (or the
combination) get up to?

P.S. I also upgraded to the latest 2.5.21 with no change in behavior.



FVWM: disappearing windows?

2007-04-30 Thread Tom Horsley
Redhat and fedora boxes have an application (written in some python
gui toolkit or other) named virt-manager (for managing Xen virtual
machines).

If I point my DISPLAY environment variable at a server where I'm
running fvwm (probably 2.5.18 is currently installed), then
I see a brief flash as a window tries to appear, but it disappears
immediately. The virt-manager app still thinks it is running,
but the window isn't on the screen or in the WindowList.

Anyone have any guesses where the windows might have gone?

P.S. If I point the DISPLAY at a bare X server with no window
manager, the windows do indeed show up.



Re: FVWM: disappearing windows?

2007-04-30 Thread Thomas Adam
On Mon, Apr 30, 2007 at 06:29:07PM -0400, Tom Horsley wrote:
 If I point my DISPLAY environment variable at a server where I'm
 running fvwm (probably 2.5.18 is currently installed), then
 I see a brief flash as a window tries to appear, but it disappears
 immediately. The virt-manager app still thinks it is running,
 but the window isn't on the screen or in the WindowList.

Well, neither of those are symptomatic of the window not being there.
It could not be on the screen because the window was moved elsewhere,
and it might not be in the WindowList due to a possible style setting
this window to use WindowListSkip.

That said, it is slightly odd behaviour.  And, assuming FVWM logs to
something like ~/.xsession-errors, what happens if you enable (via
FvwmConsole for instance):

BugOpts ExplainWindowPlacement On
BugOpts DisplayNewWindowNames On

And then launch this application which loads this window?  It could be
that the window is in a mapped atate still, but is just withdraw.  If
the output from that doesn't help you (and we'd like to see it anyway),
try using the output from DisplayWNewWindowNames specifically to set a
style of  Unmanaged:

Style foo !Managed

 Anyone have any guesses where the windows might have gone?

I take it you've done nothing like:

Next (foo) FlipFocus

You could of course use something like this to see what's happening:

DestroyModuleConfig FE-AW: *
*FE-AW: add_window ThisWindow (NameOfTheWindowImAfter, !Focused) Focus

Module FvwmEvent FE-AW

Which is slightly more interactive than using DisplayNewWindowNames.

-- Thomas Adam

--
He wants you back, he screams into the night air, like a fireman going
through a window that has no fire. -- Mike Myers, This Poem Sucks.