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

xreconfigurewmwindow() not supported #117

Closed
mse2 opened this Issue May 11, 2014 · 16 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. It seems that xreconfigurewmwindow() is not supported.
The test project is here:
https://gitorious.org/mseuniverse/mseuniverse/source/testcase/window/reconfigurewmwindow2

@bbidulock

This comment has been minimized.

Show comment
Hide comment
@bbidulock

bbidulock May 11, 2014

Contributor

Where are your test results? It appears that you are trying to set the position of a window using WM_NORMAL_HINTS, and particularly the x and y position. ICCCM 2.0 no longer supports this. You are setting static gravity, but static gravity only relates to the position of the window in the resulting decorative frame (i.e. the window will be in the same position relative to root as it would if it had no decorative frame).

Also, ICCCM 2.0 section 4.1.5 reads: "Clients must be aware that there is no guarantee that the window manager will allocate them the requested size or location and must be prepared to deail with any size and location. If the window manager decides to respond to a ConfigureRequest request by not changing the size, location, border width, or stacking order of the window at all [a] client will receive a synthetic ConfigureNotify event that describes the (unchanged) geometry of the window. ...."

So it appears your expectations in response to this test are unrealistic.

Contributor

bbidulock commented May 11, 2014

Where are your test results? It appears that you are trying to set the position of a window using WM_NORMAL_HINTS, and particularly the x and y position. ICCCM 2.0 no longer supports this. You are setting static gravity, but static gravity only relates to the position of the window in the resulting decorative frame (i.e. the window will be in the same position relative to root as it would if it had no decorative frame).

Also, ICCCM 2.0 section 4.1.5 reads: "Clients must be aware that there is no guarantee that the window manager will allocate them the requested size or location and must be prepared to deail with any size and location. If the window manager decides to respond to a ConfigureRequest request by not changing the size, location, border width, or stacking order of the window at all [a] client will receive a synthetic ConfigureNotify event that describes the (unchanged) geometry of the window. ...."

So it appears your expectations in response to this test are unrealistic.

@mse2

This comment has been minimized.

Show comment
Hide comment
@mse2

mse2 May 11, 2014

Our users expect that a window stacking order defined by a xreconfigurewmwindow(msedisplay,id2,msedefaultscreenno,
cwsibling or cwstackmode,@changes); call
actually changes the stacking order. How do you suggest to restore the window stacking order of an application after restart for example?

mse2 commented May 11, 2014

Our users expect that a window stacking order defined by a xreconfigurewmwindow(msedisplay,id2,msedefaultscreenno,
cwsibling or cwstackmode,@changes); call
actually changes the stacking order. How do you suggest to restore the window stacking order of an application after restart for example?

@joewing

This comment has been minimized.

Show comment
Hide comment
@joewing

joewing May 11, 2014

Owner

I guess I don't understand the use case. If there is a dialog that should be on top, then it should have the TRANSIENT_FOR hint set. Otherwise, an application shouldn't really care to that level of deal about window stacking. If the application does, then I would suggest setting override_redirect and managing the windows yourself.

Adding support for this should be possible, but it's not something I've seen used before.

Owner

joewing commented May 11, 2014

I guess I don't understand the use case. If there is a dialog that should be on top, then it should have the TRANSIENT_FOR hint set. Otherwise, an application shouldn't really care to that level of deal about window stacking. If the application does, then I would suggest setting override_redirect and managing the windows yourself.

Adding support for this should be possible, but it's not something I've seen used before.

@mse2

This comment has been minimized.

Show comment
Hide comment
@mse2

mse2 May 11, 2014

Take MSEide as example. MSEide saves the Z-order of the tool windows in the project file. After opening a project it restores the positions and Z-order of the windows. A double click on a component in form editor activates the object editor with the selected component and places it on top of the window stack. This seems not to be possible with JWM.
Activating the main menu by a short-cut-key raises the main window in order the whole menu bar is visible, after the menu has been closed the original Z-position of the main window will be restored.

