Re: Implemented lower window when middle click on titlebar in gtk/mutter
On Thu, 7 May 2020 14:28:17 +0200 Mildred Ki'Lya 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
Re: Implemented lower window when middle click on titlebar in gtk/mutter
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? 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). 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. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Implemented lower window when middle click on titlebar in gtk/mutter
On Mon, 4 May 2020 12:08:46 +0200 Mildred Ki'Lya said: > Hi, > > For a long time I delayed using Wayland on my computer for about three > reasons: inability to restart the gnome-shell (Alt-F2, r), slowness in > gnome-shell, and inability to lower client-side decorated windows on > middle click like on X11. The performance getting better and better (and > with the realtime option enabled in mutter) I decided to scratch my itch > and implement lowering in waylang for Gtk client-side decorations. > > My work is implemented as an upgrade to the gtk-shell protocol: > > - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1221 > > - https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1821 > > It works, but I do not like how it works and the fact that it's Gtk > specific (although other toolkits could implement the gtk protocol). > Also, I don't like that it's the client that should look up the window > manager configuration to know that middle clicking means lowering the > window. It's up to the compositor to map the middle click to lower and > not the client. > > So I'm asking it here, what would be the wayland solution for a > cross-toolkit and cross-environment solution? > > 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). 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. 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. > Thank you, > > Mildred > > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- - 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
Re: Implemented lower window when middle click on titlebar in gtk/mutter
On Wed, May 06, 2020 at 06:49:05PM +0100, David Edmundson wrote: > For non-Gnome people, what does "lower" mean in this context? Send into background, move behind other windows; the opposite of "raise". Marius Gedminas -- Q: Is the Zombie Apocalypse a likely occurrence? A: It happens every morning when people drag their ass out of bed to go to work. We seem to survive it. -- http://whatever.scalzi.com/2009/04/05 signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Implemented lower window when middle click on titlebar in gtk/mutter
For non-Gnome people, what does "lower" mean in this context? David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Implemented lower window when middle click on titlebar in gtk/mutter
Hi, For a long time I delayed using Wayland on my computer for about three reasons: inability to restart the gnome-shell (Alt-F2, r), slowness in gnome-shell, and inability to lower client-side decorated windows on middle click like on X11. The performance getting better and better (and with the realtime option enabled in mutter) I decided to scratch my itch and implement lowering in waylang for Gtk client-side decorations. My work is implemented as an upgrade to the gtk-shell protocol: - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1221 - https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1821 It works, but I do not like how it works and the fact that it's Gtk specific (although other toolkits could implement the gtk protocol). Also, I don't like that it's the client that should look up the window manager configuration to know that middle clicking means lowering the window. It's up to the compositor to map the middle click to lower and not the client. So I'm asking it here, what would be the wayland solution for a cross-toolkit and cross-environment solution? 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? Thank you, Mildred ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
