FVWM: Special window manager hand holding required?

[Tom Horsley]

Just wondering if this strikes a familiar note? The newest
google-chrome running on my fedora 20 system utterly fails
to redraw anything at all (not only no web content, but
no menu bar, navigation buttons, etc) when I minimize it,
then later restore it from the window list. I get nothing
but fvwm window decorations and a totally white window
inside them (at least it is the right size :-).

Out of curiosity, I tried it under gnome 3 in fedora 21
(the fedora 20 video drivers won't run gnome 3) and the
window contents do get restored when I fully restore the
window, but in gnome 3, in the "preview" with all the small
copies of the windows you can click on to actually do the
restore, the google-chrome preview window is totally blank.

It is like the gnome shell is doing something "extra" when
actually restoring the google-chrome window that makes
it really redraw. Any clue what that might be and if I
can convince fvwm to do it too?

[Chris Siebenmann]

Post by Tom Horsley
Just wondering if this strikes a familiar note? The newest
google-chrome running on my fedora 20 system utterly fails
to redraw anything at all (not only no web content, but
no menu bar, navigation buttons, etc) when I minimize it,
then later restore it from the window list. I get nothing
but fvwm window decorations and a totally white window
inside them (at least it is the right size :-).

For what it's worth: I'm also seeing this Chrome behavior under
fvwm. It's specific to the latest google-chrome; I restored the
previous version and it didn't behave this way.

- cks

[Dominik Vogt]

Post by Tom Horsley
Just wondering if this strikes a familiar note? The newest
google-chrome running on my fedora 20 system utterly fails
to redraw anything at all (not only no web content, but
no menu bar, navigation buttons, etc) when I minimize it,
then later restore it from the window list. I get nothing
but fvwm window decorations and a totally white window
inside them (at least it is the right size :-).
Out of curiosity, I tried it under gnome 3 in fedora 21
(the fedora 20 video drivers won't run gnome 3) and the
window contents do get restored when I fully restore the
window, but in gnome 3, in the "preview" with all the small
copies of the windows you can click on to actually do the
restore, the google-chrome preview window is totally blank.
It is like the gnome shell is doing something "extra" when
actually restoring the google-chrome window that makes
it really redraw. Any clue what that might be and if I
can convince fvwm to do it too?

First of all, write a bug report for the application.

Some hints:

* Does it redraw if you place another window on top of it,
covering it partially or even completely when you remove the other
window?

* Does the broken application gobble cpu?

* Try the RefreshWindow command on the offending window with
something like

All (window-name) RefreshWindow

RefreshWindow actually tries to force an application redraw by
covering that window completely for a moment.

If anything of this works, it should be possible to automate that.
Maybe you can add

Thiswindow (window-name) RefreshWindow

to your de-iconification function.

Ciao

Dominik ^_^ ^_^

[Chris Siebenmann]

Post by Dominik Vogt

Post by Tom Horsley
Just wondering if this strikes a familiar note? The newest
google-chrome running on my fedora 20 system utterly fails
to redraw anything at all (not only no web content, but
no menu bar, navigation buttons, etc) when I minimize it,
then later restore it from the window list. I get nothing
but fvwm window decorations and a totally white window
inside them (at least it is the right size :-).

[...]

Post by Dominik Vogt
First of all, write a bug report for the application.

[...]

What I'm seeing is that nothing works to get Chrome to redisplay.
Covering and uncovering Chrome does nothing, resizing the Chrome window
does nothing, RefreshWindow does nothing, and Chrome doesn't gobble
CPU. In fact I have iconified a Chrome window that was playing a Youtube
video and when I deiconified it the audio continued but there were
absolutely no video updates.

In addition, Chrome doesn't seem to pay attention to keyboard input
once iconified and deiconified. For instance, Control-W will normally
close my Chrome windows but after a deiconify it's completely ignored.
Chrome *does* still notice and respond to fvwm's Close, though, so it
is not completely ignoring X events.

- cks

[Dominik Vogt]

Post by Chris Siebenmann

Post by Dominik Vogt

Post by Tom Horsley
Just wondering if this strikes a familiar note? The newest
google-chrome running on my fedora 20 system utterly fails
to redraw anything at all (not only no web content, but
no menu bar, navigation buttons, etc) when I minimize it,
then later restore it from the window list. I get nothing
but fvwm window decorations and a totally white window
inside them (at least it is the right size :-).

[...]

Post by Dominik Vogt
First of all, write a bug report for the application.

[...]
What I'm seeing is that nothing works to get Chrome to redisplay.
Covering and uncovering Chrome does nothing, resizing the Chrome window
does nothing, RefreshWindow does nothing, and Chrome doesn't gobble
CPU. In fact I have iconified a Chrome window that was playing a Youtube
video and when I deiconified it the audio continued but there were
absolutely no video updates.
In addition, Chrome doesn't seem to pay attention to keyboard input
once iconified and deiconified. For instance, Control-W will normally
close my Chrome windows but after a deiconify it's completely ignored.
Chrome *does* still notice and respond to fvwm's Close, though, so it
is not completely ignoring X events.

Sounds pretty broken. Other things to try are to resize the
window or to restart fvwm or to use the "Recapture" or
"RecaptureWindow" command. Maybe clicking somewhere in the window
where one of the controls should be helps? But I have litte hope
that anything of this wokrs. Probably the window waits for some
specific odd event that never comes.

Do you display icons too, or have them just in the icon manager?
Maybe it waits for the icon window to appear? Try to comment out
all icon related styles in your configuration file and see if that
helps (i.e. make fvwm use and display whatever icon pixmap or icon
window the application provides).

Ciao

Dominik ^_^ ^_^

[Tom Horsley]

On Thu, 4 Sep 2014 22:12:01 +0100

Post by Dominik Vogt
Do you display icons too, or have them just in the icon manager?

I don't use icons at all (All my screen space are belong to me! :-),
I just pop up the window list from a menu item when I want to
restore a window.

[Chris Siebenmann]

Post by Dominik Vogt
Do you display icons too, or have them just in the icon manager?
Maybe it waits for the icon window to appear? Try to comment out
all icon related styles in your configuration file and see if that
helps (i.e. make fvwm use and display whatever icon pixmap or icon
window the application provides).

Unlike Tom Horsley, I display icons and I let Chrome use its default.
So between the two of us I think we cover all or very close to all of
the bases here. On the other hand the one thing neither of us does is
'iconify' Chrome to some sort of a menubar, which is what many common
desktop environments do.

(Tom hides Chrome entirely, I iconify it to a regular icon.)

As Tom says, this is clearly a very recent Chrome behavior change. On
the other hand it's at least a difference between what FVWM is doing and
what eg gnome-shell is doing (and I suspect KDE as well or there would
be many more bug reports to the Chrome people). I'm personally concerned
that the Chrome people will likely ignore bug reports about this unless
we can somehow identify what FVWM is doing differently.

Post by Dominik Vogt
Sounds pretty broken. Other things to try are to resize the window
or to restart fvwm or to use the "Recapture" or "RecaptureWindow"
command. Maybe clicking somewhere in the window where one of the
controls should be helps?

Sadly, recapturing doesn't help and clicking where controls are is
ignored just like keystrokes.

Post by Dominik Vogt
Probably the window waits for some specific odd event that never
comes.

An odd event or maybe a sequence of events? Perhaps gnome-shell
deiconifies windows in a different sequence of X actions than FVWM
does?

(The other theory I can vaguely wave my hands about is that Chrome is
now waiting for some sort of OpenGL or compositor event in addition to
normal X events. Since FVWM doesn't do any of that stuff... but I
theorize extremely wildly and probably incorrectly.)

- cks

[Thomas Adam]

This post might be inappropriate. Click to display it.

[Tom Horsley]

On Thu, 4 Sep 2014 22:50:53 +0100

Post by Thomas Adam
I'd be interested in seeing the output from xev attached to the chromium
window when these problems happen.

I started xev immediately before hitting the minimize window decoration
and that printed all the events through serial 20.

I then went to the window list and restored it, and got a slew of events,
all of which are serial 21 (which seems a bit weird to me :-).

Here is the output:

zooty> xev -id 0x2200001

FocusIn event, serial 18, synthetic NO, window 0x2200001,
mode NotifyNormal, detail NotifyNonlinear

KeymapNotify event, serial 18, synthetic NO, window 0x0,
keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

FocusOut event, serial 18, synthetic NO, window 0x2200001,
mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 18, synthetic NO, window 0x2200001,
mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 18, synthetic NO, window 0x0,
keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

FocusOut event, serial 18, synthetic NO, window 0x2200001,
mode NotifyNormal, detail NotifyNonlinear

UnmapNotify event, serial 18, synthetic NO, window 0x2200001,
event 0x2200001, window 0x2200001, from_configure NO

PropertyNotify event, serial 18, synthetic NO, window 0x2200001,
atom 0x11d (WM_STATE), time 283968683, state PropertyNewValue

PropertyNotify event, serial 18, synthetic NO, window 0x2200001,
atom 0x13f (_NET_WM_STATE), time 283968687, state PropertyNewValue

PropertyNotify event, serial 20, synthetic NO, window 0x2200001,
atom 0x28 (WM_NORMAL_HINTS), time 283968690, state PropertyNewValue

MapNotify event, serial 21, synthetic NO, window 0x2200001,
event 0x2200001, window 0x2200001, override NO

VisibilityNotify event, serial 21, synthetic NO, window 0x2200001,
state VisibilityPartiallyObscured

PropertyNotify event, serial 21, synthetic NO, window 0x2200001,
atom 0x11d (WM_STATE), time 283985397, state PropertyNewValue

VisibilityNotify event, serial 21, synthetic NO, window 0x2200001,
state VisibilityUnobscured

FocusIn event, serial 21, synthetic NO, window 0x2200001,
mode NotifyWhileGrabbed, detail NotifyNonlinear

KeymapNotify event, serial 21, synthetic NO, window 0x0,
keys: 29 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

PropertyNotify event, serial 21, synthetic NO, window 0x2200001,
atom 0x249 (_WIN_AREA), time 283985399, state PropertyNewValue

PropertyNotify event, serial 21, synthetic NO, window 0x2200001,
atom 0x13f (_NET_WM_STATE), time 283985399, state PropertyDelete

FocusIn event, serial 21, synthetic NO, window 0x2200001,
mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 21, synthetic NO, window 0x0,
keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

FocusOut event, serial 21, synthetic NO, window 0x2200001,
mode NotifyNormal, detail NotifyNonlinear

Expose event, serial 21, synthetic YES, window 0x2200001,
(0,0), width 1526, height 679, count 1

Expose event, serial 21, synthetic YES, window 0x2200001,
(508,679), width 1018, height 299, count 0

Expose event, serial 21, synthetic YES, window 0x2200001,
(0,679), width 508, height 299, count 0
^C

[Dominik Vogt]

Post by Chris Siebenmann

Post by Dominik Vogt
Probably the window waits for some specific odd event that never
comes.

An odd event or maybe a sequence of events?

Odd as in "I've no idea for which event or why". ;-)

Ciao

Dominik ^_^ ^_^

[Tom Horsley]

On Thu, 04 Sep 2014 16:42:49 -0400

Post by Chris Siebenmann
What I'm seeing is that nothing works to get Chrome to redisplay.

Yea, that's what I see too. I get the impression someone cleverly
taught it that when iconified, it doesn't need to try to draw anything,
but neglected to tell it to notice when it is de-iconified (except
in gnome-shell, it does somehow notice).

I did file a bug report, and it was almost immediately re-directed
as a duplicate of this:

https://productforums.google.com/forum/#!mydiscussions/chrome/_TNTBy20VsI

Nothing in there looks very much like what I'm seeing though, and that
is a android issue (at least originally) and was supposedly fixed
in version 36, but this started happening in linux on version 37 :-(.

[Bert Geens]

Post by Chris Siebenmann

Post by Dominik Vogt

Post by Tom Horsley
Just wondering if this strikes a familiar note? The newest
google-chrome running on my fedora 20 system utterly fails
to redraw anything at all (not only no web content, but
no menu bar, navigation buttons, etc) when I minimize it,
then later restore it from the window list. I get nothing
but fvwm window decorations and a totally white window
inside them (at least it is the right size :-).

[...]

Post by Dominik Vogt
First of all, write a bug report for the application.

[...]
What I'm seeing is that nothing works to get Chrome to redisplay.
Covering and uncovering Chrome does nothing, resizing the Chrome window
does nothing, RefreshWindow does nothing, and Chrome doesn't gobble
CPU. In fact I have iconified a Chrome window that was playing a Youtube
video and when I deiconified it the audio continued but there were
absolutely no video updates.
In addition, Chrome doesn't seem to pay attention to keyboard input
once iconified and deiconified. For instance, Control-W will normally
close my Chrome windows but after a deiconify it's completely ignored.
Chrome *does* still notice and respond to fvwm's Close, though, so it
is not completely ignoring X events.
- cks

The same problem occurs with Chromium 37.0.2062.94, Chromium
36.0.1985.143 does not exhibit the problem

However shading and unshading the window after deiconifying returns the
application to normal behaviour for me (fvwm 2.6.5).

Kind regards,

Bert

[Tom Horsley]

On Fri, 05 Sep 2014 11:49:17 +0200

Post by Bert Geens
However shading and unshading the window after deiconifying returns the
application to normal behaviour for me (fvwm 2.6.5).

So now I have to ask: What the heck is shading and unshading
and how do I do it? :-).

[Chris Bannister]

Post by Tom Horsley
On Fri, 05 Sep 2014 11:49:17 +0200

Post by Bert Geens
However shading and unshading the window after deiconifying returns the
application to normal behaviour for me (fvwm 2.6.5).

So now I have to ask: What the heck is shading and unshading
and how do I do it? :-).

Double click the title bar ... et voila!

[Chris Bannister]

Post by Chris Bannister

Post by Tom Horsley
On Fri, 05 Sep 2014 11:49:17 +0200

Post by Bert Geens
However shading and unshading the window after deiconifying returns the
application to normal behaviour for me (fvwm 2.6.5).

So now I have to ask: What the heck is shading and unshading
and how do I do it? :-).

Double click the title bar ... et voila!

Apologies for that answer, I now realise that you have to explicitly
enable it.

[Dominik Vogt]

Post by Tom Horsley
On Fri, 05 Sep 2014 11:49:17 +0200

Post by Bert Geens
However shading and unshading the window after deiconifying returns the
application to normal behaviour for me (fvwm 2.6.5).

So now I have to ask: What the heck is shading and unshading
and how do I do it? :-).

Shading means to reduce the window to its title bar (in fvwm you
can also "shade" a window to any of its borders or corners to make
it really small). Use the WindowShade command to do that.

Ciao

Dominik ^_^ ^_^

[Tom Horsley]

On Fri, 05 Sep 2014 11:49:17 +0200

Post by Bert Geens
However shading and unshading the window after deiconifying returns the
application to normal behaviour for me (fvwm 2.6.5).

By golly, it works for me too (once I found the WindowShade function
and added it to my window operations menu). Thanks!