Adding support for this should be possible, but it's not something I've seen used before.

MSEgui applications have a sophisticated window docking system with panels. Most of the usual non MSEgui applications have a single window only, most likely because of the problems with the WM's i assume. ;-)

mse2 commented May 11, 2014

Take MSEide as example. MSEide saves the Z-order of the tool windows in the project file. After opening a project it restores the positions and Z-order of the windows. A double click on a component in form editor activates the object editor with the selected component and places it on top of the window stack. This seems not to be possible with JWM.
Activating the main menu by a short-cut-key raises the main window in order the whole menu bar is visible, after the menu has been closed the original Z-position of the main window will be restored.

Adding support for this should be possible, but it's not something I've seen used before.

MSEgui applications have a sophisticated window docking system with panels. Most of the usual non MSEgui applications have a single window only, most likely because of the problems with the WM's i assume. ;-)

@bbidulock

This comment has been minimized.

Show comment
Hide comment
@bbidulock

bbidulock May 11, 2014

Contributor

Is there any X11 window manager that does what you want?

Contributor

bbidulock commented May 11, 2014

Is there any X11 window manager that does what you want?

@mse2

This comment has been minimized.

Show comment
Hide comment
@mse2

mse2 May 11, 2014

Sure, Openbox for example.

mse2 commented May 11, 2014

Sure, Openbox for example.

@joewing

This comment has been minimized.

Show comment
Hide comment
@joewing

joewing May 12, 2014

Owner

I agree that this would be a nice thing for JWM to support and I'll probably get around to supporting it some day, but I don't think well-behaved applications should rely on this.

I think JWM does support doing what you want. If I'm not mistaken, many applications do things much like you want, take audacious as an example. Using something like _NET_ACTIVE_WINDOW from the EWMH would be the preferred method of raising a window.

Owner

joewing commented May 12, 2014

I agree that this would be a nice thing for JWM to support and I'll probably get around to supporting it some day, but I don't think well-behaved applications should rely on this.

I think JWM does support doing what you want. If I'm not mistaken, many applications do things much like you want, take audacious as an example. Using something like _NET_ACTIVE_WINDOW from the EWMH would be the preferred method of raising a window.

@joewing joewing added the enhancement label May 12, 2014

@bbidulock

This comment has been minimized.

Show comment
Hide comment
@bbidulock

bbidulock May 12, 2014

Contributor

_NET_ACTIVE_WINDOW doesn't always work. For example, IceWM just flashes the task bar for the window when a client attempts that and waits for the user to "select" the window. Applications should not attempt things like that because they are not privy to the user's preferred focus/autoraise/layout model. Just about every tiling window manager out there ignores all configuration attempts for non-floating windows. Misbehaving applications built that way will find themselves working with only a retricted set of yesteryear's technologies. If the application wants to manage its own windows in this way it needs to set override-redirect.

Contributor

bbidulock commented May 12, 2014

_NET_ACTIVE_WINDOW doesn't always work. For example, IceWM just flashes the task bar for the window when a client attempts that and waits for the user to "select" the window. Applications should not attempt things like that because they are not privy to the user's preferred focus/autoraise/layout model. Just about every tiling window manager out there ignores all configuration attempts for non-floating windows. Misbehaving applications built that way will find themselves working with only a retricted set of yesteryear's technologies. If the application wants to manage its own windows in this way it needs to set override-redirect.

@mse2

This comment has been minimized.

Show comment
Hide comment
@mse2

mse2 May 12, 2014

Then it probably should be stated on
http://joewing.net/projects/jwm/
and in the docs that JWM is intended for single window applications only and does not support multiple windows per application. Sad because MSEide+MSEgui and JWM would match very well - MSEide+MSEgui also needs solely Xlib. JWM seems not to be ICCCM compilant:
http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.5
because it does not support:

