Created attachment 252186 [details] [review]
Patch

OK, but what's the use-case?

IOW, how are you enabling full screen through Quartz rather than with gtk_window_fullscreen(), which already sets GDK_WINDOW_STATE_FULLSCREEN? How does that have general applicability?

I'm not - /yet/.

What I want to do is to add support for Lion+ fullscreening via [NSWindow setCollectionBehavior: NSWindowCollectionBehaviorFullScreenPrimary], which will cause Quartz to show the system-standard fullscreening widget in the top right corner of the window. But exactly how and where that support should be added isn't clear yet - whether it should be in core gtk+ somewhere, or added to gtk-mac-integration, or whatever. I need to talk to the developers (mostly you, I guess?) about how to approach it.

Assuming that it goes *somewhere*, responding to these messages needs to go here, and they don't break anything on its own, so I figured I'd submit them first and make sure I'm getting all the patch-submissions-process stuff right before I tackle the part that touches public APIs.

OK, but there's a bit more involved than just setting the window state flag. Probably the right thing to do is to call gdk_quartz_window_(un)fullscreen.

ISTM calling setCollectionBehavior: should be something that applications can decide to do or not do on a per-window basis, just like adding a Fullwindow toggle to the View menu. I'd rather not put anything more into gtk-mac-integration if we can find a way to add the API to Gtk itself, though we can't add API until after Matthias branches 3.10. I guess the place to put it would be a function exposed in gdkwindow-quartz.h, but we can't add API until after Mattias branches 3.10.

Kristian, Mitch, Paul, any thoughts?

> Probably the right thing to do is to call gdk_quartz_window_(un)fullscreen.

Well, I'm not sure; that function messes with window geometry and decorations and stuff, but Quartz's native fullscreening is already doing all of that automatically, right? So it seems like a lot of what that function is doing is at best redundant and at worst may cause conflicts. Might be necessary to split it up into window-frame-related bits (which Quartz is doing for us) and window-client-area-related bits (which I suspect it isn't).

> ISTM calling setCollectionBehavior: should be something that applications can decide to do or not do on a per-window basis, just like adding a Fullwindow toggle to the View menu.

Yes, agreed. And ideally, support - or leave a path open - for NSWindowCollectionBehaviorFullScreenAuxiliary for toolwindows and stuff, too.

> I'd rather not put anything more into gtk-mac-integration if we can find a way to add the API to Gtk itself

Fair enough. Is anyone aware of other supported platforms that have this kind of WM-provided fullscreening behaviour at the moment?

(In reply to comment #5)
> > Probably the right thing to do is to call gdk_quartz_window_(un)fullscreen.
> 
> Well, I'm not sure; that function messes with window geometry and decorations
> and stuff, but Quartz's native fullscreening is already doing all of that
> automatically, right? So it seems like a lot of what that function is doing is
> at best redundant and at worst may cause conflicts. Might be necessary to split
> it up into window-frame-related bits (which Quartz is doing for us) and
> window-client-area-related bits (which I suspect it isn't).
> 

Looking at it a bit more along with the history, I'm leaning towards the reverse, actually. gdk_quartz_window_(un)fullscreen should be testing for the nswindow responding to toggleFullScreen: and using it *instead* of all of the resizing stuff, which is a mix of Cocoa and Carbon and should work on any supported version of OSX. That seems to work in the testfullscreen program as long as setCollectionBehavior:NSWindowCollectionBehaviorFullScreenPrimary has already been called on the nswindow.

I need to experiment some more on that.

> > ISTM calling setCollectionBehavior: should be something that applications
> > can decide to do or not do on a per-window basis, just like adding a 
> > Fullwindow toggle to the View menu.
> 
> Yes, agreed. And ideally, support - or leave a path open - for
> NSWindowCollectionBehaviorFullScreenAuxiliary for toolwindows and stuff, too.

Indeed, that's another problem that's going to take some experimentation to get right. Most Gtk apps are multi-windowed as far as Cocoa is concerned -- dialog boxes are windows, not sheets -- and if I understand the NSWindow documentation correctly either they won't be displayed if one of the windows is fullscreened or maybe worse, they'll kick it out of full screen unless they're set to FullScreenAuxiliary. Neither would be acceptable.

So, this went in today:
https://git.gnome.org/browse/gtk+/commit/?id=ec17a649aed65fb0a27d6cf10ab097a5f310dfc6

gdkwindow-quartz: Support native fullscreen mode
This implements native fullscreen mode on OS X >= 10.7. This patch
adds tracking of the fullscreen mode if externally modified, as well
as toggling the native fullscreen mode of the window as needed.

It would be nice to give it a look. It works well for the case of gedit, but I haven't tested all the cases. For gedit we now set FullScreenPrimary on the main window. Dialogs (like preferences) correctly stay on top if you go in/out of fullscreen.

assuming that this was good enough, then