[Chris Siebenmann]

Post by Tom Horsley
On Fri, 05 Sep 2014 11:49:17 +0200

Post by Bert Geens
However shading and unshading the window after deiconifying returns the
application to normal behaviour for me (fvwm 2.6.5).

By golly, it works for me too (once I found the WindowShade function
and added it to my window operations menu). Thanks!

For the record: the same thing happens for me, using almost the CVS
tip.

- cks

[Tom Horsley]

I finally figured out how to re-open the mysteriously closed thread where
I reported this in the google forums, so if anyone wants to chime in over there
the thread is here:

https://productforums.google.com/forum/#!mydiscussions/chrome/p1Ebp57SpC4

[Dominik Vogt]

Post by Tom Horsley
On Fri, 05 Sep 2014 11:49:17 +0200

Post by Bert Geens
However shading and unshading the window after deiconifying returns the
application to normal behaviour for me (fvwm 2.6.5).

By golly, it works for me too (once I found the WindowShade function
and added it to my window operations menu). Thanks!

Now, that is a real surprise to me. Shading and unshading a
window is almost the same as just resizing it, except that some
additional Ewmh or Gnome state may be communicated to the window.

Could one of you please try what happens if you add the following
lines at the end of the function fvwm/icons.c:CMD_Iconify(), right
before the final return:

