On Thu, 7 May 2020 14:28:17 +0200 Mildred Ki'Lya <mildred...@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 - ras...@rasterman.com _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel