Wrong position of client window after maximize/normalize window

[mse2]

It has been reported that MSEgui applications:
http://sourceforge.net/projects/mseide-msegui/
don't work well with jwm 2.2.2. After maximizing/normalizing a MSEgui window by the frame buttons the position of the client window is wrong, maybe because of the staticgravity or other settings in xsetwmnormalhints() call.
The test project is here:
https://gitorious.org/mseuniverse/mseuniverse/source/testcase/window/clientwindowpos

[bbidulock]

You are setting PPostion, PSize, USPosition and USSize. That is wrong. Pick a pair. Also, few window managers respect either.

[mse2]

@bbidulock
It is a nightmare to make a toolkit which works with the myriad of different window mangers. It would be nice if you simplify the life of a toolmaker if you can. Up to now jwm AFAIK is the only WM which fails with the combined setting. Do you know if either PPostion, PSize or USPosition and USSize is sufficient for all other WM's? Which one of the pair?

[joewing]

I would say it's a nightmare to make a toolkit for X11 just in general. Window managers have the additional nightmare of dealing with the myriad of applications that abuse X11, ICCCM, and EWMH.
As far as this particular issue is concerned, I would note that completely ignoring these hints is a perfectly acceptable solution. The window manager is free to place a window how it sees fit.

Anyway, I think the problem is that JWM is applying the window gravity multiple times when restoring a window if PPosition or USPosition is set (JWM actually doesn't make a distinction between USPosition and PPosition).

[mse2]

I would say it's a nightmare to make a toolkit for X11 just in general.

I don't think so. MSEgui runs on Windows too and as a toolkit maker I much more prefer X11 over gdi32/user32. Z-order handling is the exception because not all WM's support
xreconfigurewmwindow() with "cwsibling or cwstackmode". If they would support it, X11 would be an almost perfect environment.

[mse2]

The effect is not caused by the xsetwmnormalhints() calll with PPostion, PSize, USPosition and USSize but the
win_gravity:= staticgravity setting in attributes for xcreatewindow().
Yes, I know that the WM can place the windows where it likes and the applications should not expect anything, but shifting the client area out of parent is a little bit impractical. ;-)

[bbidulock]

When I run a little test.pl, I get:

Initial:

Maximized:

Restored:

The little test program is here:
test.pl

JWM acts fine for static windows. You must be doing something wrong.

[mse2]

The important code is this:

  with attributes do begin 
   win_gravity:= staticgravity; <<<<<<<<<<<<<<<<<-------
   background_pixel:= 0;
  end;
  id:= xcreatewindow(msedisplay,mserootwindow,xpos1,ypos1,width1,height1,0,
             copyfromparent,copyfromparent,pvisual(copyfromparent),
             cwwingravity or cwbackpixel,@attributes);

[bbidulock]

$win->set_gravity('static') in the test does that.
xprop WM_NORMAL_HINTS shows:

WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified minimum size: 0 by 0
window gravity: Static

So, obviously you did not try running the program...

[mse2]

I am surprised about the aggressive and dismissive tone in the JWM community.
Anyway,

$win->set_gravity('static')

probably sets the wmnormalhints property the equivalent of

  xsetwmnormalhints(msedisplay,id,sizehints);

in my test program, this not the same as setting the window create attributes.

[bbidulock]

Pardon, me. ICCCM 2.0 4.1.6. Changing Window Attributes:

The window manager is free to override the window gravity; a reparenting window manager may want to set the top-level window's window gravity for its own purposes.

So, don't set it to 'static'. Set the win_gravity in WM_NORMAL_HINTS instead.

[mse2]

It seems to me that actually JWM does not override the window gravity but it should. ;-)
BTW, do you have a link where the window create attribute win_gravity=staticgravity is documented?
http://tronche.com/gui/x/xlib/window/attributes/#XSetWindowAttributes
http://tronche.com/gui/x/xlib/window/attributes/gravity.html
is not very clear to me. In experiments with embedded windows I found no difference in moving embedded window by moving the parent between staticgravity and northwestgravity.
Edit: got it, sizing not moving. And I remember now why staticgravity has been set many years before, there was a WM which worked better so and the known others had no problem with it...

[joewing]

Ideally JWM should handle static gravity. Even if the standard says it's not strictly necessary, there is code in JWM to handle the various window gravities, so it should work and if it doesn't there's a bug. I'm not sure what's going on in this case yet, but I plan to investigate this more when I get a chance.

[mse2]

Wmnormalhints sizehints works OK, the problem was that I set win_gravity=staticgravity in xcreatewindow attributes and JWM did not remove it before maximizing window, see my comment above. Seems already been fixed by bbidulock.

[bbidulock]

IceWM just sets win_gravity to NorthWestGravity before reparenting the window.

[bbidulock]

I protected 8 other window managers from that: icewm, blackbox, larswm, waimea, flwm, etwm, ctwm, adwm. 2bwm and mcwm don't reparent and are immune to that.

[joewing]

That makes sense.
@bbidulock: thanks for the fix!

[mse2]

Fixed, thanks a lot!