FlushAllMessageQueues();
XFlush(dpy);
EWMH_SetWMState(fw, False);
GNOME_SetHints(fw);
GNOME_SetWinArea(fw);

(Even if it works it is not a proper solution, just an attempt to
fire extra events at the window and see what happens.)

Ciao

Dominik ^_^ ^_^

[Chris Siebenmann]

Post by Dominik Vogt
Could one of you please try what happens if you add the following
lines at the end of the function fvwm/icons.c:CMD_Iconify(), right
FlushAllMessageQueues();
XFlush(dpy);
EWMH_SetWMState(fw, False);
GNOME_SetHints(fw);
GNOME_SetWinArea(fw);
(Even if it works it is not a proper solution, just an attempt to
fire extra events at the window and see what happens.)

I tried this and it appears to have made no difference to the
behavior of Chrome: de-iconifying still results in blank white,
and WindowShade'ing it fixes this.

- cks

[Dominik Vogt]

Post by Chris Siebenmann

Post by Dominik Vogt
Could one of you please try what happens if you add the following
lines at the end of the function fvwm/icons.c:CMD_Iconify(), right
FlushAllMessageQueues();
XFlush(dpy);
EWMH_SetWMState(fw, False);
GNOME_SetHints(fw);
GNOME_SetWinArea(fw);
(Even if it works it is not a proper solution, just an attempt to
fire extra events at the window and see what happens.)

