Created attachment 217893 [details] [review]
window: Also use hide-titlebar-when-maximized when tiled

Side-by-side tiling is conceptually very close to maximization
("half-maximized"), so it makes sense to also hide the titlebar
in this state if requested by the application.

Review of attachment 217893 [details] [review]:

Looks fine. If designers agree it's ACN from me. See also the following patch.

Created attachment 217918 [details] [review]
panel: Allow dragging an unfocused tiled match window

Since we allow dragging tiled windows from the panel, it seems natural
that we also allow it for the matching unfocused tiled window if it
exists, especially since tiled windows might now have their titlebar
hidden.

Comment on attachment 217893 [details] [review]
window: Also use hide-titlebar-when-maximized when tiled

Attachment 217893 [details] pushed as 0a50488 - window: Also use hide-titlebar-when-maximized when tiled

I'll assume "filed by a designer" == "designers are OK with it" ;-)

Review of attachment 217918 [details] [review]:

I'm not sure this behavior makes sense to me, but let's get design input on this. Allowing to drag a window from the panel that does not match the app menu may or may not be a problem, personally I tend to like it. However, using the matched window seems confusing to me - basically we end up with "sometimes you can drag an unfocused tiled window, sometimes you can't". So if we extend the behavior to non-focus windows, we should allow it for all unfocused tiled/maximized windows in my opinion (e.g. pick window at (pointerX, panelY + panelHeight + 1) and check if it's either tiled or maximized), not based on an implementation detail of the window shadow policy.

(In reply to comment #5)
> However, using the
> matched window seems confusing to me - basically we end up with "sometimes you
> can drag an unfocused tiled window, sometimes you can't". So if we extend the
> behavior to non-focus windows, we should allow it for all unfocused
> tiled/maximized windows in my opinion (e.g. pick window at (pointerX, panelY +
> panelHeight + 1) and check if it's either tiled or maximized), not based on an
> implementation detail of the window shadow policy.

I think it only makes sense for "foreground" unfocused tiled windows as implemented here because, just as with maximized windows, there's no ambiguity as to which window the gesture will apply.

I don't see that. If I have two windows, why is the case where the focus window is tiled less ambiguous than the case where it is not?

(In reply to comment #7)
> I don't see that. If I have two windows, why is the case where the focus window
> is tiled less ambiguous than the case where it is not?

Because then it's likely that both tiled windows are exposed enough that you can visually see their tops contiguous to the panel.

It's not perfect because you can do something like having a 3rd window of the same size and in the same place, stacked on top of the unfocused match tiled window but not tiled itself and this code would still allow you to drag the match tiled window underneath. This seems like a very unlikely scenario in practice though?

(In reply to comment #8)
> (In reply to comment #7)
> > I don't see that. If I have two windows, why is the case where the focus window
> > is tiled less ambiguous than the case where it is not?
> 
> Because then it's likely that both tiled windows are exposed enough that you
> can visually see their tops contiguous to the panel.

That would only make sense to me if we treated the windows as a unit, e.g. start a drag for both windows. Also, we don't care about contiguous tops for the focus window, so why does it become important for non focus windows?

(In reply to comment #9)
> That would only make sense to me if we treated the windows as a unit, e.g.
> start a drag for both windows. Also, we don't care about contiguous tops for
> the focus window, so why does it become important for non focus windows?

Not contiguous between each other but between each one of them and the panel. Anyway, too much yak shaving already for such a little detail. There's more important stuff to do.

(In reply to comment #5)
> Review of attachment 217918 [details] [review]:
> 
> I'm not sure this behavior makes sense to me, but let's get design input on
> this. Allowing to drag a window from the panel that does not match the app menu
> may or may not be a problem, personally I tend to like it. However, using the
> matched window seems confusing to me - basically we end up with "sometimes you
> can drag an unfocused tiled window, sometimes you can't". So if we extend the
> behavior to non-focus windows, we should allow it for all unfocused
> tiled/maximized windows in my opinion (e.g. pick window at (pointerX, panelY +
> panelHeight + 1) and check if it's either tiled or maximized), not based on an
> implementation detail of the window shadow policy.

Trying out Rui's patch, it took me a while to find a case where it didn't allow the drag (a maximized window with a tiled window on top of half of it), and when it didn't work, it was just puzzling. I suspect that the current restriction of the drag-off to the focused window is wrong - if the user learns the drag-off behavior, they aren't paying attention to what window is focused and the app menu, they rather are paying attention to the juncture of the maximized/tiled window with the panel.

Review of attachment 217918 [details] [review]:

Marking need-work for now pending designer input. Jon?

I'd test the patch, I happen to try unmaxing (with topbar grab) an unfocused window (whole window not a tile) and the current behaviour makes it seems broken (trapped feeling), I think with tiles it will seems even more broken, I was actually thinking it was a bug so Owen reasoning is right to me.

Seems this never got any designer input, and we still don't initiate a window-move when dragging from the panel over a non-focused tile. Adding the 'usability' keyword to see if that helps with getting UX feedback.

Actually there was some designer input Jonas :-)

I was referring to comment 12. Since then, was there any input given elsewhere?