Noctia: A sleek and minimal desktop shell thoughtfully crafted for Wayland
github.com97 points by doener 3 days ago
97 points by doener 3 days ago
At first I thought "desktop shell" was supposed to be compositor, but that's not the case, a wayland compositor like sway is a requirement. I've been using sway for years I have no idea what a "shell" is? It's somewhere in between a desktop environment and a theme?
Yes. It occupies the spot in the Sway tutorials that recommend you "waybar, fuzzel, tofi, [etc]" to fill out the necessities. Noctalia, DMS, and other Quickshell projects cover that void.
I have no idea what shell means either! Isn’t it called ricing to customize desktop environment? Since when do people started calling it shell?
I'm not sure about Linux, but on Windows it's been called that since forever https://en.wikipedia.org/wiki/Windows_shell
I wonder where where LiteStep is at
used it (and sometimes SharpE) for a number of years until about idk 20y ago
https://en.wikipedia.org/wiki/LiteStep
https://reddit.com/r/LiteStep/comments/1fjnj9y/litestep_revi...
Still using X11, so no Noctia for me. Patiently waiting for somebody/someone to get remote desktop on Wayland. https://bugs.kde.org/show_bug.cgi?id=481912
You probably know this already, but the problem isn't remote desktop into a logged-in session (krdp supports this) but rather logging in remotely into a headless server without a local session running. This is slightly more complicated because the login manager has to get involved and present its UI remotely. This is what that bug is tracking.
If you're happy to use Gnome with GDM as the login manager, remote headless sessions are supported already with gnome-remote-desktop: https://gitlab.gnome.org/GNOME/gnome-remote-desktop#headless....
Personally, I am fine with starting sessions via ssh, don't need extra remote login.
Depends on everybody needs obviously, but say you have your dev machine that is remote, and you want to connect to it from a laptop (for real-estate reason or just for working from everywhere you want), maybe you want everything on the same (remote) machine like browser, db, IDE, etc and access to it as a remote "desktop" not just an ssh session.
Of course cli tools would be enough for somebody who likes a full TUI dev environment (and for my own use cases that would be enough) but for some people I understand the need, and I feel it is a regression for them to not have it.
I'm not familiar with the space, but wouldnt something that streams the whole screen like a video (WebRTC or Moonlight and VNC works like this ) work here too as well, and would be universal? Wayland already supports screen capture (into a texture, at interactive framerates) fairly well.
I'd say the problematic part is not capturing the desktop but injecting controls into it. Proper universal support for simulated input is still missing.
I have not used Wayland specifically, but did do this for X11, Windows, Qt, too much stuff to count... It usually takes the form of an api call like
DispatchEvent(&MouseEvent{MOUSE_L, 1345, 3432});
It's almost literally always this
This is something implemented by the compositor, so with KDE this may be addressed by the new Plasma Login Manager. GNOME already supports this.
[dead]
This is not a window manager, so thanks for stating the obvious. You might not like wayland and that's fine with me, but if you decide to hate on it, you should at least know what you are hating on. There are good reasons to prefer a wayland compositor over X11. If you don't care about these reasons, that doesn't mean nobody should.
> This is not a window manager, so thanks for stating the obvious.
So what exactly is a "shell" ?
My attempt at a definition of a desktop shell would be: The collection of all the software that aids a compositor (or a window manager on X11) in providing a more complete desktop experience. Now that's kind of vague and probably also not quite correct, so a more concrete explanation would be: A program or collection of programs that gives you desktop notifications, a taskbar (with a system tray), volume controls and more stuff like that, maybe even a neat menu to configure most of this. Usually for standalone compositors/window managers you'd usually use a collection of tools like dunst, polybar, and the like, but with newer tools like quickshell, which was used here, it's reasonably easy to build a single tool which handles most of that. And that's what we're looking at here ^^
Wayland got rid of screen tearing, an issue that plagued every machine I had used with X since I started using Linux in 2003/2004. That alone was enough for me to switch to sway in 2016, and I've never looked back. Xorg was nothing but headaches. Let's not even mention its security model.
[dead]
You can minimize tearing with double buffering so it's pretty rare but you can't completely eliminate it. Xorg by design cannot guarantee perfect frames. Tearing is something you'll notice every time it happens, whereas latency is not something that's necessarily an issue, and modern compositors have substantially reduced this latency.
I'm not really sure why Wayland gets all the hate it does, you'd think desktop Linux was perfect before Wayland came along and made everything totally unusable. As for myself, it's been a much better experience than Xorg ever was, pretty much since day one -- I've never had a torn frame, I've never had any issues with input lag, and I've never had to fuss with video settings. Not once. I'm sure some people have, but across a dozen machines I've had exactly zero problems in...a few months shy of a decade.
Let's not forget Xorg's own devs have put it on life support and recommend Wayland, which was created by Xorg devs, going forward. Nobody wants to maintain 35-year old spaghetti code of a fundamentally flawed design.
> latency is not something that's necessarily an issue
Of course it is not. Especially when GUI elements are black, waiting for the next, or other, frame. (hello Microsoft).
Out of curiosity, are you using nvidia? Which drivers are you using? I've never experienced this issue with an Intel or AMD graphics, even on a budget laptop.
[dead]
It's own devs have put it on life support because fixing the problems inherent to its design is not doable without breaking everything that works with it. I don't know what more justification you could want.
Go work on Xorg if you like, but that ship has sailed.
I prefer X11 as well, but it has some security issues. Notably, all applications can read your input at any time. It's really hard to sandbox.
Wayland brought some irritations, including increased latency, and an architecture that requires rethinking all window managers. A rewrite is not enough. Very annoying.
I will never understand why "the computer can tell what input it is receiving" has turned into an accepted threat model.
I understand that we have built a computer where our primary interface depends on running untrusted code from random remote locations, but it is absolutely incredible to me that the response to that is to fundamentally cripple basic functionality instead of fixing the actual problem.
We have chosen to live in a world where the software we run cannot be trusted to run on our computers, and we'd rather break our computers than make another choice. Absolutely baffling state of affairs.
Defense in depth. One compromised application may do a lot of harm if it has access to your keyboard inputs. Supply chain attacks are not that uncommon. While you can trust software developers, you cannot completely trust their builds.
[dead]
I agree. I think fixing the keylogging issue should be possible without dumping the entire architecture. Perhaps the new X11 fork https://x11libre.net will achieve that? At least, it's encouraging to hear it's getting maintained.
Regarding (recent) supply chain attacks, Linux needs to take supply integrity and sandboxing more seriously. The tools to do so are there (e.g. Nix and firejail/bwrap) and, unlike Wayland, they play well with existing software.