I tried this and it appears to have made no difference to the
behavior of Chrome: de-iconifying still results in blank white,
and WindowShade'ing it fixes this.

Sigh. Do you use any of the window shading related styles?

WindowShadeSteps
WindowShadeScrolls or WindowShadeShrinks
WindowShadeLazy or WindowShadeAlwaysLazy or WindowShadeBusy

Or the obsolete WindowShadeAnimate command?

Can you post all your WindowShade related settings please? And
what exactly is the command that triggers shading?

(All these questions aim at finding out exactly what the
WindowShade command does on your system, and what the difference
is between shading and resizing windows manually.)

Also, please try to grab the bottom border of the bad window, and
drag it all the way up to the title bar (in opaque resize mode,
not in wire frame mode). Stop resizing, then resize the window
again to its original size.

One more thing to try: Does maximizing and unmaximizing the window
help? Or making it sticky and unsticky?

Ciao

Dominik ^_^ ^_^

[Chris Siebenmann]

Post by Dominik Vogt
Sigh. Do you use any of the window shading related styles?
WindowShadeSteps
WindowShadeScrolls or WindowShadeShrinks
WindowShadeLazy or WindowShadeAlwaysLazy or WindowShadeBusy
Or the obsolete WindowShadeAnimate command?

I don't use any of them. Until this Chrome thing came up I didn't
use WindowShade et al at all; I've added it to my setup only due
to Chrome.

Post by Dominik Vogt
Can you post all your WindowShade related settings please? And
what exactly is the command that triggers shading?

I'm triggering shading and unshading with:
AddToFunc Raise-Or-Move "I" Raise
+ "M" Move
+ "D" WindowShade

and then a titlebar mouse binding that invokes it:

Mouse 1 T N Raise-Or-Move

(as you might guess from the function name, the WindowShade on
doubleclick bit is a very recent addition.)

Post by Dominik Vogt
Also, please try to grab the bottom border of the bad window, and
drag it all the way up to the title bar (in opaque resize mode,
not in wire frame mode). Stop resizing, then resize the window
again to its original size.

This has no effect, but during the opaque resize things flicker
and I can occasionally see flashes of bits of window content.

Post by Dominik Vogt
One more thing to try: Does maximizing and unmaximizing the window
help? Or making it sticky and unsticky?

Maximizing and unmaximizing the window has no effect.

However, making it sticky and then unsticky is a winner; the moment
I make it sticky the window contents pop back (and they stay when I
unsticky it again, until I iconify it again). In addition while the
window is set sticky I can iconify it and then deiconify it and the
contents stay visible.

- cks

[Tom Horsley]

Post by Dominik Vogt
Sigh. Do you use any of the window shading related styles?
WindowShadeSteps
WindowShadeScrolls or WindowShadeShrinks
WindowShadeLazy or WindowShadeAlwaysLazy or WindowShadeBusy

Nope, all I did was add this to the menu that is attached to
the window op buttons on the titlebar:

+ "Shade" WindowShade

So I click on the menu button I have in the titlebar
and pick Shade, then do it again to un-shade and
the window contents are back (it's magic :-).

Post by Dominik Vogt
One more thing to try: Does maximizing and unmaximizing the window
help?

I tried that before, does nothing other than make a much bigger
white screen :-).

