Created attachment 264102 [details]
screenshot

Created attachment 264103 [details] [review]
GtkWindow: disable csd on Quartz for now

Client side decorations are not working properly on quartz, so disable
them until someone who knows what they are doing can fix them.

Note: the active app in the screenshot is finder, not because gtk-demo is incapable of becoming focused, but because I had clicked on the desktop just before taking the screenshot...

Some notes:

I was able to get resize working again with this:

   if (decorations == 0 || GDK_WINDOW_TYPE (window) == GDK_WINDOW_TEMP ||
       impl->type_hint == GDK_WINDOW_TYPE_HINT_SPLASHSCREEN )
     {
-      new_mask = NSBorderlessWindowMask;
+      new_mask = NSBorderlessWindowMask | NSResizableWindowMask;
     }
   else
     {
       /* FIXME: Honor other GDK_DECOR_* flags. */
       new_mask = (NSTitledWindowMask | NSClosableWindowMask |
                     NSMiniaturizableWindowMask | NSResizableWindowMask);
     }

but note that this is a bit misleading because apparently NSBorderlessWindowMask is 0 (ie: it's the 'None' case of the flags.  It seems that 'TitledWindowMask' is the way to get a titlebar shown or not.


Meanwhile, not so much luck with moves.  I can see that beginManualMove() is called and sets inManualMove to YES.  After that we see two calls to sendEvent():

 - NSLeftMouseDown (1)
 - NSMouseEntered (8)

followed by nothing else.  inManualMove is never unset.

After that, no additional attempt to manually move the window is successful.

More notes: when I apply the patch above I get a titlebar, but the headerbar is still there.

First issue: the header bar has a close button in it.  We should probably take that out in the case that CSD is not supported.

Secondly: if I try to drag on the headerbar that doesn't work (ie: app-initiated window movement is clearly not dependent on the decorations being there or not -- it never works).  The weird thing about this is that after I try to drag by the headerbar (and see that fail), trying to drag by the normal titlebar will reposition the window so that the mouse cursor is over the position that I tried to drag from on the headerbar.

ie: although the headerbar drag does not succeed, clicking on the OS-provided titlebar seems to 'resume' the drag I attempted to start on the headerbar.

setMovableByWindowBackground on the GtkQuartzNSWindow and removing all of the sendEvent machinery makes everything work very nicely (and much more smoothly than our code ever did), but unfortunately "window background" seems to be the entire app and it's not possible to interact with anything at all anymore...

Created attachment 264108 [details] [review]
quartz: fix manual window move

We need to have gdk skip standard processing of events when we are in
manual move in addition to manual resize.

This seems to fix the move issue, but there are additional problems.  Resizing is extremely jerky and unreliable (which is why I thought it didn't work before) and occasionally produces a result where the display server's idea of the window size is larger than Gtk's idea (resulting in the bottom few pixels of the window not being painted).  Additionally, gtk seems to count the width of the client-side shadows when ensuring that the window cannot be dragged under the menubar resulting in the window having to stay the width of the shadow away from the menubar.

Review of attachment 264108 [details] [review]:

::: gdk/quartz/GdkQuartzNSWindow.c
@@ +365,3 @@
 -(BOOL)isInManualResize
 {
+  return inManualResize || inManualMove;

Makes the function name somewhat misleading. Maybe rename it to match ?

Created attachment 265468 [details] [review]
quartz: fix manual window move

We need to have gdk skip standard processing of events when we are in
manual move in addition to manual resize.

Attachment 265468 [details] pushed as 394fe4b - quartz: fix manual window move