transient docks
Quite a few people are annoyed by the way that GIMP manages (or not manages) its windows. Users coming from the Windows world or using GIMP on Win32, typically demand a container window to embed all GIMP windows. I dislike that interface but I have to admit that GIMP should do a better job at handling its windows. The actual window handling is of course done by the window manager and there are plenty of window managers out there and each and every one behaves slightly differently. That doesn’t make this an easy task. All the application can do is to tell the window manager as much as possible about its windows and their relationships. This is defined in the Extended Window Manager Hints specification. Unfortunately, this spec doesn’t cope very well with an application like GIMP. There is for example no window type hint that would fit well for the GIMP toolbox.
Yesterday I added an option to GIMP to make the toolbox and all docks transient to the active image window. Inkscape uses this approach to keep the property windows over the document window. The same happens in GIMP; the toolbox and the dock containing layers, channels and such is kept over the image window, no matter what you are doing. There are some other side effects. Minimizing the image window also minimizes the docks. Deiconfiying it brings all the GIMP windows back. If you also set the utility window type hint on the docks, you will only see the active image window in the taskbar and the GIMP UI will appear a lot more like a single window.
So much for theory. In practice, it doesn’t work all that well and it depends a lot on your window manager. Sawfish for example seems to make the assumption that a window can only have at most one transient child and fails to bring all docks back if you deiconify the image window. Things start to become even more confusing as soon as you have more than one image window and iconfiy one of them or move it to a different desktop. I guess that some of these problems can be worked around in GIMP, other could be fixed in the window managers. This will need more work but it might be a step into the right direction.
The code is in CVS for you to try (gimp HEAD branch). Make sure you enable “Transient docks” in the Window Management section of the Preferences dialog. Your feedback is appreciated.
May 12th, 2005 at 5:59 pm
1. now working with gimp is much easier.
2. about gimp cvs head – i have such feeling that preferences dialog opens a bit slower than 2.2.6
3. there is no images if i aggregate only some categories from your blog (check http://planet.gimp.org.pl)
May 12th, 2005 at 6:02 pm
forget about 3rd point, it works now
May 12th, 2005 at 6:06 pm
The Preference dialog opens a good deal slower in the development version. We are using four GtkFileChooserButton widgets on the Color Management page and obviously the implementation of this widget is so damned stupid that it is almost unsuable. Unless this is improved in GTK+, we will most probably have to use GimpFileEntry instead.
May 12th, 2005 at 7:54 pm
I haven’t tried this out, but it sounds like a good idea. It would also help for common window managers to have better support for window groups. Sawfish had good support, at the cost of UI complexity; Metacity doesn’t really seem to have any (just a gconf option that doesn’t actually do anything).
Something else useful would be support (at the toolkit and window manager level) for a single visible application menu (either Mac-style or NeXT-style). One of the usability flaws in the GIMP is “which menu am I supposed to use”. In GIMP 1.x, it was “where is the menu for the image window”, which was solved with some duplication of functionality in GIMP 2.x. In a single application menu UI, that problem doesn’t arise, and also the tool pallettes don’t have to be overloaded to also contain the main application menu.
May 12th, 2005 at 8:46 pm
Does “transient windows” mean they are _always_ stacked over the actual image/document? Then please make some allowance to turn it off.
It is already nosebleed-inducingly annoying when tool dialogs place themselves on top of the image and just can’t be alt-tabbed behind it. When you run gimp on a relatively small screen, like on a laptop (or just want to use most or all of your big screen for your image), you:
* click on the crop tool
* drag the crop tool window to the bottom edge of the screen
* span out the crop rectangle, adjusting as it goes
* find then drag back the crop tool dialog
* check the proportions and resize x or y to get the proportion you need
* drag the crop tool dialog to the bottom edge again
* adjust the crop rectangle position
* drag the crop tool dialog _again_
* press “Crop”
Phew.
I would not like to have to do that kind of stuff for every single window.
For my use-case, it would really work a lot better if, for instance, the tool window is the “base” window, and all other dialogs are transient children to it. The image itself is totally separate.
So when I alt-tab the image, it jumps to the front of everything and I can edit away. When IU alt-tab again, _all_ open dialogs come to the front and I can click buttons and move sliders to my hearts content. When I’m done, I’m one alt-tab away from having my image in all its glory in front again.
That would also be a solution to having more than one image, I believe.
May 12th, 2005 at 10:54 pm
I use gimp from cvs.
Janne:
1. crop tool window is stacked over actual image whether transient window option is turned off or on.
2. imho crop tool window should be merge with “crop & resize option tab”, then there will be no pop-up which covers actual window. Than there should be option to hide/recall all docks with i.e. tab key. No problem with small screen.
3. transient option solves some problems when hint for toolbox and other docks is set to “utility window”
one situation: when you swith between some apps like web browser, irc, gimp and use no virtual desktops. Than if you switch back to gimp, you have to raise up all docks.
a) If you have transient option enabled you have to click only once, on image window on taskbar.
b) if you have also enabled hint for toolbox and other docks:utitility window, than there are only opened images on taskabar. No need to group windows on taskbar. That’s the way how inkscape works.
May 13th, 2005 at 11:54 am
Rofro: the crop tool is only one of them. All tools (but not filters) behave in the same way. Curves and Levels, for instance (two tools I use a lot for photo editing) both require me to physically move the windows to and from to see what I’m doing since I can’t just tab them behind the image.
And on my laptop (where I end up doing a lot of my editing since a morning train ride is perfect for this kind of thing), many dialogs take up up to a third of the horizontal or vertical space, making it infeasible to tile the image and tool dialog and still have enough resolution to actually see the result of my manipulations.
This isn’t the right place to discuss this, of course; just wanted to give a small heads-up that forcing stacking order is very very painful for some users.
May 16th, 2005 at 11:09 am
I like the fact that GIMP doesn’t have a parent window, When you start using it often, you realize its just the way it is,
What i would really like though is the options of each tool to appear in a vertical bar, like photoshop on OSX, not because photshop does it, but because i think it makes things easier. It will always be there visible, so you have already positioned your image somewhere where it doesn’t overlap, and you gain more space verticaly, plus you drop the popup menus for each tool, and just keep popup for filters.
May 17th, 2005 at 1:34 am
In addition to my recent post to the Inkscape devel list:
http://sourceforge.net/mailarchive/message.php?msg_id=11769154
all I can say is THANKS. In my opinion this is (was) the most important usability issue with GIMP. It’s a pity it took you so long to do this, but better late than never
I haven’t tried the 2.3 but I’m going to try it out as soon as I have some time.
Re: Insufficient standards support: I fully agree. But if the standard does not give us a 100% solution, we have to use the incomplete solution which is available NOW, and not just sit and wait. Establishing a practice is one way to influence standards development. The standard way of doing this was missing not because someone decided to omit it, but simply because no one thought about that need. GIMP has enough clout to make itself heard and to make this need obvious.
Re: Incompatible window manager implementations: Same here. I’m sure they are different in that aspect not for some deep reason, but simply because very few programs used transient flag before and so the window manager developers simply didn’t test this aspect well enough. Again, the fact that GIMP now uses this will go a long way to forcing them to make this behavior more consistent, making it a de-facto standard if not an official standard.
Some caveats from Inkscape experience:
- I don’t know if you are doing it already, but you should re-transientize all open docks to each document window when that window becomes active. This is how Inkscape emulates “group transientizing”, i.e. dialogs being transient not to a single window but to all the document windows as a group.
- We tried the utility window type hint for dialogs, but eventually turned it off, because it causes weird bugs on Windows and OSX (http://sourceforge.net/tracker/index.php?func=detail&aid=1074850&group_id=93438&atid=604306). On Linux, this hint did nothing at all in my testing. As for the taskbar, we call gtk_window_set_skip_taskbar_hint for that, the utility hint has no effect on that.
I will be very interested to see your code implementing this behavior, maybe we can borrow something from you. I also hope the window managers will respond to the GIMP challenge and fix their handling of transient windows wherever it is broken. This will greatly benefit both GIMP and Inkscape.
May 25th, 2005 at 12:37 pm
[...] y GIMP uses (or not) windows, then the next revision has much better control.
Related Stories (gimp:, layer, stylespanoramas [...]
February 12th, 2006 at 11:41 pm
I agree with Janne; this “feature” has given me nosebleeds on several occasions.
There are several useful window managers for Unix that can be configured to allow windows to selectively remain visible even while working on windows below them (disabling “raise on click” works in many window managers); being forced to have these toolbars covering the canvas is a major nuisance and Inkscape (an otherwise excellent program that I use daily) almost deserves a place in the hall of shame for its behavior in this regard.
I just found out that the insanity can be turned off! File -> Inkscape preferences -> Windows -> Dialogs on top
June 22nd, 2006 at 12:26 pm
I’m sorry, simply I can’t find “Transient docks” in the Window Management section of the Preferences dialog”.
I do find windows managment section and then only the option “keep above” “utility window” “normal window”.
“keep above” does not work…(..i did restart..)
I am running GIMP 2.2.11 on XP.
June 22nd, 2006 at 12:40 pm
The feature doesn’t exist in the stable version (2.2.x).