Clients can resize and reposition their top-level windows by using the ConfigureWindow request. The attributes of the window that can be altered with this request are as follows:
...
The window's position in the stack

mse2 commented May 12, 2014

Then it probably should be stated on
http://joewing.net/projects/jwm/
and in the docs that JWM is intended for single window applications only and does not support multiple windows per application. Sad because MSEide+MSEgui and JWM would match very well - MSEide+MSEgui also needs solely Xlib. JWM seems not to be ICCCM compilant:
http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.5
because it does not support:

Clients can resize and reposition their top-level windows by using the ConfigureWindow request. The attributes of the window that can be altered with this request are as follows:
...
The window's position in the stack

@joewing

This comment has been minimized.

Show comment
Hide comment
@joewing

joewing May 12, 2014

Owner

@mse2: I am unaware of another application that requires this ability. This includes applications that successfully manage multiple windows (for example, audacious in "winamp" mode or Xilinx ISE). Modern applications use _NET_ACTIVE_WINDOW. From ICCCM 4.1.5 (the last paragraph):

Window managers are in any case free to position windows in the stack as they see fit, and so clients should not rely on receiving the stacking order they have requested. Clients should ignore the above-sibling field of both real and synthetic ConfigureNotify events received on their top-level windows because this field may not contain useful information.

Regardless, JWM supports _NET_ACTIVE_WINDOW from EWMH, which allows this ability. As @bbidulock notes, however, there are window managers that don't even support that. Such window managers can indeed be fully ICCCM compliant.

Owner

joewing commented May 12, 2014

@mse2: I am unaware of another application that requires this ability. This includes applications that successfully manage multiple windows (for example, audacious in "winamp" mode or Xilinx ISE). Modern applications use _NET_ACTIVE_WINDOW. From ICCCM 4.1.5 (the last paragraph):

Window managers are in any case free to position windows in the stack as they see fit, and so clients should not rely on receiving the stacking order they have requested. Clients should ignore the above-sibling field of both real and synthetic ConfigureNotify events received on their top-level windows because this field may not contain useful information.

Regardless, JWM supports _NET_ACTIVE_WINDOW from EWMH, which allows this ability. As @bbidulock notes, however, there are window managers that don't even support that. Such window managers can indeed be fully ICCCM compliant.

@joewing

This comment has been minimized.

Show comment
Hide comment
@joewing

joewing May 12, 2014

Owner

Actually, I just realized that _NET_ACTIVE_WINDOW doesn't raise the window in JWM. I thought it did (perhaps it should?). Anyway, as it stands, it appears that setting the TRANSIENT_FOR hint is the only way to keep one window above another in JWM (which is how audacious works).

EDIT: Sorry, apparently I can't read my own code. _NET_ACTIVE_WINDOW does raise the client.

Owner

joewing commented May 12, 2014

Actually, I just realized that _NET_ACTIVE_WINDOW doesn't raise the window in JWM. I thought it did (perhaps it should?). Anyway, as it stands, it appears that setting the TRANSIENT_FOR hint is the only way to keep one window above another in JWM (which is how audacious works).

EDIT: Sorry, apparently I can't read my own code. _NET_ACTIVE_WINDOW does raise the client.

@mse2

This comment has been minimized.

Show comment
Hide comment
@mse2

mse2 May 12, 2014

MSEgui uses the transient for hint for the stack of modal windows. xraisewindow() is used for the mentioned double click on components or for a double click in a row with a breakpoint in MSEide source editor where it activates the breakpoints window. I can additonally fire the _NET_ACTIVE_WINDOW protocol if there are no side effects with other WM's. Contrary to modal windows the user later can change the stacking order by focusing another window. Do you recommend that we set TRANSIENT_FOR for all windows, wait until WM stacks the windows accordingly and remove the TRANSIENT_FOR hint afterward? Would this work with all WM's? In which order should TRANSIENT_FOR be applied and removed? How can the Z-position of the main window be restored after closing the main menu without disturbing the stacking order of the other windows? Maybe you are right that you never seen something like MSEgui. MSEgui tries to provide optimal solutions which often are innovative.
MSEgui actually ignores the sibling field of ConfigureNotify, it queries the stacking order from server.

mse2 commented May 12, 2014

MSEgui uses the transient for hint for the stack of modal windows. xraisewindow() is used for the mentioned double click on components or for a double click in a row with a breakpoint in MSEide source editor where it activates the breakpoints window. I can additonally fire the _NET_ACTIVE_WINDOW protocol if there are no side effects with other WM's. Contrary to modal windows the user later can change the stacking order by focusing another window. Do you recommend that we set TRANSIENT_FOR for all windows, wait until WM stacks the windows accordingly and remove the TRANSIENT_FOR hint afterward? Would this work with all WM's? In which order should TRANSIENT_FOR be applied and removed? How can the Z-position of the main window be restored after closing the main menu without disturbing the stacking order of the other windows? Maybe you are right that you never seen something like MSEgui. MSEgui tries to provide optimal solutions which often are innovative.
MSEgui actually ignores the sibling field of ConfigureNotify, it queries the stacking order from server.

@joewing

This comment has been minimized.

Show comment
Hide comment
@joewing

joewing May 12, 2014

Owner

See here (around line 70) for how Chromium raises a window. It uses XRaiseWindow only if the window manager doesn't support EWMH.

For simply raising a window, I would not use the transient hint.

Owner

joewing commented May 12, 2014

See here (around line 70) for how Chromium raises a window. It uses XRaiseWindow only if the window manager doesn't support EWMH.

For simply raising a window, I would not use the transient hint.

@joewing

This comment has been minimized.

Show comment
Hide comment
@joewing

joewing May 15, 2014

Owner

Commit 0d2a9e0 should add support for this. Windows are still confined to their layer. TopIf and BottomIf don't work exactly as documented yet and I'm not sure it's worth the effort to implement them completely.

I think a possible enhancement would be to prevent a client from raising a window to the top of the stack unless a window with the same WM_CLASS is at the top of the stack.

Owner

joewing commented May 15, 2014

Commit 0d2a9e0 should add support for this. Windows are still confined to their layer. TopIf and BottomIf don't work exactly as documented yet and I'm not sure it's worth the effort to implement them completely.

I think a possible enhancement would be to prevent a client from raising a window to the top of the stack unless a window with the same WM_CLASS is at the top of the stack.

@mse2

This comment has been minimized.

Show comment
Hide comment
@mse2

mse2 May 15, 2014

Seems to work, thanks a lot! :-)
MSEgui does not use TopIf and BottomIf.

I think a possible enhancement would be to prevent a client from raising a window to the top of the stack unless a window with the same WM_CLASS is at the top of the stack.

I don't know. Applications who manage there own Z-order stack should know what they do, implementing limitations is maybe not a good idea.

mse2 commented May 15, 2014

Seems to work, thanks a lot! :-)
MSEgui does not use TopIf and BottomIf.

I think a possible enhancement would be to prevent a client from raising a window to the top of the stack unless a window with the same WM_CLASS is at the top of the stack.

I don't know. Applications who manage there own Z-order stack should know what they do, implementing limitations is maybe not a good idea.

@joewing

This comment has been minimized.

Show comment
Hide comment
@joewing

joewing May 16, 2014

Owner

My concern is that a window that is buried while the user is using another application,could push itself to the front unexpectedly. So it might make sense to prohibit applications from moving windows more than one level above the applications top-most window.
In any case, I'll leave that for a future enhancement if the need arises.

Owner

joewing commented May 16, 2014

My concern is that a window that is buried while the user is using another application,could push itself to the front unexpectedly. So it might make sense to prohibit applications from moving windows more than one level above the applications top-most window.
In any case, I'll leave that for a future enhancement if the need arises.

@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