After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 711298 - "Edit Scheduled Transaction" window way too modal
"Edit Scheduled Transaction" window way too modal
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Quartz
3.11.x
Other Mac OS
: Normal major
: ---
Assigned To: John Ralls
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2013-11-02 16:45 UTC by Greg P
Modified: 2014-01-24 23:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Assign dialog and utility-hinted windows to NSNormalWindowLevel (1.14 KB, patch)
2013-12-01 22:30 UTC, John Ralls
committed Details | Review

Description Greg P 2013-11-02 16:45:26 UTC
When using GnuCash 2.5.x (I have not tried recently with prior versions) on Mac OS X, the "Edit Scheduled Transaction" window created when editing a scheduled transaction is unable to be hidden behind any other windows.

This applies whether command-tabbing out of the application, doing an expose gesture to switch to another app, clicking on another app to bring it into focus, etc.

Workaround is to move the window to the bottom of the screen and continue to use other apps, otherwise it's in the way.

I marked this as major as if this goes out as 2.6 it'll be really annoying.  I might even call it a blocker (but didn't want to spam your bug tracker).
Comment 1 John Ralls 2013-11-03 00:18:18 UTC
Don't you mean the "Since Last Run" window? The SX Editor is a special register tab. You can open it as a window if you want, but it isn't modal at all.

The Since Last Run window does exhibit the behavior you describe.
Comment 2 Greg P 2013-11-10 04:15:42 UTC
The actual "Scheduled Transactions" list is a tab in the register section, but if I double-click a transaction that I have scheduled it opens a window, which exhibits the behaviour I indicated.

I can reproduce this in 2.5.7.
Comment 3 John Ralls 2013-11-10 19:31:11 UTC
It appears to be a gtk-quartz bug associated with dialogs created by GtkBuilder. It can be demonstrated in gtk-demo and gtk3-demo in the builder demo with the Help>About dialog.
Comment 4 John Ralls 2013-12-01 22:30:06 UTC
Created attachment 263257 [details] [review]
Assign dialog and utility-hinted windows to NSNormalWindowLevel

This is due to dialogs and utility windows, as determined by GDK_WINDOW_TYPE_HINT_DIALOG and GDK_WINDOW_TYPE_HINT_UTILITY, being assigned to level NSFloatingWindow. The attached patch puts them in the same level as ordinary windows so that Gtk can manage their stacking. Note as well that gdk_window_set_keep_above() and gdk_window_set_keep_below() can promote or demote a GdkWindow to the next  higher or lower NSWindow level than dictated by its GdkWindowTypeHint.

We probably shouldn't be using NSWindow Levels at all, but if we must we should call setHidesOnDeactivate:True on every GdkWindow that is promoted out of NSNormalWindow so that it doesn't interfere with the user's other applications.
Comment 5 John Ralls 2014-01-24 23:24:35 UTC
Comment on attachment 263257 [details] [review]
Assign dialog and utility-hinted windows to NSNormalWindowLevel

Pushed to master, gtk-3-10, and gtk-2-24.