GNOME Bugzilla – Bug 686935
Dragging the toolbar down should leave full screen
Last modified: 2016-03-31 13:57:18 UTC
Dragging the toolbar down when the window is maximized unmaximizes. I expected the same thing to happen in fullscreen mode, but it didn't have any effect. One alternative would be to make the fullscreen toolbar look different from the normal one: something that is overlaid and semi-transparent probably wouldn't have this problem.
The fullscreen toolbar _is_ supposed to be styled in the similar way to the overlay toolbar (which Boxes is lacking too). https://raw.github.com/gnome-design-team/gnome-mockups/master/boxes/boxes-fullscreen.png
This affects both the overlay in a VM display and the toolbar in the collection view. Right now if you start boxes in fullscreen (-f) there is no way to get out of it other than starting a VM and unfullscreening from there.
Created attachment 236912 [details] [review] Allow drag to unfullscreen
Review of attachment 236912 [details] [review]: ::: src/display-page.vala @@ +63,3 @@ + private uint button_down_button; + + public override bool button_press_event (Gdk.EventButton ev) { More descriptive names please: ev -> event @@ +66,3 @@ + var res = base.button_press_event (ev); + + Gdk.Event *eev = (Gdk.Event *)(&ev); Why do we need pointer? We are not modifying the event struct even. @@ +87,3 @@ + double dy = ev.y - button_down_y; + + if (dx * dx + dy * dy > 40 * 40) { whats this calculating? @@ +91,3 @@ + App.app.fullscreen = false; + + var window = get_toplevel () as Gtk.Window?; Don't think we need the '?' here. Looks slightly odd. @@ +92,3 @@ + + var window = get_toplevel () as Gtk.Window?; + int old_w; old_w -> old_width @@ +97,3 @@ + ulong id = 0; + id = App.app.notify["fullscreen"].connect ( () => { + int root_x, root_y, w; w -> width
Review of attachment 236912 [details] [review]: ::: src/display-page.vala @@ +66,3 @@ + var res = base.button_press_event (ev); + + Gdk.Event *eev = (Gdk.Event *)(&ev); This is due to problems with the current bindings of GdkEvent in vala. There is no other way to upcast from Gdk.EventButton to GdkEvent which is what we need to get at GdkEvent.triggers_context_menu. I'm chatting with the vala people about redoing the GdkEvent binding, but this is it for now. @@ +87,3 @@ + double dy = ev.y - button_down_y; + + if (dx * dx + dy * dy > 40 * 40) { Its the normal euclidian distance calculation. @@ +91,3 @@ + App.app.fullscreen = false; + + var window = get_toplevel () as Gtk.Window?; I guess not.
Created attachment 237021 [details] [review] Allow drag to unfullscreen
I added comments to the upcast workaround, but if ever a better mapping for GdkEvent lands we need to drop that as it will stop working. Juerg *may* land it this cycle, but maybe not. I've asked him to keep us in the loop on the decision.
This is a tricky one. During size_allocate() on the spice widget the GtkDrawingArea sends a configure event, which is caught by spice-widget.c:configure_event(). This then tries to get a mouse grab via try_mouse_grab(). If this succeeds we'll send a SPICE_DISPLAY_MOUSE_GRAB signal which eventually will reach the boxes code that adds the label about unbreaking. The label change causes a queue_resize on the label widgets and up the widget tree to the toplevel, but this is ignored/overridden by gtk+ since you're not allowed to request size changes during size allocation (that leads to loops). So, the labels are not correctly relayouted.
eh, wrong bug. should be bug 692465
Review of attachment 236912 [details] [review]: ::: src/display-page.vala @@ +87,3 @@ + double dy = ev.y - button_down_y; + + if (dx * dx + dy * dy > 40 * 40) { Forgive me, I've started to forget my school education. :(
Review of attachment 237021 [details] [review]: Look good now, ack
Attachment 236912 [details] pushed as 715d4f1 - Allow drag to unfullscreen Attachment 237021 [details] pushed as 715d4f1 - Allow drag to unfullscreen