GNOME Bugzilla – Bug 169965
transient dialogs with minimized parent
Last modified: 2018-02-10 04:36:21 UTC
Please describe the problem: the picture windows still present when you reduce it and you want to close it without having save before Steps to reproduce: 1. create a new picture 2. do some modification in this one 3. reduce the picture 4. right clic on it/close Actual results: the picture is still ther, we can't acces to it and the unique way to close it is to close all the application Expected results: Does this happen every time? yes Other information: I think it is the " do you wan't to save picture" mesage wich make the problem
Just guessing here (as I don't use Windows), but it looks like what happens is that the confirmation dialog is attached to the image window. Windows allows you to restore/maximize/close windows that are minimized. Problems seem to occur when the confirmation dialog tries to pop up with its parent set to a minimized window. If this is the case (maybe some other Windows user could confirm this), then it may be possible to implement a workaround by not attaching the confirmation dialog to the image window if that window is not currently mapped.
I can confirm this. It is still possible to restore the image, though - just use Restore from the context menu of the task bar entry - but the close dialog remains hidden. "Microsoft Windows - How do you want to be disappointed today?"
This is a duplicate of bug #166012, isn't it? And actually I think we should reassign this problem to GTK+ and deal with it at the toolkit level.
In order to deal with this problem further, we need to know the version of GTK+ this problem shows up with.
marking as NEEDINFO in accordance with comment #4.
GTK+ 2.6.4
I am reassigning this report to GTK+ now since I would like to get some advice whether this should be handled on the toolkit level or if GIMP needs to workaround this problem. Here's a short summary of the problem: - user minimizes image window - user closes the minimized image window using win32 taskbar functionality - gimp opens a confirmation dialog which is transient to the image window - this dialog doesn't seem to show up at all
I just realized that the very same problem exists on Unix as well. At least with metacity, the confirmation dialog also doesn't show up.
On Windows, it seems to be something that we need to handle in the toolkit. The metacity behavior however sounds like something we might need to fix in metacity ... I dont' think you can fix it in the toolkit without a lot of gymnastics ... the user might minimize the window between the time that the toolkit checks "is this window minimized" and when it actually shows the window. The same race condition exists if we just tell applications that they have to gtk_window_present() the parent of dialogs to make sure they appear on the screen. One initial question is "what is the right user behavior' ... do we want to just show the dialog, or do we want to unminimize the window? (What's the normal behavior on windows?)
*** Bug 305644 has been marked as a duplicate of this bug. ***
*** Bug 383226 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > One initial question is "what is the right user behavior' ... do we want > to just show the dialog, or do we want to unminimize the window? (What's > the normal behavior on windows?) I just had access to a Windows machine and I tried several applications in order to check how they behave: Word, PowerPoint, Excel, Visio, Paint, Eclipse. For these applications, when there are several documents open and they are all minimized, right-clicking in the task bar and selecting "Close" results in a "confirm close" dialog in the middle of the screen while the document is still minimized. These confirmation dialogs never seem to be attached to the document windows. If I open several documents on my screen and put some of them on the right side and some others on the left side, the confirmation dialogs will always appear centered in the middle of the screen. This seems to be the case for all Windows applications that I tried - both from Microsoft (Office 2003) or from third parties such as Firefox or Eclipse. The easiest solution would be to avoid making these confirmation dialogs transient to the image windows, regardless of whether the image windows are mapped or not. At least for Win32 (and maybe even for other platforms). Unless someone can propose a better solution at the GTK+ level, this should probably be re-assigned back to GIMP.
*** Bug 383657 has been marked as a duplicate of this bug. ***
I think bug #164537 may affect this, if I understand this bug correctly.
I think we're also experiencing this bug with Inkscape on Windows. A user reports this to recreate the issue on Windows with Inkscape 0.45: https://bugs.launchpad.net/inkscape/+bug/168301 - open Inkscape and draw a rect - minimize app window - right-click Inkscape window in a taskbar and select Close - Inkscape enters some strange state. Its window can be restored, but it doesn't seem to accept any commands... We suspect this is because Inkscape is asking you whether you want to save changes, but that dialog is buried underneath other windows. Yet that window is modal, i.e. it grabs all Inkscape input, therefore the main Inkscape window is disabled. Fixing the "dialogs don't stay on top of main window" bug may resolve this one. Has anyone had a chance to look into this?
Have you tried GTK+ 2.12.2? (Available from http://ftp.gnome.org/pub/GNOME/binaries/win32/gtk+/2.12/ .) It includes the fix to bug #164537. (Note that you need to upgrade your gettext-runtime to 0.17, available from http://ftp.gnome.org/pub/GNOME/binaries/win32/dependencies/ , if you upgrade to GTK+ 2.12.)
Bryce, I'm aware of the issue you mentioned with right-clicking the taskbar entry. The part about restoring and not accepting any commands is, I believe, fixed. But the part about entering a weird state when you right-click is not, and I created bug #505928 to track it.
Hi Tor, thanks (I don't actually run Windows so can't test, I'm just forwarding bugs from the Inkscape bug tracker upstream). But for the Inkscape windows build we'll plan on including 2.12.2 or newer; we've got a few other problems that get solved with that version. Cody, thanks for pointing at the new bug for the right click state.
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.