hi Alan, thank you for maintaining CC mode :-) it is endlessly useful in my day-to-day.
to preface, I'm not a wayland protocol expert; I've had to debug clients and servers a few times, view communications between clients and servers some others, experimented with some patches, but I haven't written a significant amount of code with it, and am mostly an end user happy to see an end to flickering, window tearing, weird keyboard grabs, ... Alan Mackenzie <a...@muc.de> writes: > Hello, Arsen. > > On Tue, Aug 06, 2024 at 15:56:40 +0200, Arsen Arsenović wrote: >> "J. Aho" <gen...@kotiaho.net> writes: > >> > On 05/08/2024 18.30, Daniel Frey wrote: >> >> Is it just me or is wayland nowhere near primetime? > >> > There are still issues with wayland, not sure how up to date this page is: >> > https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277 > >> it's either out of date or fearmongering. I'd presume the former if not >> for the first emphasised paragraph of the post: "DO NOT USE A WAYLAND >> SESSION! Let Wayland not destroy everything and then have other people >> fix the damage it caused. Or force more Red Hat/Gnome components (glib, >> Portals, Pipewire) on everyone". > >> but, each "point" it makes can individually be debunked also. I'm not >> very interested in doing that beyond oneliners though (which is >> apparently enough for the author of the original post). > > I'm interested in one of the points you address in particular, namely: > > [ .... ] > >> - Wayland breaks setting the window position - yes, intentionally, >> wayland is declarative wrt window positioning (you might notice that >> if you right click, the popup position is as you'd expect - this is >> because the client tells the compositor where /relative to a surface/ >> it wants some other surface to appear, rather than a global position). > > This has caused problems for Emacs, though I can't remember exactly how, > so I'm guessing. On restarting a saved Emacs session, it's necessary to > have the windows the same size, in the same place they were on saving > the session. This would appear to be difficult in Wayland. yes, indeed, your memory serves right. that has been brought up on emacs-devel (in fact, I have some of those threads saved so that I can go back when I get some hacking time). in truth, I think the implementation in Emacs likely won't be (fully) reusable, since wayland will likely never let clients self-position like Emacs wants to. it has been said to me that a complete Emacs port 'requires' arbitrary positioning and cursor reading (IIRC, probably other stuff I'm forgetting). I'm afraid that's likely not to happen (but I'm not too sad about losing that functionality either). > You say "yes, intentionally, wayland is declarative wrt window > positioning". What does that mean when you replace abstract words like > "declarative" with concrete sentences? What is declaring what to what > else in this context, and what does that have to do with not being able > to position windows? well, it means that there will be a long and arduous process of standardization and development to most things people conventionally use these 'hacks' in X for, including this one: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18 I haven't read the full proposed protocol, but I suspect it is the right one here. the disadvantage of this approach is that it's slow as molasses, the advantage is that there will be a descriptive way to do something with no room for 'whoops, forgot this workaround' or 'huh, forgot that property', etc, and slightly different behaviour from program to program. > Later on, you say "where /relative to a surface/". I think "surface" is > a word with particular meaning in Wayland, and using it in a Gentoo list > without explanation is less than helpful. What does "surface" mean in > this context? Is the entire screen such a "surface"? well, the term is somewhat abstract because it is an abstraction :-) a surface is a rectangle of a program with some pixels on it that can receive events and stuff (so, a window of some kind). a toplevel surface is what we conventionally think of as proper windows (like the one I'm typing this email in, which Emacs calls a frame); a popup surface is for, well, popups (C-<right click> menu for instance). respectively, they are defined as: https://wayland.app/protocols/wayland#wl_surface https://wayland.app/protocols/xdg-shell#xdg_toplevel https://wayland.app/protocols/xdg-shell#xdg_popup the interface responsible for positioning popups is: https://wayland.app/protocols/xdg-shell#xdg_positioner the latter allows the client to tell the server where to put a new surface compared to the current one. this information is later passed to the server with a request to create a popup surface. > So, is it possible in Wayland to record a configuration of windows, > their sizes and positions, then restore these on starting a program > again? If not, that would appear to be a design bug in Wayland. What > am I missing? well, more like a todo or wip (which, yes, I'm aware is a frequently cited criticism, but I promise it's not as bad as it seems - as mentioned, I very rarely run into real limitations). wayland is extensible, so even though it is seeing relatively wide adoption, it also sees active development. (joke) but surely this is entirely unnecessary, because who ever closes emacs? :) have a lovely evening -- Arsen Arsenović
signature.asc
Description: PGP signature
