[PATCH 0/2] xdg-shell: Proposal to be more generic for decorations

[Adam Goode]

On Fri, Dec 9, 2016 at 6:10 PM, Dima Ryazanov <dima at gmail.com> wrote:

> Overall, I like the idea - it seems to solve the issues with raise/lower,
> etc.
>
> I wonder, though, if removing the explicit move/resize/etc. requests makes
> it too restrictive. Suppose that, for whatever reason, the client wants to
> trigger a move or a resize using the right or middle button. Maybe it's a
> weirdly-shaped surface (like weston-flower) where all of it is draggable,
> or some other strange case. As far as I can tell, it's possible in v6, but
> not v7.
>
>
If all of it is draggable, then it seems like the entire surface is a
custom-shaped titlebar? It's a bit of a stretch. I played with
weston-flower and looked at the code. I see what you mean, it is a bit of a
custom thing.

Maybe we don't want to call this "titlebar" in the protocol. I don't know
what else to call it though.


> Another, more real use case: nautilus has a bunch of buttons in the
> titlebar. If you click them, they work as usual - but dragging a button
> triggers a shell move. That means, at the time the client receives a mouse
> down event, it doesn't know yet what it should do. Once it gets a mouse
> move, it sends a shell move request. Would that still be possible in v7?
>
>
Ah, I was wondering about some of the details of the in-titlebar widgets in
GNOME. I tried it out in Nautlus, and dragging on the buttons does indeed
turn into move requests, in most cases. (The folder widget in Nautilus
seems to not do this.) As another aside, the behavior does seem a bit
surprising to me, since I am used to dragging away from a clicked button to
cancel the click. (There are some inconsistencies there between GNOME
Terminal and Nautilus.)

Anyway, if the client decides that a mouse down event was actually on the
titlebar (because the mouse moved or whatever), then it can tell the
compositor that the original mouse down event was a titlebar interaction
and give that original seat and serial to the compositor. Then the
compositor can implement its policy as before.

This is pretty much the "gui event chaining
<https://www.google.com/search?q=gui+event+chaining>" model (called
different things in different systems). If you don't know how to handle a
particular event, you call out to the next handler. In this case, it's the
client calling out to the compositor to handle a click on the titlebar
where there isn't a client widget.


Adam




> On Fri, Dec 9, 2016 at 2:20 PM, Adam Goode <agoode at google.com> wrote:
>
>> Hi,
>>
>> There were many different opinions and suggestions for how to allow
>> for raise and lower to be bound to mouse clicks in titlebars. This
>> is one possible way forward. It removes some of the semantic requests
>> in xdg-shell and replaces it with a "interact_with_decoration"
>> request that lets more window management logic move into the compositor.
>>
>> Comments welcome. I know this is a tricky issue, but I hope this
>> is leading somewhat in the right direction.
>>
>>
>> Adam
>>
>>
>>
>> Adam Goode (2):
>>   xdg-shell: Introduce protocol v7
>>   xdg-shell: Fold several client-side decoration requests into a generic
>>     request
>>
>>  COPYING                                      |    1 +
>>  unstable/xdg-shell/xdg-shell-unstable-v7.xml | 1012
>> ++++++++++++++++++++++++++
>>  2 files changed, 1013 insertions(+)
>>  create mode 100644 unstable/xdg-shell/xdg-shell-unstable-v7.xml
>>
>> --
>> 2.8.0.rc3.226.g39d4020
>>
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20161211/23f8c97c/attachment.html>