Better than you think. Every other time or so I log in in Gnome Shell in Wayland mode.
Thanks to xwayland you can run the majority of X.org applications without much problems in Wayland. The major problem with Wayland nowadays is bugs (I remember crashing my desktop trying to run mpv with Wayland native output, however OpenGL+GLX backend seems to work) and missing features (mainly touchpad support that is still treated as a mouse, or no touch support at all).
However running a Wayland setup has its advantages too, mainly improved composite performance in Gnome. No more screen tearing or skip frames of animation.
Thanks :) Things are mostly stable. Sway doesn't quite have all the features of i3, but it's getting there, and for bonus points it reads your i3 config file and interprets it correctly. I have trouble with floating windows, but if I wanted those I'd be using a different WM.
Probably my biggest complaint is that pretty much all of the graphical applications I use behave a bit oddly under Wayland because they're actually X applications running in XWayland. I spend most of my time in terminal emulators anyway, so it's not a huge deal.
Firefox and Chrome currently do not work on Wayland without Xwayland. But Libreoffice and Gnome work. You also have to use open source drivers for Wayland to work, so no Steam.
IPC
i3 has an IPC interface (it creates a socket that applications can connect to and issue commands or queries via its protocol), and sway replicates that protocol (so e.g. i3-msg can be used with sway by simply changing the socket, e.g. i3-msg -s $(sway --get-socketpath)). The code for that lies in sway/ipc.
No D-Bus in this day and age?
(not to undermine the otherwise impressive achievement, I was just a little surprised about this little backward bit. But then, I guess it's required for compatibility?)
Not using dbus for its ipc is a feature of i3 for me. What it has works perfectly compared to every interaction I've ever had with dbus, which is always pain.
Yeah i can't help wonder if dbus is one contribution element to making bluetooth painful on Linux.
This because the tray side client talks to the daemons over dbus to get anything done. And i have seen file transfer after file transfer get lost in dbus limbo.
By this i mean that i initiate a transfer from pc to phone via the gui. Everything checks out on both ends, but no data gets transferred.
So i hit abort, and try over, but now nothing happens at all.
And no restarting of the relevant daemons or clients change a thing.
Only by restarting dbus, and thus restarting my desktop along with it, will i be able to initiate a new file transfer (that may again get stuck in limbo).
i3 explicitly had a IPC interface separate from D-Bus:
"Implement an IPC interface for other programs. Provide subscription to certain events and accept commands.
This approach should be more lightweight than wmii’s usage of the 9P filesystem. Furthermore, core functionality does not depend on a separate program, so that i3 runs faster, especially when your system is under load."
https://i3wm.org/
I remembered this name from some place, then I looked at his github account and remembered he was the guy doing a cleanroom rewrite of minecraft. Amazing to go from that to working on this.
Considering the goal, which is stated very clearly in the README that's shown on the project page, that's not an out of line reply. Here's the first two paragraphs.
A completely clean-room implementation of Minecraft beta 1.7.3 (circa September 2011). No decompiled code has been used in the development of this software. This is an implementation - not a clone. TrueCraft is compatible with Minecraft beta 1.7.3 clients and servers.
I miss the old days of Minecraft, when it was a simple game. It was nearly perfect. Most of what Mojang has added since beta 1.7.3 is fluff, life support for a game that was "done" years ago. This is my attempt to get back to the original spirit of Minecraft, before there were things like the End, or all-in-one redstone devices, or village gift shops. A simple sandbox where you can build and explore and fight with your friends. I miss that.
Be careful googling for "Sway" and "Wayland" while at work... You might not get the screenshots you're expecting, although they will probably be shiny.
I did yet another quick search for "wayland remoting" and there still does not appear to be a well-supported story, so for me it's not even worth trying yet. In the age of IaaS and containers, who has just one computer?
It seems to me that something like xpra should be fairly easy to port to wayland. (For those who don't know, xpra installs itself as a compositing window manager, and then can render each window either locally or remotely).
A lot of people say "remoting wayland should be straightforward" but it keeps not happening. Either it's actually hard, or nobody on the project cares, which makes me question their judgment. Imagine how a display system would be received if it didn't support color on day one.
I think part of it is that the remoting situation on X is so bad that a lot of linux users just avoid it in favor of something like tmux or screen for remote work.
Remote desktop from the mid XP era just blows away anything that X has up to now.
ssh -Y will work find on a LAN, but higher latency links are a really bad experience; X11 is a very chatty protocol with a lot of round-trip delays. On top of that, you cannot detach from such sessions. If e.g. your ssh connection gets reset, you lose any unsaved work in the program.
Traditional VNC servers allow detachable sessions, but the local use is kind of crummy.
Tools like x11vnc are closer, but they lack options to lock the display on the local machine, which is something remote desktop has done by default since at least windows 2000.
Yes, I can see that. It certainly isn't ideal and I wouldn't do something crazy like running a web service based on this technology. However at least within a LAN it's good enough and I wouldn't want to loose this capability for the sake of 'moving with the times' (wayland).
Mostly usable unless you use nVidia or AMD with the binary drivers. AMD are going to be supported in the near future via their open-source amdgpu driver (for GPUs from 2015 onward) and nVidia will show up with a new driver that will support Wayland, any day now, we "promise".
So glad this is to make i3 work under Wayland. I jumped around with Tiled Window Managers for several years and it stopped 3 years ago when I started using i3. i3 has the best config system out (it reminds me of the old Arch rc file).
Once I saw this, I tried to use Wayland on an Arch Linux install. It worked great (apart from the really gross default cursor), until I tried to use gdm as my login screen. I have a two-screen setup (which worked fine with Sway if I just started it by itself). But if I start sway through gdm, the two screens would fuse into one screen. Is there any way to fix that? I'm guessing it's not a Sway issue, it's either an issue with the compositor Sway uses or just gdm.
I think it did some harm to have "i3way" announcing a port to wayland and even phrasing it like it already is a thing, when it seems like there has nothing been done yet for years. My bet is if this would not have been the case there probably already would have been much more development to port i3 to wayland... Anyhow great work :)
According to people in the know[1], X is severely bloated in terms of CPU usage, interface complexity, and useless code. X spends a lot of time performing useless actions, such as drawing a gray rectangle even when it knows that part of the screen is going to be rewritten by something useful. Going full-Wayland is bound to be lighter on the system. But traditional X clients run within XWayland. I don't know if XWayland offers anything more than compatibility, but going forward, as more and more toolkits and window managers wean themselves off X, "weaker" computers will have more resources to spend on doing useful stuff.
Funny, i have no trouble running X on a "weak" computer. What was bogging it down was never X, but KDE or Gnome. Going for a lighter DE, or stripping down to just a WM, greatly improves performance.
Frankly, the very thought that X is bloated seem insane, given that it originated in a time when servers had less resources to go on than many smartphones today.
No, what is "bloated" is the DE thinking that everything has to happen via the OGL pathway.
This makes X "bloated" in that it sits to a side and takes certain commands, while most of the UI work happens outside X.
> i have no trouble running X on a "weak" computer.
Well, obviously, your "weak" computer is powerful enough to handle X. Remember that not all computers are desktops, laptops, or phones. We have Linux running on industrial PLC's, CNC machines, and so many other things that are not thought of as "computers". There are buyers of these at even extremely low price-points, so it's not uncommon to host everything on one processor.
> Frankly, the very thought that X is bloated seem insane
Quit the empty snark. Have you actually compared X and VNC for remote access? Try running Firefox from a remote desktop. To understand what's going on, watch the talk I linked to in my previous comment.
People have real needs, and they are working on solutions, be it Wayland, Mir, Freon, running GUI on a PLC, or whatever else. I get that you don't have these needs, but can't you even understand that other people do? Have you compared X and VNC yet?
It seems obscuring the filename / sub group tags is probably necessary in this world where everything is recorded forever. Especially when the author has public name and employment record.
I watched a few episodes of Angel Beats, ultimately it didn't keep my attention.
> It's pretty funny (positive) that you don't include .deb or .rpm packages. This isn't for any of them.
Is it particularly common for projects to provide .deb or .rpm packages? Given the dependency hell of out-of-repo packages, I've found it's much easier to simply:
maybe not on github, but usually on their websites, a project will provide packages. Sometimes, these are donated by users. Often, they're provided by the developers themselves.
