xreconfigurewmwindow() not supported

[mse2]

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]

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]

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]

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]

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]

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

[mse2]

Sure, Openbox for example.

[joewing]

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.

[bbidulock]

_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]

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]

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

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]

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]

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]

Commit 0d2a9e0d8a5e528acd77e6ca9770530ba283513e 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]

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]

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.