wayfire VS wayland-protocols

Unusable until moving your mouse to the edges of the screen and clicking makes it hit the scrollbar, or the exit button. Right now it initiates a resize.

Illustrated example from a different compositor https://github.com/WayfireWM/wayfire/issues/570

It's the only DE I'm excited about it so I hope they fix that. Very very promising and the best part is that it made the GNOME people mad.

GNOME: "Sorry I don't see the use case for that, PR closed. Make your own project. "

One of the developers just responded on the github issue referecing this thread.

"After a bit of discussion on HackerNews, I got a bit better understanding of the actual problem. People don't want to just configure the keys according to a particular layout - the actual 'issue' here is that they expect the key binding changes together with the layout. Unfortunately, the 0.8.0 changes didn't make this possible to implement as a plugin.

I would reconsider adding this as an option if there are enough interested people. React with a thumbs up to this comment if you are interested in having this option (though the defaults will certainly remain as they are now). Please, react only if you actually use Wayfire or would use it if it had this feature :)"

https://github.com/WayfireWM/wayfire/issues/1601#issuecommen...

I have been on Wayfire for over a year now, and I can't possibly praise it enough. It's entirely modular, so you can make it look and behave exactly as you want. It does tiling, it does Compiz-style wobbly windows and 3D desktop cubes, configurable rules and hotkeys, everything. It's stable and handles gaming flawlessly.

Your impression of Wayland is going to be very much determined by the quality of the compositor implementing it, and I've found Wayfire to be the best, by far - but oddly, also the one least talked about. Everybody's paying attention to stuff like Hyprland, Sway and Mutter - you're barking up the wrong tree there. Wayfire is fantastic, has most of the bells and whistles Compiz on X11 has, and is as pretty or as functional as you want it to be.

- VR support

I thought so too not long ago, but Wayland compositors needed some time to mature, and some of them are getting pretty damn good. Ever since I discovered Wayfire I'm a total believer, it's better than any X window management solution I've used. Much lighter too.

might be a small window when wayfire releases a version, before master identfies as the next release number. (see: https://github.com/WayfireWM/wayfire/blob/master/meson.build )

I was wondering which .so contains the symbols for https://github.com/wayland-project/wayland-protocols/blob/main/unstable/input-method/input-method-unstable-v1.xml.

I was researching the issue and noticed wlr-screencapture. I was hoping to see it at https://github.com/wayland-project/wayland-protocols too, but no luck. Thanks for the lead on xfg-desktop-portal.

It is fascinating watching the near decade-long journey as Wayland tackles screenshots.

> Nothing is thrown away -> xserver is there for exactly this reason. Adding the extension for a system with bad abstraction is not too wise, but if you wanted to understand it, you would have done so already based on the video.

I did watch the video, and while I was convinced that the X.org reference implementation was crusty, I was not convinced that there was anything inherently wrong with X11-the-protocol. Like, if there existed an X extension whose responsibility was just to get clients set up with their own video buffers that it could composite for them, then it sounds like it would address 90% of Wayland's value proposition. Is there a particular video snippet you want me to pay special attention to that clarifies this?

> Why would it be lost? There is a core protocol that absolutely specifies it.

I read through the stable interface definitions in the wayland-protocols repo [1], and did not see anything related to controlling which programs get to see which events. Is this still in development (or unstable)? If so, is there an ETA at which point I can expect every correct Wayland compositor to faithfully implement it?

> And when you had only one player in the whole game.. which is pretty contradictory to your last sentence.

That's because the X server implements the mechanisms, not policies, for multiplexing the screen and input devices. In the service of this, it provides tools to enumerate, identify, query, modify, and extend properties of windows, as well as route messages between them. There was never a compelling need for multiple competing incompatible X servers because X is the narrow waist (i.e. an unopinionated digital commons) shared by software that competed on policy.

> I didn’t address these things because basically everything has a solution under wayland nowadays. Please have a look at the wayland-protocol repo and see for yourself the state of it. Also, wayland is a display manager, just because the X server was a monolith, it had no place to eg. manage clipboard. Actually, Wayland is the one that fulfills the UNIX philosophy of do one thing (although I don’t find the UNIX philosophy a good thing in every case)

I read through the unstable interface definitions, and see that Wayland is indeed trying to implement not only the same kinds IPC facilities and input device multiplexing that X provided, but also is trying to impose stronger opinions on what types of windows exist and how they behave (e.g. Wayland has a notion of pop-ups, text inputs, and so on). So if Wayland's goal is to avoid being as "monolithic" as X, it appears to be failing.

Also, putting core functionality that everyone must implement the same way into extensions just so they can call Wayland "just a protocol" or "just a display manager" is disingenuous. They might as well just say that they're part of the core protocol.

> No, you just use wlroots that implemented the “crap-ton” of extensions for you already, and be on your way.

Does the wlroots project define what extensions are standard and required for a piece of software to call itself a Wayland compositor? No? Then "just use wlroots" isn't addressing the problem of making sure these compositors are compliant to a set of common, useful standards. Like, maybe wlroots should be the standard-definer, just as X was? What happens with window managers built with a compositor that is not wlroots?

[1] I was looking here: https://github.com/wayland-project/wayland-protocols

Virtual keyboard: https://bugs.kde.org/show_bug.cgi?id=427972 it is still a hot-topic on the protocol definition side with the current definition https://github.com/wayland-project/wayland-protocols/blob/master/unstable/text-input/text-input-unstable-v3.xml still not satisfactory, this was one of the subject of this weekend Plasma Wayland online Sprint. The Virtual keyboard is especially important for different input methods, aka chinese, japanese, koreans characters. You may want to setup http://maliit.github.io/ on your system.

The protocol XML files have remarkable, concise documentation of each request, event and interface. Core protocol. Other protocols.