Implemented lower window when middle click on titlebar in gtk/mutter

[Carsten Haitzler (The Rasterman)]

On Thu, 7 May 2020 14:28:17 +0200 Mildred Ki'Lya <mildred-ml at mildred.fr> said:

> Le 07/05/2020 à 11:15, Carsten Haitzler (The Rasterman) a écrit :
> >> I suppose that the client can declare the title bar area, and the
> >> compositor can then handle clicks in this area. is there something like
> >> that already existing? Is there anything that has prevented to do this
> >> before?
> > So you want this to only happen when middle-clicking in the titlebar? Then
> > it does require the client to deal with it as only it knows precisely the
> > things in a titlebar that are the titlebar (and not other buttons too like
> > close and what not, and tyring to expose all of this to the compositor to
> > deal with just is endlessly complex).
> That's why I was thinking that there should be a protocol to let clients 
> know where the titlebar area is. Reading past mails, I believe this 
> should allow the titlebar to be non rectangular. I saw that there was an 
> idea of a mask the client sends to the server. Was it rejected for some 
> reason or was it just never implemented?

It's far too complex. People would like to be able to keep compositors really
simple if they can. It also disallows dynamic decisions based on the state and
input at the time. It requires continual updates of this list of rectangles...
when it is possible to do it client side. If it is possible to do client-side,
leave it client-side.

> > So what you need really is clients deal with this. That means every toolkit
> > and/or app will have to follow suit and do it too.
> This is the other solution, but how do all the clients know it's middle 
> click to lower? How do they know it's not middle-click and not 
> double-click? How do they know it's lower and not to minimize or 
> maximize? We can't reasonably ask every wayland client to look at GNOME 
> configuration files (and every other window manager for that matter).

They already don't know what double-click is... or mouse wheel on title etc. -
nothing new. Expect all toolkits/clients to disagree here. On one hand forcing
them to do the same thing limits freedom. E.g. I'd want to make double click
shade the window (next-like roll up into the titlebar) and wheel up.down
shade/unshade. Toolkits are already free to disagree what a mouse wheel does
when scrolled over a scrollable area. They do slightly different things. They
already can disagree on what happens with scrollbars. They can already
disagree with tab/shift tab navigation (e.g. EFL does tab/shift tab but also
down up/down/left/right in addition). This argument always appears. What is one
toolkit wants close button on top-left? Or one desktop insists titlebars are to
be at the bottom of windows? Shall everyone then implement every possible UI/UX
decision a WM/compositor wants?

If I were to tell Gnome and KDE they must now implement shading into the
titlebar on double-click in CSD because I want to do this they will probably
tell me to get lost as it's yet more work to do and it's "not popular". Just as
much as I would say "But double-click shades the window, not maximizes it. It
has done so for me since like 1996/7 or so and still does.". :) Pushing policy
at clients from the compositor is going to end up with push-back and already is
inconsistent in so many other areas so you'll never solve it with some protocol
you might be able to address one specific thing, but then there are still 8439
others you won't solve... :)

> > If you want middle-mouse anywhere to do this (like alt+left mouse drag is
> > seconded anywhere to move a window). then the compositor can do this with
> > clients being ignorant of it happening.
> We can't just steal every middle-click everywhere on the window. It has 
> to be on the title bar.

You can... alt+left click is generally stolen on all windows already as a handy
mov-the-window. A compositor CAN steal whatever events it likes... :) I leave
it up to user config and bindings to decide what it steals or not. :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com