I have a problem with this article, because it doesn't address my main gripe with Wayland - segmentation. X11 is a server, but Wayland is not. Wayland is a protocol, and that means that the...
I have a problem with this article, because it doesn't address my main gripe with Wayland - segmentation.
X11 is a server, but Wayland is not. Wayland is a protocol, and that means that the implementation of most basic stuff comes from the composer. This design is clearly made specifically for huge DE projects like GNOME or KDE, but it leaves people that don't rely on huge multipurpose chunks of coupled software. It's 2019, and Linux desktop is still pretty segmented - every DE has its own web browser, text editor, file manager, composer, hotkey daemon, settings daemon, etc. And if you aren't willing to go along with any DE's vision, then here is what Wayland means - you would have to make WMs much more than they are. Now even a minimalist DE like bspwm would have to implement it's own hotkey daemon, and as it's been put in the article - people in charged aren't interested in it. Drew himself is the author of Sway, an i3-inspired replacement for Wayland, and the compatibility of Sway with i3 tools is well known to be awful. Even the simplest things fail to function, despite XWayland, and that's because there is no way around the composer now. You want an overlay that never gets through a composer? Nope, can't do so, a composer has to have specific entry point for such thing! And that's where the whole thing leads to - if you are trying to do something that had never been done before, for example, redshift - Wayland has to provide an interface for it, and then every composer ever has to implement that interface. The mention he made with first-person shooters is another shiny example of how narrow and cherry-picky the specification is.
Yep, that sucks a lot. It has to do with UI framework fragmentation more than DE fragmentation, by the way. You know what solves this? Electron. But saying this triggers a lot of people because...
It's 2019, and Linux desktop is still pretty segmented - every DE has its own web browser, text editor, file manager, composer, hotkey daemon, settings daemon, etc.
Yep, that sucks a lot. It has to do with UI framework fragmentation more than DE fragmentation, by the way. You know what solves this? Electron. But saying this triggers a lot of people because electron bloated, javascript bad, webdev lame, etc. There's legitimate problems with Electron of course but they should be worked on, rather than getting smugged on.
I keep wanting to write an in-depth post/article about why Electron is the potential saving grace of the Linux desktop if we pursue it as our future. But cutting through the noise of people who'd rather open up a few veins than "run arbitrary javascript" (as if they don't already run arbitrary C) is tedious.
For context, I was the project lead on LXQt for a long time, which is exactly what you're talking about (a small non-tightly-coupled DE that doesn't rely on huge chunks of coupled software). And it's currently the polar opposite of Electron. I'm saying all this as someone who adores Qt, too.
You can cry about it all you want, but it's true. I've used VSCode as my daily text editor for about a year now. The wide range of extensions make it pretty unbeatable, but literally everything...
But saying this triggers a lot of people because electron bloated, javascript bad, webdev lame, etc.
You can cry about it all you want, but it's true. I've used VSCode as my daily text editor for about a year now. The wide range of extensions make it pretty unbeatable, but literally everything about it is just okay. It takes 400mb of memory for an empty window. It lags badly when running on my laptop's integrated GPU. JavaScript is bad. I don't even know anyone who would argue that point. I just wish I could find someone who would actually pay me to write good tools, because I don't have the time or energy to do it on my personal time.
I'm not crying about it. As I said, Electron's pitfalls are known and accepted. What's important is to work on it, not say "Javascript is bad". Especially since Javascript is absolutely not the...
Exemplary
I'm not crying about it. As I said, Electron's pitfalls are known and accepted. What's important is to work on it, not say "Javascript is bad".
Especially since Javascript is absolutely not the root of the issue you're encountering. That you don't know why that point would be argued doesn't make you more correct. Flat earthers don't know why non-flat-earthers would argue the earth is round, after all.
I just wish I could find someone who would actually pay me to write good tools, because I don't have the time or energy to do it on my personal time.
You sincerely need to take yourself down a notch.
I've been lucky enough to, during my career in open source, meet hundreds of extremely talented engineers (paid and unpaid) who write excellent tools. Even if you were part of that group, you'd just be joining a long, long line of others who do just the same and it makes absolutely no difference to what you're talking about.
In fact, the most significant advancements come from Microsoft and Facebook, who have contributed incredible value to the JS and Python ecosystems. VSCode (by MS) for example has contributed immense firepower to Electron and they're actively improving it, because it's core to the product.
In the mean time, most classic UI frameworks are dying off in favour of Electron. Yes it's a problem for weaker devices; as the owner of a $2000 laptop that can barely run VSCode+Discord+Chrome without running OOM, I'm acutely aware of this. But seriously, how does your reply and mindset actually advance the needle?
I could give you $50k to write a few Qt apps that'll run great on my laptop. Now what? Qt is losing devshare, and that's the most successful of them. The entire model desktop environments are designed is falling behind because it's incompatible with the way work gets done today.
The greatest advancements JS and the web have brought to developers is making very complex systems accessible to build to a very large amount of new devs. This is why they're so popular. This being brought to the desktop through Electron isn't "killing" the desktop, it's what's keeping it alive. If Windows and macOS had their way, we'd just be running an app store.
So with you, I'm down $50k, and nothing has changed. I've seen this happen with LXQt: We ran out of manpower, despite my proactive fighting of fragmentation (eg. partnering up with KDE and the Hawaii project, actively reaching out to other devs, etc). It's still chugging along and hell, I'm running LXQt after all. But it's low quality, and the project has lost more of its developers than it'll gain back, because C++ is not an accessible enough language.
You can of course also pay everyone on the team. This needs a source of funding. There's nothing special about that DE other than "it runs slightly better than other DEs" and people don't really care about that, so you won't be selling/licensing it. It certainly won't get FAANG funding. So far, there's nothing viable about developing a traditional non-mobile environment.
So, what can we do? Well, a successful project would need developer viability, which means it has to be part of the JS ecosystem. And for it to be technologically viable, the pitfalls of using a web renderer core need to be addressed. Google is the best positioned to do this, and they've attempted it with ChromeOS but somewhat botched the execution (and even then it wasn't a complete failure). Mozilla also attempted their version of this (FirefoxOS), but that project failed for too many reasons to count.
I think once an Electron (or whatever) shared server is available, this all becomes possible. But we're talking something really low level, like at the compositor level. And you need X11 compatibility. And you need good app bundling that won't scare off commercial users.
Oh and of course this all needs to be fully Electron API-compatible. Those apps are being written for the web, and macOS and Windows are the main target, not Linux. Maybe we'll get there. Maybe next year will be the year of the Linux desktop, too.
This is one of the few times I've had to flag a comment for malice. As you seem to be a new account, please read the site's guidelines about civil discourse. https://docs.tildes.net/overall-goals...
You can cry about it all you want...
This is one of the few times I've had to flag a comment for malice. As you seem to be a new account, please read the site's guidelines about civil discourse.
Additionally, dismissing an entire language and its ecosystem as "bad" is not a substantiated argument. Javascript is one of the fastest interpreted languages on the block, has enormous library support and exceptional cross-platform support. There's few reasons not to use it.
I'd be interested in reading this. I have run a couple Electron apps that has not melted my computer: VS Code, and Spotify is Electron too if I'm not mistaken. Spotify apps are all low quality,...
I keep wanting to write an in-depth post/article about why Electron is the potential saving grace of the Linux desktop if we pursue it as our future. But cutting through the noise of people who'd rather open up a few veins than "run arbitrary javascript" (as if they don't already run arbitrary C) is tedious.
I'd be interested in reading this. I have run a couple Electron apps that has not melted my computer: VS Code, and Spotify is Electron too if I'm not mistaken. Spotify apps are all low quality, Android and desktop, but VS Code is great software, albeit seemingly slower than Sublime.
Having tried to write an Android app with the standard API and also Flutter, I saw why folks want to do PWAs. These APIs and the development experience sucks. The fragmentation of UI toolkits suck. But also, writing a graphical app that compiles to native code is a nice thing to have, because the GUI adds some inherent performance overhead.
I wonder what would happen if Qt adopted Go or D or something instead of C++.
What the article says mostly makes sense, but I take issue with a few parts, and some things are left unaddressed. This doesn't exactly fill me with confidence in the stability of the Wayland...
What the article says mostly makes sense, but I take issue with a few parts, and some things are left unaddressed.
support [for the pointer constraints extension] was added to sway a few weeks ago.
This doesn't exactly fill me with confidence in the stability of the Wayland ecosystem – why should I use software that's changing so rapidly? Further, how long will it take for other software to support the pointer constraints extension (e.g. does XWayland support it?)
If you find your needs aren’t met by Wayland, just keep using X! We won’t be offended. I’m not trying to force you to use it.
Sure, in the same way that I can keep using Windows XP because I think that every version since then has had worse UI. Wayland is, like it or not, the future, and at some point it will end up being harder than I can justify to continue using X.
Users are then encouraged to use the compositor’s own keybinding facilities to execute this command.
Why is the compositor responsible for keybindings?
In the same post you say you're not confident in using Wayland because it's too early, but then when he says you should still use X11 if you're not ready you say you have to use Wayland because...
In the same post you say you're not confident in using Wayland because it's too early, but then when he says you should still use X11 if you're not ready you say you have to use Wayland because it's the future.
The point is that it's still in early adopter phase, I don't think anyone is pretending otherwise.
Ubuntu would disagree with you – version 17.10 defaulted to Wayland. They've since changed the default back to X, but AFAIK they intend to change back to Wayland by default by 20.04.
The point is that it's still in early adopter phase, I don't think anyone is pretending otherwise.
Ubuntu would disagree with you – version 17.10 defaulted to Wayland. They've since changed the default back to X, but AFAIK they intend to change back to Wayland by default by 20.04.
Your comment seems to agree with what I just said. Ubuntu very clearly made a mistake switching the default to Wayland as they rolled it back, and they won't make it default again until at least a...
Your comment seems to agree with what I just said. Ubuntu very clearly made a mistake switching the default to Wayland as they rolled it back, and they won't make it default again until at least a year from now.
And the other half of that is that hotkey daemons I'm sure are a very small portion of the overall hotkey thing. On my laptop, when I'm in a video call with my girlfriend she just has to deal with...
Users are then encouraged to use the compositor’s own keybinding facilities to execute this command.
And the other half of that is that hotkey daemons I'm sure are a very small portion of the overall hotkey thing. On my laptop, when I'm in a video call with my girlfriend she just has to deal with my laptop fans roaring in her ears because push-to-talk doesn't work under Wayland. Even if SimpleScreenRecorder worked under Wayland, I wouldn't be able to use my hotkeys to start/stop it. Same for OBS.
Apps creating command line interfaces to interact with running instances of GUI programs just so you can add your hotkeys in your compositor's settings seems fragile, hacky, and a massive step backwards.
It's removing fragmentation of the overall desktop environment in favor of heavy fragmentation among every single application and fragmentation among the different compositors. Used to be, apps...
It's removing fragmentation of the overall desktop environment in favor of heavy fragmentation among every single application and fragmentation among the different compositors.
Used to be, apps worked together seamlessly. I can pick this window manager and that compositor and this hotkey daemon and that other on-screen keyboard and that other dock and that screen recorder over there and this screencast key overlay over here and it all worked.
Now, your app wants to listen to input so you can have push to talk? Or share your screen? Or simulate user input so you can create an on screen keyboard that doesn't suck hairy monkey balls? Gotta talk to the compositor. Fingers crossed they even support that. And no two compositors can ever agree on what API should be used, so each of those individual, (formerly) simple tools must now fragment huge chunks of themselves off for each compositor they want to support, again, if that compositor even allows it.
Under Wayland, I will never have a usable on-screen keyboard (least not under GNOME). My girlfriend has to deal with constant loud background noise in calls because push to talk doesn't work. My Steam Controller loses a lot of functionality. SC-Controller's menus don't work and they're just simple overlays on the screen with no need to capture input or anything. If I want to pick a color off my screen, I need to take a screenshot and fire up GIMP.
The fragmentation isn't gone. It was pushed and spread around.
I have a problem with this article, because it doesn't address my main gripe with Wayland - segmentation.
X11 is a server, but Wayland is not. Wayland is a protocol, and that means that the implementation of most basic stuff comes from the composer. This design is clearly made specifically for huge DE projects like GNOME or KDE, but it leaves people that don't rely on huge multipurpose chunks of coupled software. It's 2019, and Linux desktop is still pretty segmented - every DE has its own web browser, text editor, file manager, composer, hotkey daemon, settings daemon, etc. And if you aren't willing to go along with any DE's vision, then here is what Wayland means - you would have to make WMs much more than they are. Now even a minimalist DE like bspwm would have to implement it's own hotkey daemon, and as it's been put in the article - people in charged aren't interested in it. Drew himself is the author of Sway, an i3-inspired replacement for Wayland, and the compatibility of Sway with i3 tools is well known to be awful. Even the simplest things fail to function, despite XWayland, and that's because there is no way around the composer now. You want an overlay that never gets through a composer? Nope, can't do so, a composer has to have specific entry point for such thing! And that's where the whole thing leads to - if you are trying to do something that had never been done before, for example, redshift - Wayland has to provide an interface for it, and then every composer ever has to implement that interface. The mention he made with first-person shooters is another shiny example of how narrow and cherry-picky the specification is.
Just a minor nitpick, that may be incorrect, but I thought X11 was the protocol, and X.Org is the primary (server) implementation.
This is correct, back when there were multiple implementation (Xfree86) there also was segmentation in the X11 world
Yep, that sucks a lot. It has to do with UI framework fragmentation more than DE fragmentation, by the way. You know what solves this? Electron. But saying this triggers a lot of people because electron bloated, javascript bad, webdev lame, etc. There's legitimate problems with Electron of course but they should be worked on, rather than getting smugged on.
I keep wanting to write an in-depth post/article about why Electron is the potential saving grace of the Linux desktop if we pursue it as our future. But cutting through the noise of people who'd rather open up a few veins than "run arbitrary javascript" (as if they don't already run arbitrary C) is tedious.
For context, I was the project lead on LXQt for a long time, which is exactly what you're talking about (a small non-tightly-coupled DE that doesn't rely on huge chunks of coupled software). And it's currently the polar opposite of Electron. I'm saying all this as someone who adores Qt, too.
You can cry about it all you want, but it's true. I've used VSCode as my daily text editor for about a year now. The wide range of extensions make it pretty unbeatable, but literally everything about it is just okay. It takes 400mb of memory for an empty window. It lags badly when running on my laptop's integrated GPU. JavaScript is bad. I don't even know anyone who would argue that point. I just wish I could find someone who would actually pay me to write good tools, because I don't have the time or energy to do it on my personal time.
I'm not crying about it. As I said, Electron's pitfalls are known and accepted. What's important is to work on it, not say "Javascript is bad".
Especially since Javascript is absolutely not the root of the issue you're encountering. That you don't know why that point would be argued doesn't make you more correct. Flat earthers don't know why non-flat-earthers would argue the earth is round, after all.
You sincerely need to take yourself down a notch.
I've been lucky enough to, during my career in open source, meet hundreds of extremely talented engineers (paid and unpaid) who write excellent tools. Even if you were part of that group, you'd just be joining a long, long line of others who do just the same and it makes absolutely no difference to what you're talking about.
In fact, the most significant advancements come from Microsoft and Facebook, who have contributed incredible value to the JS and Python ecosystems. VSCode (by MS) for example has contributed immense firepower to Electron and they're actively improving it, because it's core to the product.
In the mean time, most classic UI frameworks are dying off in favour of Electron. Yes it's a problem for weaker devices; as the owner of a $2000 laptop that can barely run VSCode+Discord+Chrome without running OOM, I'm acutely aware of this. But seriously, how does your reply and mindset actually advance the needle?
I could give you $50k to write a few Qt apps that'll run great on my laptop. Now what? Qt is losing devshare, and that's the most successful of them. The entire model desktop environments are designed is falling behind because it's incompatible with the way work gets done today.
The greatest advancements JS and the web have brought to developers is making very complex systems accessible to build to a very large amount of new devs. This is why they're so popular. This being brought to the desktop through Electron isn't "killing" the desktop, it's what's keeping it alive. If Windows and macOS had their way, we'd just be running an app store.
So with you, I'm down $50k, and nothing has changed. I've seen this happen with LXQt: We ran out of manpower, despite my proactive fighting of fragmentation (eg. partnering up with KDE and the Hawaii project, actively reaching out to other devs, etc). It's still chugging along and hell, I'm running LXQt after all. But it's low quality, and the project has lost more of its developers than it'll gain back, because C++ is not an accessible enough language.
You can of course also pay everyone on the team. This needs a source of funding. There's nothing special about that DE other than "it runs slightly better than other DEs" and people don't really care about that, so you won't be selling/licensing it. It certainly won't get FAANG funding. So far, there's nothing viable about developing a traditional non-mobile environment.
So, what can we do? Well, a successful project would need developer viability, which means it has to be part of the JS ecosystem. And for it to be technologically viable, the pitfalls of using a web renderer core need to be addressed. Google is the best positioned to do this, and they've attempted it with ChromeOS but somewhat botched the execution (and even then it wasn't a complete failure). Mozilla also attempted their version of this (FirefoxOS), but that project failed for too many reasons to count.
I think once an Electron (or whatever) shared server is available, this all becomes possible. But we're talking something really low level, like at the compositor level. And you need X11 compatibility. And you need good app bundling that won't scare off commercial users.
Oh and of course this all needs to be fully Electron API-compatible. Those apps are being written for the web, and macOS and Windows are the main target, not Linux. Maybe we'll get there. Maybe next year will be the year of the Linux desktop, too.
This is one of the few times I've had to flag a comment for malice. As you seem to be a new account, please read the site's guidelines about civil discourse.
https://docs.tildes.net/overall-goals
Additionally, dismissing an entire language and its ecosystem as "bad" is not a substantiated argument. Javascript is one of the fastest interpreted languages on the block, has enormous library support and exceptional cross-platform support. There's few reasons not to use it.
I'd be interested in reading this. I have run a couple Electron apps that has not melted my computer: VS Code, and Spotify is Electron too if I'm not mistaken. Spotify apps are all low quality, Android and desktop, but VS Code is great software, albeit seemingly slower than Sublime.
Having tried to write an Android app with the standard API and also Flutter, I saw why folks want to do PWAs. These APIs and the development experience sucks. The fragmentation of UI toolkits suck. But also, writing a graphical app that compiles to native code is a nice thing to have, because the GUI adds some inherent performance overhead.
I wonder what would happen if Qt adopted Go or D or something instead of C++.
Spotify is CEF, unless they recently changed. It's basically the same as electron, but before electron was a thing.
What the article says mostly makes sense, but I take issue with a few parts, and some things are left unaddressed.
This doesn't exactly fill me with confidence in the stability of the Wayland ecosystem – why should I use software that's changing so rapidly? Further, how long will it take for other software to support the pointer constraints extension (e.g. does XWayland support it?)
Sure, in the same way that I can keep using Windows XP because I think that every version since then has had worse UI. Wayland is, like it or not, the future, and at some point it will end up being harder than I can justify to continue using X.
Why is the compositor responsible for keybindings?
In the same post you say you're not confident in using Wayland because it's too early, but then when he says you should still use X11 if you're not ready you say you have to use Wayland because it's the future.
The point is that it's still in early adopter phase, I don't think anyone is pretending otherwise.
Ubuntu would disagree with you – version 17.10 defaulted to Wayland. They've since changed the default back to X, but AFAIK they intend to change back to Wayland by default by 20.04.
Your comment seems to agree with what I just said. Ubuntu very clearly made a mistake switching the default to Wayland as they rolled it back, and they won't make it default again until at least a year from now.
And the other half of that is that hotkey daemons I'm sure are a very small portion of the overall hotkey thing. On my laptop, when I'm in a video call with my girlfriend she just has to deal with my laptop fans roaring in her ears because push-to-talk doesn't work under Wayland. Even if SimpleScreenRecorder worked under Wayland, I wouldn't be able to use my hotkeys to start/stop it. Same for OBS.
Apps creating command line interfaces to interact with running instances of GUI programs just so you can add your hotkeys in your compositor's settings seems fragile, hacky, and a massive step backwards.
As far as I know, Wayland doesn't fragment things like in X; the compositor is basically everything.
It's removing fragmentation of the overall desktop environment in favor of heavy fragmentation among every single application and fragmentation among the different compositors.
Used to be, apps worked together seamlessly. I can pick this window manager and that compositor and this hotkey daemon and that other on-screen keyboard and that other dock and that screen recorder over there and this screencast key overlay over here and it all worked.
Now, your app wants to listen to input so you can have push to talk? Or share your screen? Or simulate user input so you can create an on screen keyboard that doesn't suck hairy monkey balls? Gotta talk to the compositor. Fingers crossed they even support that. And no two compositors can ever agree on what API should be used, so each of those individual, (formerly) simple tools must now fragment huge chunks of themselves off for each compositor they want to support, again, if that compositor even allows it.
Under Wayland, I will never have a usable on-screen keyboard (least not under GNOME). My girlfriend has to deal with constant loud background noise in calls because push to talk doesn't work. My Steam Controller loses a lot of functionality. SC-Controller's menus don't work and they're just simple overlays on the screen with no need to capture input or anything. If I want to pick a color off my screen, I need to take a screenshot and fire up GIMP.
The fragmentation isn't gone. It was pushed and spread around.
But why is that a good thing? Why does everything have to be in the compositor?