FVWM: ConfigureNotify on the root window

[Raimund Steger]

Hi,

for years now I have been using nxagent to work with X11 desktops over our company WAN. nxagent is a variant of Xnest with some low-bandwidth optimizations when paired with a client program called nxproxy. I think it's also the basis for X2go.

nxagent windows are resizable. This means the X display they present to clients, such as FVWM, can change its geometry dynamically. Up until now, this hasn't been a problem as I've just configured a certain size and refrained from resizing the window in any way.

However, we've now been outfitted with laptops which have the annoying trait of switching the whole local desktop to the resolution of the built-in LCD whenever the external monitor is switched off. This means my nxagent windows are now resized a lot more often.

Whenever this happens, a ConfigureNotify event on the root window occurs which carries the new extent of the window. Xrandr is not involved as far as I can tell.

Now after a couple of weeks filled with countless FVWM restarts, I've finally looked into building a patch (attached) that will at least update $[vp.width] and make FVWM popup menus be clipped correctly to the changed screen area. As far as I've been able to tell this seems to work, although I have no real grasp about what places *would* actually need to be changed to do it properly. Also, what I've done is very likely totally wrong for multi-head/Xinerama setups.

Just wanted to hear somebody else's opinion on the whole thing...

Raimund

[Raimund Steger]

Post by Raimund Steger
[...]
Now after a couple of weeks filled with countless FVWM restarts, I've
finally looked into building a patch (attached) that will at least update
$[vp.width] and make FVWM popup menus be clipped correctly to the changed
screen area. As far as I've been able to tell this seems to work, although
I have no real grasp about what places *would* actually need to be changed
to do it properly. Also, what I've done is very likely totally wrong for
multi-head/Xinerama setups.

er, I just noticed that the patch hard-coded my desktop size. I think I've
improved it now.

[Raimund Steger]

[...]
But that's a much larger piece of work, believe me. But your patch

No argument here, but from [1], section 8:

"
Clients MAY select for ConfigureNotify on the root window to be
informed of screen changes. This may be advantageous if all your
client needs to know is the size of the root window, as it avoids
round trips to set up the extension.
"

I don't see how this could be understood in any other way than that it
/is/ acceptable for clients to handle ConfigureNotify even when not
setting up Xrandr.


[1] http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt

[Dan Espen]

Post by Raimund Steger

[...]
But that's a much larger piece of work, believe me. But your patch

"
Clients MAY select for ConfigureNotify on the root window to be
informed of screen changes. This may be advantageous if all your
client needs to know is the size of the root window, as it avoids
round trips to set up the extension.
"
I don't see how this could be understood in any other way than that it
/is/ acceptable for clients to handle ConfigureNotify even when not
setting up Xrandr.
[1] http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt

That's the way I read it too, you'd want to trap both.

Tom, by "larger piece of work", I take it you mean you have to deal with
rotations?

[Dan Espen]

Post by Raimund Steger

[...]
But that's a much larger piece of work, believe me. But your patch

"
Clients MAY select for ConfigureNotify on the root window to be
informed of screen changes. This may be advantageous if all your
client needs to know is the size of the root window, as it avoids
round trips to set up the extension.
"
I don't see how this could be understood in any other way than that it
/is/ acceptable for clients to handle ConfigureNotify even when not
setting up Xrandr.
[1] http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt

As a follow up on this, I applied the patch and added some stderr
prints.

Then I used xrandr to change screen size, like this:

xrandr -s 1024x768
xrandr -s 1600x1200

I found that xrandr generates configurenotify events.
I got 2 root window configurenotifys for issuing the command once.

But Fvwm doesn't react well. Fvwm sees the event and knows the new
screen size but doesn't move anything around like it should.
I told Fvwm to execute a "recapture" and that helped.
I think if fvwm becomes aware of a new screen size, it makes sense
to re-position all the windows and icons.

[Raimund Steger]

On Sun, 24 Jan 2016 22:37:08 -0500

Post by Dan Espen
[...]
I found that xrandr generates configurenotify events.
I got 2 root window configurenotifys for issuing the command once.
But Fvwm doesn't react well. Fvwm sees the event and knows the new
screen size but doesn't move anything around like it should.
I told Fvwm to execute a "recapture" and that helped.
I think if fvwm becomes aware of a new screen size, it makes sense
to re-position all the windows and icons.

I had a similar problem; not with icons, as I only use FvwmIconMan, but I have a FvwmButtons panel at the right edge of the screen which needs to be repositioned.

They way I handle it currently is -- outside of FVWM. I have a FIFO open on the nxagent log where I read its 'screen changed' message and subsequently restart the FvwmButtons module with FvwmCommand. That's far from perfect, of course. I thought maybe it would be an option to have the user define a ScreenResizeFunc or something like that, or maybe just feed the event into FvwmEvent.

Raimund