GNOME Bugzilla – Bug 585091
Utility windows not displayed correctly in GDK-Quartz
Last modified: 2018-04-15 00:22:26 UTC
Please describe the problem: Mac utility windows have smaller titlebars and only a close button; GDK-Quartz displays them as normal windows which are at such a high level that they are placed above their own popup menus. Utility windows should also disappear when the application is inactive; they do not. Steps to reproduce: 1. Open GIMP, for example. 2. Try using the brush selection menu under the Paint tool. 3. Deactivate the application; the utility windows do not disappear. Actual results: Expected results: Does this happen every time? Other information:
Created attachment 136110 [details] [review] Slightly hackish patch Lowers the level of utility windows so they are not displayed above submenus and makes them hide on deactivation of the application. I'm still working on getting them to display as NSPanels, not NSWindows.
Move to right components so the right people see it.
(In reply to comment #0) > Please describe the problem: > Mac utility windows have smaller titlebars and only a close button; GDK-Quartz > displays them as normal windows which are at such a high level that they are I don't think I fully understand this. Yes, they are displayed as normal windows, but with the window level set to floating. When I set some other window to this type hint, popup menus just display as usual. How will changing the window level from float to normal help things? Did you mean to say that because they are floating windows they are above their own popup menus? > placed above their own popup menus. Utility windows should also disappear when > the application is inactive; they do not. This seems reasonable. (In reply to comment #1) > and makes them hide on deactivation of the application. I'm still working on > getting them to display as NSPanels, not NSWindows. This is tricky. It has to be handled in _gdk_window_impl_new(). At that point the window type hint has to be set (the documentation requires this). Based on the type hint value, we need to create a NSPanel instead of a NSWindow here. The problem is that GdkQuartzWindow inherits NSWindow, not NSPanel. We could make GdkQuartzWindow a decorator that takes any NSWindow subclass, but I wonder if that will work out with the delegates. Need to think about this.
Exactly - that's why I was never able to come up with a real fix.
Small status update. I did a bunch of refactoring and ended up with a GdkQuartzWindow and GdkQuartzPanel with the common code factored out in a separate GdkQuartzWindowDelegate class. When creating a GtkWindow with a utility type hint, widgets show up in a NSPanel just fine. However, there's a bunch of event handling issues that I need to debug before this is ready to be pushed to the git master branch. I am very close now though ;)
Created attachment 150733 [details] [review] Patch as of December 29, 2009 (commits merged into one patch) Here's the patch so far. This patch contains all commits from my local "window-delegate" branch. When this goes to the master branch, I will push the separate commits instead. The event handling issues from the previous comment have been settled. These issues were not fully specific to NSPanels. The GIMP utility windows seem to work just fine with this patch. I have yet to test this patch on Tiger.
Created attachment 218853 [details] tarball containing separate commits Attached is a tarball containing the separate commits like mentioned in the previous commit, if anyone wants to pick up work on this. I will likely never get to it again.
Kristian - so this set of patches basically works and just needs testing?
It worked with GIMP on Snow Leopard (perhaps with some small issues), but the code was never tested on Tiger. It might be that mitch has tested the code as well on Lion, but I am not sure about that.
Created attachment 226975 [details] [review] This patch applies to gtk-2-24 of October 2012 Here's an updated patch against current gtk-2-24. It's one large patch because I forgot I used to have a branch with the broken down patches, I don't think that matters that much. It comes with the following notes: - Compared to the old patch I changed GtkQuartzWindowDelegate to be an NSObject subclass instead of a NSWindow subclass. From what I understand it doesn't make sense for the delegate to be a NSWindow subclass and this makes the code less confusing too. - For some reason the compiler is warning "[NSApp contextID]" is not defined, NSCountWindowsForContext() is marked as "can be deprecated at any time". The contextID method still appears to work though. - It hasn't been tested on Tiger. Mitch: The weird stuff we saw Saturday night (the window in GIMP not receiving events) seems to have been fixed. I don't remember what change exactly fixed it, but it works for me now.
> - For some reason the compiler is warning "[NSApp contextID]" is not defined, > NSCountWindowsForContext() is marked as "can be deprecated at any time". The > contextID method still appears to work though. I guess I forgot it is private API, but many people are using it.
Kris, I believe this patch should be applied (when I finally tested it), but look at bug 688710. That one solves at least the hiding issue perfectly for all sorts of window types that should be hidden.
*** Bug 683618 has been marked as a duplicate of this bug. ***
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new