New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong position of client window after maximize/normalize window #115

Closed
mse2 opened this Issue May 11, 2014 · 17 comments

Comments

Projects
None yet
3 participants
@mse2

mse2 commented May 11, 2014

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
clientwindowpos

@bbidulock

This comment has been minimized.

Show comment
Hide comment
@bbidulock

bbidulock May 11, 2014

Contributor

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

Contributor

bbidulock commented May 11, 2014

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

@mse2

This comment has been minimized.

Show comment
Hide comment
@mse2

mse2 May 11, 2014

@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?

mse2 commented May 11, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@joewing

joewing May 11, 2014

Owner

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).

Owner

joewing commented May 11, 2014

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

This comment has been minimized.

Show comment
Hide comment
@mse2

mse2 May 11, 2014

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 commented May 11, 2014

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

This comment has been minimized.

Show comment
Hide comment
@mse2

mse2 May 15, 2014

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. ;-)

clientshift

mse2 commented May 15, 2014

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. ;-)

clientshift

@bbidulock

This comment has been minimized.

Show comment
Hide comment
@bbidulock

bbidulock May 15, 2014

Contributor

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

Initial:
shot1

Maximized:
shot2

Restored:
shot3

The little test program is here:
test.pl

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

Contributor

bbidulock commented May 15, 2014

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

Initial:
shot1

Maximized:
shot2

Restored:
shot3

The little test program is here:
test.pl

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

@mse2

This comment has been minimized.

Show comment
Hide comment
@mse2

mse2 May 15, 2014

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);

mse2 commented May 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@bbidulock

bbidulock May 15, 2014

Contributor

$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...

Contributor

bbidulock commented May 15, 2014

$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

This comment has been minimized.

Show comment
Hide comment
@mse2

mse2 May 15, 2014

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.

mse2 commented May 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@bbidulock

bbidulock May 15, 2014

Contributor

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.

Contributor

bbidulock commented May 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@mse2

mse2 May 15, 2014

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...

mse2 commented May 15, 2014

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...

bbidulock added a commit to bbidulock/jwm that referenced this issue May 15, 2014

get rid of issue #115
 when reparenting client window:

 - sets backing store to NotUseful
 - sets win gravity to NorthWestGravity

 in case client did something stupid with these values.
@joewing

This comment has been minimized.

Show comment
Hide comment
@joewing

joewing May 15, 2014

Owner

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.

Owner

joewing commented May 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@mse2

mse2 May 15, 2014

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.

mse2 commented May 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@bbidulock

bbidulock May 15, 2014

Contributor

IceWM just sets win_gravity to NorthWestGravity before reparenting the window.

Contributor

bbidulock commented May 15, 2014

IceWM just sets win_gravity to NorthWestGravity before reparenting the window.

@bbidulock

This comment has been minimized.

Show comment
Hide comment
@bbidulock

bbidulock May 15, 2014

Contributor

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.

Contributor

bbidulock commented May 15, 2014

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 added a commit that referenced this issue May 15, 2014

@joewing joewing added the bug label May 15, 2014

@joewing joewing added this to the Version 2.2.3 milestone May 15, 2014

@joewing

This comment has been minimized.

Show comment
Hide comment
@joewing

joewing May 15, 2014

Owner

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

Owner

joewing commented May 15, 2014

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

@mse2

This comment has been minimized.

Show comment
Hide comment
@mse2

mse2 May 16, 2014

Fixed, thanks a lot!

mse2 commented May 16, 2014

Fixed, thanks a lot!

@joewing joewing closed this May 16, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment