Hi and thanks for the bug report!

I don't see why this could not be done by the window manager already given the hints we give, but maybe we could give more/better hints.

The window manager does not know enough to implement this properly for GIMP. In my opinion the requested behavior would make sense. It is however not specified in http://gui.gimp.org/index.php/No_image_open_specification.

Please start a discussion on the gimp-developer mailing-list about this. We need the UI team to make a decision on this before any changes can be implemented.

Peter said that minimising all image windows, or the no-image-window, should minimise the whole app, meaning the toolbox and inspectors get hidden.

Created attachment 121176 [details] [review]
proposed patch

The patch I am attaching here is quite straight-forward and seems to work nicely. It has one drawback though:

The user can already hide/unhide the toolbox and docks using the Tab key. The patch hooks into this functionality. This means that if the user hides the toolbox and docks using the Tab key, then iconifies the image window and deiconfies it again, the toolbox and docks will be shown again.

It should be possible to work around this but it would introduce additional complexity, so I would like to know if this is considered a problem at all.

Interestingly enough, on Windows (with the latest gtk-2-14, which maps GDK's "utility window hints" into the WS_EX_TOOLWINDOW extended window style) GIMP already works like in comment #3, without any explicit code to handle that;) For once Windows apparently happens to do the right thing by itself...

Re: comment #4

this snag is a problem, an annoying problem because users have no model/clue why this should happen.

*** Bug 557491 has been marked as a duplicate of this bug. ***

I have committed this and another change to trunk. The additional change eliminates the problem outlined in comment #4. As long as no problems are reported against the behavior in trunk, I will merge these changes to the gimp-2-6 branch for the 2.6.2 release.

Merged to gimp-2-6:

2008-10-24  Sven Neumann  <sven@gimp.org>

        Bug 556896 – Dialogs don't get minimized with single image window

	* app/display/gimpdisplayshell.c
	* app/display/gimpdisplay-foreach.[ch]
	* app/widgets/gimpdialogfactory.[ch]: merged changes from trunk.
	Hide the toolbox and docks if the last display is iconified.
	Unhide them if a display is uniconified.

This is really annoying, can we please have an option to turn it off?

Just an initial list of problems:

00:16:41 <Mikachu> okay, it finished compiling
00:16:44 <Mikachu> it's sooo buggy
00:16:51 <Mikachu> if you iconify the toolbox first, then iconify the niw
00:16:57 <Mikachu> the toolbox unmaps while being iconified
00:17:06 <Mikachu> and this causes the iconified icon to disappear from 
the taskbar
00:17:22 <Mikachu> if you then click the niw button, it uniconifies, and 
the toolbox again maps still iconified
00:17:54 <Mikachu> forgetting that issue
00:18:00 <Mikachu> if i just leave them alone and switch away
00:18:11 <Mikachu> the toolbox unmaps (not iconifies), the niw is intact
00:18:19 <Mikachu> when i switch back, the toolbox maps, in an iconified 
state
00:18:30 <Mikachu> if i uniconify it, it uniconifies (can't hurt to be 
explicit)
00:18:36 <Mikachu> then, when i switch away, it again unmaps
00:18:43 <Mikachu> but when i switch back it maps uniconified
00:18:57 <akk> Right, I found that too
00:19:07 <Mikachu> another bug is
00:19:09 <akk> if I chose it from gimp's Windows menu, it would appear 
again
00:19:10 <Mikachu> you iconify the niw
00:19:14 <Mikachu> the toolbox unmaps
00:19:19 <akk> and after that, if I switch away, then back, it's still 
there
00:19:20 <Mikachu> you click the niw button in your taskbar
00:19:23 <Mikachu> the niw uniconifies
00:19:27 <Mikachu> the toolbox maps
00:19:29 <Mikachu> steals focus from the niw
00:19:35 <Mikachu> you click the niw button again
00:19:37 <Mikachu> the niw finally gets focus

and that's just in three minutes. (using trunk/r27446)

rubikcube saw this first under windowmaker and commented in #gimp, and I saw it in openbox.

What the user sees (with Normal hints, so the image window isn't always covered by the toolbox and docks):
Switch desktops away from gimp, then switch back.
The Toolbox and all docks have disappeared. TAB doesn't bring them back.

The only way I found to bring them back is the <Image>Windows menu, separate actions for the toolbox and each dock that was visible. After that they no longer iconify/disappear, and if I switch desktops away then back, now they become visible along with the image window. I assume that's the "maps back uniconified" that Mikael was seeing.

What you are describing is a broken window manager. I have already spent some time trying to debug this. The window manager iconifies the windows when leaving the desktop and sometimes simply fails to notify the application when they are deiconified. It seems impossible to fix this on the application level.

What I can't reproduce (using sawfish) is the following:

 Switch desktops away from gimp, then switch back.
 The Toolbox and all docks have disappeared. TAB doesn't bring them back.

The docks are sometimes not visible after coming back to the desktop, but they do appear in the task-bar. So GIMP obviously did correctly bring them back. The window manager just failed to map them again.

Even if that fails, the TAB key should always bring them back. The code that handles the Tab key does not make any extra checks on why the windows have been hidden.

http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2505544

"The second option is to keep all managed windows as children of the root window and unmap the frames of those which are not on the current desktop. Unmapped windows should be placed in IconicState, according to the ICCCM. Windows which are actually iconified or minimized should have the _NET_WM_STATE_HIDDEN property set, to communicate to pagers that the window should not be represented as "onscreen.""

Correct. But when going back to that desktop, the windows should be restored from that iconic state. This is what some window managers seem to get wrong. GIMP does not get a WindowState event from GDK then. This works fine with metacity.

When the window is mapped and iconified when i return, it has the initial window state set to iconicstate, so i doubt it's the wm's fault.

After startup:
Initial state is Normal State.
After switching to another desktop:
Initial state is Normal State.
After switching back:
Initial state is Iconic State.

This btw only happens the first time per gimp session, after that it maps in normalstate every time.

Even if this didn't happen, we still have the other two bugs:
* If I manually iconify the toolbox, and then iconify the niw, the toolbox disappears for no good reason, and reappears still iconified after i restore the niw. IE all your fancy code does is remove the taskbar button while the niw is icionified, very useful.
* Everytime you move back to the desktop or uniconify the niw, the toolbox steals focus so you have to click the desired window twice.

There's nothing fancy about the code. Actually it is extremely simple.

(In reply to comment #16)

> * If I manually iconify the toolbox, and then iconify the niw, the toolbox
> disappears for no good reason, and reappears still iconified after i restore
> the niw.

That sounds like the expected behavior. It is exactly what this bug report and the UI team is asking for. Hide the toolbox and docks if the main window is minimized.

> * Everytime you move back to the desktop or uniconify the niw, the toolbox
> steals focus so you have to click the desired window twice.

This is bad. But it doesn't happen with the window manager I am using. For the toolbox and dock windows we have explicitly unset focus_on_map. So this is clearly a window manager bug.

Sorry, but it looks like we can only blame the window manager here. Unless we find a reliable workaround, perhaps the best option is to add an option to the preferences that allows to switch this off in case the WM misbehaves.

(In reply to comment #17)
> There's nothing fancy about the code. Actually it is extremely simple.
> 
> (In reply to comment #16)
> 
> > * If I manually iconify the toolbox, and then iconify the niw, the toolbox
> > disappears for no good reason, and reappears still iconified after i restore
> > the niw.
> 
> That sounds like the expected behavior. It is exactly what this bug report and
> the UI team is asking for. Hide the toolbox and docks if the main window is
> minimized.
>
> > * Everytime you move back to the desktop or uniconify the niw, the toolbox
> > steals focus so you have to click the desired window twice.
> 
> This is bad. But it doesn't happen with the window manager I am using. For the
> toolbox and dock windows we have explicitly unset focus_on_map. So this is
> clearly a window manager bug.

Your conclusion here is somewhat arrogant. It could just as well be a bug in gtk (or gimp is using the function incorrectly perhaps). In this case, it is both. Openbox doesn't check for _NET_WM_USER_TIME being 0 at map time, and gimp doesn't set it to 0. I've made openbox print out the user_time value when a window maps and this is what i get when the gimp starts up:
0
here is what i get after pressing tab twice in the niw:
0
now, let's assume i'm using the gimp, this usually includes clicking in the toolbox, after doing that and pressing tab twice in the niw (or realistically, the image window):
1173703904

gtk+ does this,
  if (gtk_window_get_focus_on_map (window))
    gdk_window_set_focus_on_map (widget->window, TRUE);
  else
    gdk_window_set_focus_on_map (widget->window, FALSE);

It does this, however, in gtk_window_realize. I can only assume that gtk_widget_hide doesn't unrealize the widget, is that the case?

> Sorry, but it looks like we can only blame the window manager here. Unless we
> find a reliable workaround, perhaps the best option is to add an option to the
> preferences that allows to switch this off in case the WM misbehaves.

I still don't quite understand why the erraneous iconification state only occurs the _first_ time you switch away, and never after that... akk even tried disabling openbox's setting the window to IconicState, but it still happens, she says.

And I have a counter argument to this:
"Actual results:
"Dialogs stay put, which serves no useful purpose since a new image can't be
"created from them any more.

The "Document History" dialog lets you open new image windows. (And doing so correctly de-iconifies the niw btw :)

See, I don't understand all these details about window management, nor should I have to care about them. Of course there can be bugs at the GTK+ level as well. 

The change I introduced is actually very simple. If the image window is iconified, hide the dock windows. If it is uniconified, show the dock windows. This is a few lines of code and it works absolutely correct here.

Actually if there are no image windows left that are visible (in which way whatsoever that should be defined at a window manager level), the dialogs/docks are hidden (and thus iconified).  This part seems to work on every window manager, it is even called when one switches away from GIMP's workspace (since then no image windows are visible any more).

What's surprising me is that gtk_widget_show(.) (which is called for all dialogs on reentering GIMP's workspace) does not seem to be able to restore those iconified dialogs.

In case it helps, here is some output from "xprop -spy" on the toolbox window, each section refers to switching workspaces away and back again.

=========
Windowmaker (shows the behaviour described in this bug):
====
WM_STATE(WM_STATE):
		window state: Withdrawn
		icon window: 0x0
_NET_WM_DESKTOP:  not found.
_NET_WM_STATE:  not found.
_NET_WM_ALLOWED_ACTIONS:  not found.
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Iconic State.
		bitmap id # to use for icon: 0x2a000a6
		bitmap id # of mask for icon: 0x2a000a8
		window id # of group leader: 0x2a00001
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_STICK, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE
_NET_WM_DESKTOP(CARDINAL) = 4
_NET_WM_STATE(ATOM) = _NET_WM_STATE_HIDDEN, _NET_WM_STATE_SKIP_PAGER

%% Note: I think this is where I switched back

WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x484b6c
WM_STATE(WM_STATE):
		window state: Iconic
		icon window: 0x1
_NET_WM_STATE(ATOM) = _NET_WM_STATE_HIDDEN, _NET_WM_STATE_SKIP_PAGER

========
fluxbox (works):
===

WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_BLACKBOX_ATTRIBUTES(_BLACKBOX_ATTRIBUTES) = 0x10, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0
_WIN_STATE(CARDINAL) = 0
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_STICK, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_FULLSCREEN


========
KDE 3.5.9 (works):
===

_NET_WM_STATE(ATOM) = 
WM_STATE:  not found.
WM_STATE:  not found.
_NET_WM_DESKTOP:  not found.
_NET_WM_STATE(ATOM) = 
_NET_FRAME_EXTENTS:  not found.
_KDE_NET_WM_FRAME_STRUT:  not found.
_NET_WM_ICON_GEOMETRY:  not found.
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
		bitmap id # to use for icon: 0x8000ae
		bitmap id # of mask for icon: 0x8000b0
		window id # of group leader: 0x800001
_NET_WM_STATE(ATOM) = 
_NET_WM_DESKTOP(CARDINAL) = 1
_NET_FRAME_EXTENTS(CARDINAL) = 4, 4, 21, 4
_KDE_NET_WM_FRAME_STRUT(CARDINAL) = 4, 4, 21, 4
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE
_NET_WM_STATE(ATOM) = 
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_NET_WM_ICON_GEOMETRY(CARDINAL) = 509, 978, 200, 23

I have backed out this change in the gimp-2-6 branch for now. This gives us more time to look for a way to implement this so that it works with more window managers. Or to get the window managers fixed.

Hi

today I downlaoded the new version 2.6.2 - this error didn't occure again. A

sincereley
Franz Wein

2.6.2 on x64 Windows still possesses this bug.  Haven't upgraded my Linux boxes so I can't comment on those.  Will try a purge and reinstall of GIMP and GTK.

Just thinking out loud, but how about a return to the 2.4 interface?  The separate windows for the toolbox and inspectors worked well. It was easy to switch between with Alt-Tab which works in _every_ window manager including AfterSTEP.  I understand the idea of trying to keep a PhotoShop-style interface but what about differentiation?

Created attachment 122695 [details] [review]
for the record, here's the change that was later reverted in gimp-2-6

Michael: Are you talking about different "window managers" on Windows? I doubt any acual developer/maintainer of GIMP on Windows, or more likely, GTK+, wants to spend any time on supporting other "windows managers" than the normal built-in Windows one. People who insist on breaking their systems by replacing their "shell" (as I think the correct term on Windows is) on Windows can frankly help themselves. There is quite enough work in supporting the standard Windows environment wihout any 3rd-party "enhancements". When comments in bug reports talk about window managers, they refer to window managers as used on X11 (i.e. Linux and other Unix systems, in practise). And the code in GTK+ that interfaces to those has very little to do with the code for Windows.

Sven, Thanks for the patch!  However, I don't have any way to apply it.  I'm not a Windows dev, I don't have the source and I have no tools for compiling such a change.  Sorry!  I do appreciate you attaching that, though.

Tor, no; I'm talking about different window managers not specifically Windows.  AFAIK, AfterSTEP only runs on Linux...  That's partly why I chose AfterSTEP as a reference; to serve as a means to say "I'm not a typical Windows user."  (I never said I was running AfterSTEP on Windows.)  I see your point about GTK, however; although KDE 4 maintains GTK compatibility, it's based on QT4.

You see, I work in a Windows world but live in a Linux world, that's why I chose the "window manager" reference.  Since my boss refuses to spend money for Acrobat and PhotoShop, I use GIMP to re-process PDF files that need mark-up from my Windows-based workstation.  That is why I notice these problems on Windows.  Kubuntu, which I use at home, is a little behind the curve with GIMP so I've not seen the 2.6 version for my distro just yet.

To the whole dev team, I do want to urge a return to the 2.4 style interface.  Working cross-platform as much as I do, I need as much uniformity as possible.  Keeping with common keystrokes and near-identical app behaviour is tantamount for as much as I do across systems.  If this is not possible, make the child windows (the toolbox and inspectors) dockable into the main window.  I know this reduces working area but, personally, I hate dragging these windows off of my work area when a simple Alt-Tab would get them out of the way until I need them again.  Of course, in a dual head configuration, the 2.4 interface was great.  Toolbox and all the other inspectors on the left; work area on the right.

Just something for the team to consider.  Thanks!

If you just want to get the toolbox and inspectors out of the way, you can press Tab in the image window. This will hide them until the next time you press Tab.

> I never said I was running AfterSTEP on Windows

Sorry, I misunderstood. And there is some shell replacement with a similar name for Windows, I thought you were referring to that.

> I do want to urge a return to the 2.4 style interface

I am fairly sure that is not going to happen.

> Working cross-platform as much as I do, I need as much uniformity as possible

That is certainly the intent. Many of the differences in behaviour between GIMP on X11 with the "reference" window manager (metacity) and on Windows are simply caused by bugs (or features not implemented) in GTK+'s Windows backend. Some of them have been fixed only recently and not necessarily yet included in the installers. Other problems remain, one known problem areas is for instance full-screen behaviour. 

You are free to continue to use GIMP 2.4. Now please keep this discussion out if this bug report. It does not belong here and makes it hard to work on the bug that this report deals with.

*** Bug 570299 has been marked as a duplicate of this bug. ***

What's the hold up on this? It's a pretty big problem if the utility window is set by default.

The purpose of the 'utility window' setting is void at the moment. It behaves the same as 'Keep on top' in both Metacity and Windows.

Even returning the default setting to 'normal window' would be helpful to the people who aren't as computer savvy.

The hold up is that you didn't provide a patch.

The same can be said about you, and I'm not a 'GIMP developer'.

I was only asking. In no way was it intended as a demand.

Still, there is a general feeling that The GIMP's interface is given extremely low priority. This bug has been around for ages, even if this bug report is ~4 months old.

I'm not telling you off, I'm genuinely interested. I can't find a single place where the ideas for the GIMP can be found. There seems to be no official forum, visited even occasionally by someone higher up in the development team.

The gimp website links to a few things, like the UI blog, which is useless because it's all user ideas. There are no comments. Nobody knows what you're doing or what you think of user submissions.

You have no obligation to explain anything, but it would be greatly appreciated by everyone who has vested an interest in this application.

http://gui.gimp.org - see the specifications there.

But that's not what should be discussed in this bug report. You are as much a GIMP developer than anyone else - you got access to the source code, you can check what GIMP does to the windows, and you can try to fix this.

(In reply to comment #34)
> http://gui.gimp.org - see the specifications there.
> 
> But that's not what should be discussed in this bug report. You are as much a
> GIMP developer than anyone else - you got access to the source code, you can
> check what GIMP does to the windows, and you can try to fix this.
> 

Thanks for that. I'll check it out. I never noticed that the category headers were links themselves.

*** Bug 566196 has been marked as a duplicate of this bug. ***

While I don't mean to sound egotistical could someone please fix this bug. It is a real bother by it self and to have my desktop cluttered when I am running a dozen or so applications is a confound irritation.  One would think that as this bug has been around for over 2 years something would been have fix.  Also its embarrassing to have the de facto open source standard for image edit have a very obvious every time anyone uses it.  It gives the impressing to outsiders that the open source community has no concept whatever of multitasking and therefore is, not to put to fine a point on it, antiquated.

P.S. I'm not trying to criticize any of the developers here (you guys are doing a great job).  I'm just trying to be constructive.  Of all the bugs GIMP has this one happens to all users every time they run GIMP and so should be fixed.

b8bv2uhu, as this bug report has a long history and by now has gathere comments talking about lots of different environments (even Windows in some comments, although presumably that was a misunderstanding), you need to specify what exactly you mean with "this bug". For instance tell us what your desktop environment is *exactly*.

Sorry for not being explicit.  The bug is the dialogs ("Toobar", "Layers, Cannels etc..." and probably others) remain open once GIMP is minimized.  The OS is Windows Vista (yes I know that is a bad word around here however, you can't expect 85% of computer users to magically go open source.  The transition has to be gentle which is where programs like GIMP come in.  I myself use a few different OSs but most of my graphics work is on Windows because more programs are compatible with it.)

Here is a link to an image of the problem:

https://docs.google.com/leaf?id=0B0qOqWzppgqYY2YyOGNlMWYtMTg1Zi00MzgyLTk2N2QtNWQyZDZjOWNmNTBm&hl=en

b8bv2uhu, you don't understand. My point was not whether using Windows is good or bad as such, but simply that *this* bug report is, as far as I can see, about issues on *X11* (if you don't know what that means, just read it as "Linux"). That something superficially similar seems to happen also on Windows doesn't mean it should be discussed in the same bug report. The underlying mechanisms are quite different, it is quite unlikely that the Windows problem would have the same root cause. Thus bringing up a Windows problem here is counter-productive. Open a *separate* bug report for that. Thanks.

Sorry to have taken up your time.  As the bottom of this page lists "OS: All" I natural assumed this was the right place to report this bug.

Let's change it to Linux then.

*** Bug 627045 has been marked as a duplicate of this bug. ***

This seems to actually be a bug #586664 in gtk+. It incorrectly interprets IconicState to mean the window is iconified. Both otaylor and mclasen seem to be in favor of the change, but nothing has happened in a while.

2.6 -> 2.8

The Gtk+ bug mentioned in comment #44 was recently closed with Gtk+ 2.24.

Here (Arch Linux, Gtk+ 2.24, Openbox 3.5, latest gimp git), the minimize behavior is exactly as I would expect (like comment 3 describes).

This might be resolved at this point.

Marking this resolved since I committed the fix for the bug in gtk+. There's not a release of gtk+ out yet that has the fix though.

*** Bug 677410 has been marked as a duplicate of this bug. ***