In 2022.
That is the kind of basic thing that does not work.
In addition to that, if you have a high-DPI laptop display and you want to plug it into a low-DPI desktop monitor (or vice-versa), good luck getting the scaling to work in a usable way.
Like just give me a big text file with hundreds of tweakables and tunables like X had...
They hide behind 'you just need to get your client to make the right API calls'... but that just means most wayland compositors don't support most of the available options...
The same config pane where I adjust my pointer speed should let me adjust my scroll speed.
Most users won't even know the difference between Wayland and X.org and X11 unless they are already the kind of tinkerers who used Linux on the desktop despite its drawbacks. Normal people have no idea what any of it means, and they should not need to know.
Sure? This is exactly the thing that Wayland was supposed to solve. Only X has one DPI for all screens.
I still use X because I'm on FreeBSD and I even got multi-screen multi-dpi scaling to work there, with xrandr settings but indeed it was not fun. In Wayland it should be click & play though.
It's not real multi-DPI no but effectively it does work. Does require a pretty decent GPU to render all screens at 200% before it scales them down though.
It's not a fault of Wayland but it is reflective of the whole Linux laptop experience.
Supposedly upstream electron has fixed this but I'm yet to see a single electron app that works. Maybe they just haven't updated electron.
For example when I move my mouse from my 192 DPI screen to my 96 DPI screen, the mouse position translates in physical pixel, not in physical location. So at the bottom it matches but near the middle of the 192 DPI screen it stops going to the left (it already ends up on the top of the 96 DPI screen going from the middle of the 192 DPI screen) and becomes an 'invisible wall'. Even in Windows 11 they didn't bother to fix this :(
The only OS that had a good transition to multi-DPI capabilities was macOS and that's really because Apple doesn't care about legacy and forces app devs to update their stuff. But it's not just Linux that's having a hard time with this.
But I didn't know this was a specific problem. I'm not using Wayland yet and won't for the foreseeable future. I'm on FreeBSD and KDE on Wayland has been broken a long time. When I hear this it sounds like a good decision anyway :)
Even sharing with the help of various 'portals', e.g. xdg-desktop-portal-gnome or xdg-desktop-portal-wlr
It 'simply' takes some arguments at runtime. Below are what I use -- taken from my Sway 'start on login' script [some is superfluous]:
ElectronThingHere --silent --enable-gpu --use-gl=egl --enable-features='VaapiVideoDecoder,VaapiVideoEncoder,WebRTCPipeWireCapturer,UseOzonePlatform' --ozone-platform=wayland
You can also replace --ozone-platform=wayland with --ozone-platform-hint=auto for less strong-handed encouragement
I use quite a few different Electron-driven things on Wayland. Discord is the only one seemingly refusing to update their Electron base... and getting free Wayland support
If not for them I'd remove XWayland support entirely from my Sway configuration
KDE's upcoming release in October should hopefully be addressing this by allowing you to disable the bitmap-based scaling.
If you want the "works so well it's boring", go with X11. The one exception, as you note, is multi-DPI, which has native support in Wayland.
For Wayland, there are (depending on DE/compositor) some specific issues or inconsistencies, like the scroll speed you are mentioning. Personally, I also have qt5 apps being all over the place with window placement under wlroots. There are times when you'll need to look up some environment variable to make an application or toolkit behave properly.
So if you're in the high-DPI+low-DPI scenario, yeah, it still takes some effort. For anyone else, I think OP holds.
My pick for a "boring stable desktop" stack:
* Dist: Your preference of Fedora/Debian/Arch. (Mint, Pop, and Endeavour acceptable derivatives)
* DE: Budgie/XFCE/MATE/Cinnamon
It is a community-developed project, so it only really needs to appeal to developers. What motivation is there to attract non-technical users? Particularly ones who require lots of effort doing uninteresting polishing related tasks to keep them happy. Other platforms do this sort of thing because their entire reason for existing is to satisfy customers.
Gotta say this issue sounds minor compared to not being able to set the scroll speed.
First of all, adjusting scrolling speed is not an "uninteresting polishing related task," it is a basic standard of usability.
Secondly, if you don't think Linux on laptops should be broadly usable by the general population, you are in the wrong thread. The central point of the HN post we are all commenting on is the usability of the Linux desktop ecosystem on commodity laptops.
Though it has nothing to do with Wayland before the flamewar starts, it’s just libinput and gtk maintainers not agreeing upon whose responsibility is it to handle scroll events (it is gtk’s though, libinput doesn’t have enough context to implement kinetic scrolling, so it really should be the framework that adds semantic meaning to an event stream)
Swaywm has the ability to set this (you have to edit the config file). It seems weird that gnome or whatever you use lacks this option. Although, gnome has a lot of t's to cross and i's to dot, maybe they just haven't gotten around to it.
You can check into git so you have a history of changes?
So you can copy the config to another machine?
There are lots of reasons why text files are the preferred format to store configuration in.
Other than perhaps a slight performance boost, why do we want settings in a non-human readable database?
Hell, even Microsoft are starting to use json config files for stuff like Windows terminal because they know people like to be able to quickly copy and edit settings.
You are talking about the configs being stored in text files. The comment you are responding to was talking about being forced to edit text files to configure.
Yours is about the format of data representation and theirs is about UX.
The first step of not forcing users to edit text files is having sensible well thought out defaults. If I have to think about configs the designers of the app failed me.
The second way to not force the users to edit text files is by having a well thought out gui for the kind of changes you might want.
The format of how the config settings are stored is almost orthogonal to this questions. And yes, you are right, a text based format is preferable over a properitary binary one.
The Windows mouse thing has been somewhat fixed in Win11 22H2, where you can now even move your mouse to the side "above" the other screen and it will still move there.
As for apps working seamlessly, I'm really not convinced. Not even the taskbar works well. If you change the DPI while it's running, the taskbar icons become blurry. The initial start menu (on first click) adapts fine, but then if you start typing to search something, the results are a blurry mess. Edge has weird artefacts in the tab animation after a DPI change, where half of the icon moves at a different speed. IntelliJ has funny fonts, with some of them huge, others tiny.
To me, the killer feature of MacOS when it comes to multi-DPI setups is that it remembers the per-screen-per-setup DPI. In my case, my PC has a 14" 1920x1080 screen. When I use it alone, it's much closer than with an external screen. I like it in 100% mode. When I plug in the screen, a 32" 4k, they're both much further away. They have roughly the same DPI (by design - I mostly use Linux) so there's no "matching" to do, but I'd like both of them to be at say 125%. Tough luck. If I change the laptop's screen to 125% while the external screen is plugged in, it will stay at 125% when on its own, too. MacOS would remember that with this screen it's 125%, alone it's 100.
At one point I was using two 24" screens, one 1920x1080, one 3840x2160. I've tried messing around with settings, until I ended up on xrandr scaling as being, basically, the only solution. Five minutes later, the low-dpi display was in the closet, because I couldn't stand the blurry fonts.
But indeed YMMV here.. There is no way to use non-anti aliased fonts at small sizes this way. For me it is fine, I would set it up the same way anyway but I forgot it's not for everyone.
Sure, but for me as an end user, it's irrelevant who's fault of this bazaar engineering endeavor it is that very basic quality of life features from Windows/MacOS do not work on Linux.
As a dev I understand the struggle why this and many other stuff doesn't work right on Linux, but as a consumer/end user I don't care about their internal feud and I expect the product I use to have basic stuff like this working out of the box.
Also, unfortunately the bazaar style of development sort of begets this kind end-user experience. Some people like it, others don’t. I change between OSX and Linux quite often nowadays, what I prefer in the latter is that I actually have a chance of fixing problems, not just wait around and pray to the Apple/Microsoft gods that they may have fixed the issue in the next multi-GB update. Also, piece-by-piece, free software often beats out proprietary offerings’ alternatives, it is usually the experience together with the whole stack that is lacking. E.g. pipewire may well be a better sound stack than that of the other two OS’s.
What did I attack and which false claims did I make?
>what I prefer in the latter is that I actually have a chance of fixing problems
What I and most consumers want is a product that does not require fixing or learning how to fix things. I and most other people don't want to play sys-admin at home despite having cut my teeth in it and making it a career. I work in cybersecurity so all our workforce is fluent in linux which we daily drive at work and yet at home everyone of us only uses Windows and/or MacOS on our personal machines with only one guy using Linux religiously at home.
When even experienced linux users don't want it in their personal lives that says something. Even though we know how to fix things but our free time is much more valuable. Nobody likes a desktop that stutters and ruins your immersion and productivity, especially if you're running a system that costs several grand.[1]
Maybe when the hardware manufacturers can work with the bazaar engineers and finally agree on something and work together with the desktop environment devs on how to make Wayland a fully feature complete drop in replacement for X11 with no rough edges, quirks or issues and have feature parity, smoothness and polish to Windows/MacOS, we can finally have the "year of the (polished) Linux desktop". Until then, I and most consumers will continue to use whichever OS provides the best experience with least amount of friction.
I gave a potential explanation to why some people may still prefer Linux, understanding well why others don’t.
The “looks like resolutions” work by setting your screen to the resolution it claims to be multiplied by two, and then downsampling the image to your native size. Depending on the resolutions involved, the screen might feel a bit blurry. On Windows, setting an intermediary scale changes the way the UI is drawn, while keeping your native resolution.
Sway is an example of a Wayland compositor, that is an actual piece of software, and has a config file.
> input <identifier> scroll_factor <floating point value>
> Changes the scroll factor for the specified input device. Scroll speed will be scaled by the given value, which must be non-negative.
The two-finger gesture scroll speed seems to be at a fixed speed, and way too slow for my liking.
I would like it to scroll faster than the mouse movement speed.