I'm not really sure it is worth trying to fix from the fvwm side
now that we have a work around. This has got to be a chrome bug
google ought to fix (doesn't it?, he queried hopefully :-).

[Dominik Vogt]

Post by Chris Siebenmann

Post by Dominik Vogt
Also, please try to grab the bottom border of the bad window, and
drag it all the way up to the title bar (in opaque resize mode,
not in wire frame mode). Stop resizing, then resize the window
again to its original size.

This has no effect, but during the opaque resize things flicker
and I can occasionally see flashes of bits of window content.

Sounds really broken.

Post by Chris Siebenmann

Post by Dominik Vogt
One more thing to try: Does maximizing and unmaximizing the window
help? Or making it sticky and unsticky?

Maximizing and unmaximizing the window has no effect.
However, making it sticky and then unsticky is a winner; the moment
I make it sticky the window contents pop back (and they stay when I
unsticky it again, until I iconify it again). In addition while the
window is set sticky I can iconify it and then deiconify it and the
contents stay visible.

Actually, stickyness and maximization are Ewmh window states -
just like shading. That's why I suggested trying them. So, if
you replace deiconify with

AddToFunc Deiconify
+ I iconify off
+ I stick toggle
+ I stick toggle

That should hide the problem without a lot of resizing and moving
the window around.

Post by Chris Siebenmann
I'm not really sure it is worth trying to fix from the fvwm side
now that we have a work around.

No, of course not; I won't add crazy stuff to window handling jsut
because of one broken application. It might be worthwhile to add
another BugOpts option (or a style) that makes fvwm tell windows
that they are shaded when they are actually iconified.

Post by Chris Siebenmann
This has got to be a chrome bug
google ought to fix (doesn't it?, he queried hopefully :-).

I hope so, but things can take a long time until they're fixed.

(Please don't send replies to me directly but only to the list.)

Ciao

Dominik ^_^ ^_^

[Tom Horsley]

On Fri, 5 Sep 2014 23:23:38 +0100

Post by Dominik Vogt
AddToFunc Deiconify
+ I iconify off
+ I stick toggle
+ I stick toggle
That should hide the problem without a lot of resizing and moving
the window around.

Almost. Since I use the WindowList, I want to change WindowListFunc,
which I was already doing to remove some of the things I don't
want (like warping the pointer). Here's the one I finally got to
work:

# I just want to see the window, I don't want to be warped there or have the
# focus changed...
#
# Stupid google-chrome 37 won't display when deiconified, so change
# WindowListFunc to toggle sticky twice (which, God knows why) makes the
# window display again while leaving it in the sticky state it had to begin
# with
#
DestroyFunc WindowListFunc
AddToFunc WindowListFunc
+ I Iconify off
+ I Raise
+ I Refresh
+ I Stick toggle
+ I Refresh
+ I Stick toggle

Didn't work till I added the Refresh commands (not sure if both of them
were necessary).

My fvwm now behaves the way it always did, even for broken
google-chrome. Thanks to everyone who helped figure this out.

[Thomas Adam]

This post might be inappropriate. Click to display it.

[Dominik Vogt]

Post by Thomas Adam

Post by Dominik Vogt
(All these questions aim at finding out exactly what the
WindowShade command does on your system, and what the difference
is between shading and resizing windows manually.)

It's to do with EWMH_SetWMState() -- that's the only difference, and
indeed in terms of CMD_WindowShade(), not calling that won't refresh the
contents.
EWMH_SetWMState() -> ewmh_ChangeProperty() -> XChangeProperty()

Actually, in many places there's no XFlus() after these calls, so
the change may be delayed somewhat. But that does not explain the
symptoms.

Post by Thomas Adam
I do not know why, in the case of the XChangeProperty() call happening
and fvwm receiving the PropertyNotify event for the EWMH-class of
events (it's not just windowshade, sticky also makes the window work
correctly), that the window is then magically refreshing its contents
and returning to normal.

Well, the Ewmh stuff defines an atom for stickyness and one for
shading, but nothing for iconify (as that information is already
available from elsewhere). So I guess when the application
receives a PropertyNotify event for one of these atoms it
re-examines the window's state and concludes that ist should
start redrawing again.

Actually I don't understand all this crap logic. The real
criterion is: If you receive an Expose event, redraw. If you
don't receive one, don't redraw. A window that is iconified is
unmapped and a window that is shaded is either hidden or unmapped.
In both cases the window does not get Expose events and any
special logic is superfluous.

Post by Thomas Adam
That really is the culprit here---and indeed, WindowShading is no
different to resizing anyway, and having spent a while trying to debug
this, I can only conclude fvwm isn't to blame, nor do I want to dig
around in Chrome's internals.

Thinking about it - shading in fvwm is very different from
resizing in fvwm because when you shade a window, only the frame
is resized, but the client window keeps its size. This is meant
to prevent crazy redrawing during animated window shading.
Furthermore the final size of the client window would be 0 pixels
anyway, and the animation might make the window smaller than the
requested minimum size. So I actually only move the window around
in the frame during the animation without resizing it. Ideally
the application wouldn't even notice that the window is shaded
(shading would work *better* if there wasn't this stupid
_NET_WM_STATE_SHADED atom). Well, I've probably made clear what I
think of the Ewmh spec in the past.

Ciao

Dominik ^_^ ^_^