GNOME Bugzilla – Bug 319099
program, dialogs, etc only open in first viewport
Last modified: 2009-06-09 02:57:14 UTC
Please describe the problem: When running GIMP under afterstep, no matter which viewport i try to run the program from, it always opens in the top-left viewport. if i move gimp's toolbar to a different one, any other dialogs/windows will continue to open in the first viewport. Steps to reproduce: 1. use AfterStep as window manager 2. change to other than top-left viewport 3. run gimp Actual results: splash will be on the current viewport, gimp will then open on the top left viewport Expected results: it should open on the current viewport Does this happen every time? yes Other information: after some discussion on the AS mailing list, it appears gimp may be incorrectly using the "user position" flag, which window managers are suppose to respect as being the correct geometry.
GIMP does indeed use gtk_window_set_geometry_hints() with the GDK_HINT_USER_POS flag. This is done to make sure that the window position isn't changed when being shown/hidden. I don't see anything wrong about this. Please point us to the relevant part of the ICCCM and EWMH specs that you think we are violating here.
as cited by one of the AfterStep devs: Section 4.1.2.3. "To indicate that the size and position of the window (when a transition from the Withdrawn state occurs) was specified by the user, the client should set the USPosition and USSize flags, which allow a window manager to know that the user specifically asked where the window should be placed or how the window should be sized and that further interaction is superfluous. To indicate that it was specified by the client without any user involvement, the client should set PPosition and PSize . " now, sure, i suppose you could sorta say its the user requesting these posistions. but anyhow. after testing it some more on Afterstep and then on KDE, i dont see anything keeping their position from being shown/hidden. also, after reading over the ChangeLog.pre-2-0, theres 5 entries that reference "GDK_HINT_USER_POS" and only the 2nd entry stated it was removed "because they caused problems with some window managers", but then was put back in 3 days later. so much for "some window managers", eh? granted this was all in 2003. i'm still rather perplexed by it, dialogs such as layers, pallettes, etc will open up in the same viewport as the current workspace. but the file options.. open/save will always open in the first viewport. i dont know the technical aspects with kde, and how it handles its multi- desktop environment, since i dont think they use viewports, but just seperate virtual desks. so this may just be a limited bug to window managers that use multiple viewports. i'll prolly continue my own looking into whats so different and what could be the technical cause of it. i'm no coding expert, but i'm rather efficient at reading code. worse case, AS dev is already working on how to "fix" this problem at the window manager level, via bypassing whatever gimp is trying to tell it and using real user-defined values.
It might be a good idea to point one of the AS developers to this bug, to prevent information from getting lost in translation.
Reopening since the requested information has been provided.
Problem here comes from the fact that whenever USER specifies geometry under window manager that uses virtual viewports - such geometry must be provided in relation to the DESKTOP ORIGIN, so that the window can be placed anywhere on the desktop, even on the viewport that is off-screen. But when PPosition is used - it is always treated in relation to CURRENT VIEWPORT, as application presumably may not be aware of virtual desktops. So when GIMP is using USPosition - it is always treated in relation to the desktop, and as, apparently GIMP is not aware of possibility of virtual viewports and is not taking it into consideration while saving its geometry - it works wierd. If GIMP really REALLY needs USPosition, which I doubt, It should at least check for presence of _NET_DESKTOP_* properties on the root window, described in http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2449425 and take current viewport into consideration while saving/restoring its geometry. That is not a 100% safe solution, as viewport may change, while GIMP is mapping its windows, causing them to go off-screen. So really, I would strongly suggest that GIMP stops abusing USPosition, and stick to PPosition, which is a proper way to behave. If PPosition gets ignored by a Window Manager - Window Manager is completely at its rights to do so, and GIMP should not try and sneak around it. Placement policy is entirely responcibility of a Window Manager, and apps have no bussiness trying and influence it in any way. Now the fact that USPosition should always be in relation to desktop origin is not an explicit standard in any specs, and probably should be mentioned in ExtWM specs. I'll pop that question on ML. But I can hardly imagine any window manager that has virtual viewports not treating it like that, as that makes it impossible for user to start apps in a viewport different from current.
A patch that changes the behaviour would make it a lot more likely that this will ever get changed. We aren't really reluctant to do such a change or claiming that GIMP would do the right thing. But it appears it is not a problem for many of our users and especially not for any of the active GIMP developers.
Closing as WONTFIX because nobody has ever reported anything like that, indicating that all other window managers seem to be able to open gimp windows on the current viewport.
i've totally forgotten this issue. but since i received an email... last i recall, since we knew it wouldnt be fixed properly (if at all), we found a way of overriding gimp's error and forcing it to do the proper thing.