Created attachment 203660 [details] [review]
panel: Allow to start a drag to restore a window from the panel

The preferred way to unmaximize/untile a window is by using a drag
gesture. Extend the available area to start this gesture into
non-reactive parts of the top bar above the window - with that we
take advantage of the "infinite height" of the screen edge, and the
extra space is particularly useful when the window has its titlebar
hidden.

Just a small commment: why passing 0 for the modifier mask?
clutter_event_get_state() should give you the mask for a button-press-event, if you remove mouse buttons (or ignore them in mutter)
(at least, I checked the XI2 case and it is indeed set)

Review of attachment 203660 [details] [review]:

Generally looks good if you have approval from the designers (they don't want it just for hidden-titlebar windows?)

::: js/ui/panel.js
@@ +1043,3 @@
+
+        let dragWindow = focusWindow.is_attached_dialog() ? focusWindow.get_transient_for()
+                                                          : focusWindow;

You need to walk up until you find a non-attached dialog which might be a grandparent, etc

@@ +1051,3 @@
+
+        let allowDrag = dragWindow.maximized_vertically &&
+                        stageX > rect.x && stageX < rect.x + rect.width;

Probably >= for consistency with general "contained in rectangle", though matters not much

@@ +1062,3 @@
+                                     true, /* frame action */
+                                     event.get_button(),
+                                     0, /* modifier mask; we'd need to connect

As giovanni said, the modifier mask is in button events - Shell.get_event_state(event);

(In reply to comment #3)
> As giovanni said, the modifier mask is in button events -
> Shell.get_event_state(event);

Right, though thinking about it, I'd only use it to assure that no modifier is present (e.g. only extend the "normal" left-click-no-modifiers to the top bar - having different actions for mod+click on the titlebar and top bar feels confusing).

Anyway, I haven't heard anything from the designers yet, so not updating the patch for now.

Without actually playing with it, I like this. On one hand toolbarless maximized apps sound like quite an exception, but web apps work really well like that (through Epiphany appification). 

I haven't managed to apply this on master, but I think this approach would be better than what I initially had in mind -- using the app menu. I don't think we should specialcase only the toolbarless windows with this. If all windows behave like this, we lower the element of surprise.

(In reply to comment #5)
> I don't think we should specialcase only the toolbarless windows with this. 
> If all windows behave like this, we lower the element of surprise.

Currently we don't special-case at all, i.e. we allow the behavior for all maximized/tiled windows (regardless whether they have or don't have a toolbar/titlebar/whatever)

Created attachment 208574 [details] [review]
panel: Allow to start a drag to restore a window from the panel

Limit behavior to right-clicks + pass on modifier state.

Review of attachment 208574 [details] [review]:

I like this. The code looks right except for one doubt:

::: js/ui/panel.js
@@ +1063,3 @@
+    _onButtonPress: function(actor, event) {
+        if (!Meta.prefs_get_edge_tiling())
+            return false;

I don't think this condition is needed. Don't we want this to work for regular maximized windows even if tiling is disabled?

Created attachment 208617 [details] [review]
panel: Allow to start a drag to restore a window from the panel

Right, there's no good reason to not apply the same behavior to the "shaking-loose" behavior ...

Review of attachment 208617 [details] [review]:

Looks fine to me.

Attachment 208617 [details] pushed as f4b58f3 - panel: Allow to start a drag to restore a window from the panel

Nice!!!