I'm using KDE with Wayland and 2 non-standard DPI monitors (one at 100% the other at 150% scale). No workarounds needed, nothing is blurry. I think your experience comes from GNOME which lacks behind in this regard.
FWIW, I can do the same with KDE on Xorg with Gentoo Linux.
Since the introduction of the XSETTINGS protocol in like 2003 or 2005 or so to provide a common cross-toolkit mechanism to communicate system settings, the absence of "non-integer" scaling support has always been the fault of the GUI toolkits.
> I think your experience comes from GNOME which lacks behind in this regard.
When doesn't GNOME lag behind? Honestly, most of Wayland's problems have been because a project that expects protocol implementers and extenders to cooperate in order to make the project work set those expectations while knowing that GNOME was going to be one of those parties whose cooperation was required.
The issue with X11 is that it's not dynamic. Think using a laptop, which you sometimes connect to a screen on which you require a different scale. X11 won't handle different scales, and it also won't switch from one to the other without restarting it.
No, it is. Maybe you're using an ancient (or misconfigured) Xorg? Or maybe you've never used a GTK program? One prereq is that you have a daemon running that speaks the ~20 year old XSETTINGS protocol (such as 'xsettingsd'). Another prereq is that you have a DE and GUI toolkit new enough to know how to react to scaling changes. [0]
Also, for some damn reason, QT and FLTK programs need to be restarted in order to render with the new screen scaling ratio, but GTK programs pick up the changes immediately. Based on my investigation, this is a deficiency in how QT and FLTK react to the information they're being provided with.
At least on my system, the KDE settings dialog that lets you adjust screen scaling only exposes a single slider that applies to the entire screen. However, I've bothered to look at (and play with) what's actually going on under the hood, and the underlying systems totally expose per-display scaling factors... but for some reason the KDE control widget doesn't bother to let you use them. Go figure.
[0] I don't know where the cutoff point is, but I know folks have reported to me that their Debian-delivered Xorg installs totally failed to do "non-integer" scaling (dynamic or otherwise), but I've been able to do this on my Gentoo Linux machines for quite some time.
I use whatever package is shipped by arch, so I think I'm fairly up to date.
I did look a bit into this at one point, but I've found that it's mostly QT apps which work fine with different scaling (telegram comes to mind). GTK apps never did, but I admit I never went too deep in the rabbit hole. Didn't know there was supposed to be some kind of daemon handling this. I do run xsettingsd, but for unrelated reasons. I'll have a look if it can update things.
In any case, except for work, I always used everything at 100% and just scaled the text as needed, which worked well enough.
> I've bothered to look at (and play with) what's actually going on under the hood, and the underlying systems totally expose per-display scaling factors...
Would you care to go into some details? What systems are those and how do you notify them there's been a change?
That's also my setup, the external 4k monitor is roughly the same scale as my FHD laptop. I did this on purpose, to avoid having to mess around with scaling and just run everything at 100%.
But more and more laptops start having higher resolutions nowadays, and using my external screen at a scale of more than 100% would be a waste. But a 3-4k 14" laptop at 100% would be unusable.
Signal is so much worse than WhatsApp from a UX perspective. Backup sync forces you to allow background permissions (WhatsApp doesn't), you have to set and get nagged to enter a PIN every few weeks (WhatsApp doesn't), there's no transcription for audio messages (WhatsApp has that for some languages), the desktop app loses its connection if you don't open it ever few weeks (WhatsApp works fine), etc.
You are moving the goal post. But you're right: Signal's E2EE is miles better than telegram's.
I was just trying to point out my experience in getting people to switch, most of the time they have different prioirities.
That's where the standard should come in and say something like "starting with C++26 char is always 1 byte and signed. std::string is always UTF-8" Done, fixed unicode in C++.
But instead we get this mess. I guess it's because there's too much Microsoft in the standard and they are the only ones not having UTF-8 everywhere in Windows yet.
Of course it can be made UTF-8. Just add a codepoints_size() method and other helpers.
But it isn't really needed anyway: I'm using it for UTF-8 (with helper functions for the 1% cases where I need codepoints) and it works fine. But starting with C++20 it's starting to get annoying because I have to reinterpret_cast to the useless u8 versions.
First, because of existing constraints like mutability though direct buffer access, a hypothetical codepoints_size() would require recomputation each time which would be prohibitively expensive, in particular because std::string is virtually unbounded.
Second, there is also no way to be able to guarantee that a string encodes valid UTF-8, it could just be whatever.
You can still just use std::string to store valid encoded UTF-8, you just have to be a little bit careful. And functions like codepoints_size() are pretty fringe -- unless you're not doing specialized Unicode transformations, it's more typical to just treat strings as opaque byte slices in a typical C++ application.
I never said always. Just add some new methods for which it has to be UTF-8. All current functions that need an encoding (e.g. text IO) also switch to UTF-8.
Of course you could still save arbitrary binary data in it.
> That's where the standard should come in and say something like "starting with C++26 char is always 1 byte and signed. std::string is always UTF-8" Done, fixed unicode in C++.
> I never said always
Yes you totally did. And regarding "add some new methods for which it has to be UTF-8", there is no need at all to add UTF-8 methods to std::string. It would be a bad idea. UTF-8 is not bound to a particular type (or C++ type). It works on _any_ byte sequence.
Good point, so maybe the standard should just add some functions that take std::string_view. Definitely not add a whole new class like std::u8string ...
Back in 2005 it was mostly in C++ and it was blazing fast. IMHO VS 2005 was the most performant edition. I never liked VS 2003, felt bloated in comparison.
On macOS too. On both operation systems 99% apps do though. Maybe its 99.9% on macOS vs 99.8% on Windows. But I'm using HiDPI on both and it was a long time ago that I encountered an app that didn't support it.
It can be: What definition to jump to if there are multiple (e.g. multiple Translation Units)? What if the function is overloaded and none of the types match?
With grep it's easy: Always shows everything that matches.
Sure, there might be multiple definitions to jump to.
With grep you get lots of false positives, and for some languages you need a lot of extra rules to know what to grep for. (Eg in Python you might read `+` in the caller, but you actually need to grep for __add__ to find the definition.)
Just rename root directory of project and double size of your repo
Mercurial didn't supported rename, and did delete/add instead, so size of repo grows pretty fast
GNOME still has some problems with fractional scaling, but KDE works perfectly. I'm using two displays, one with 150% and one with 100%. No blurry apps and absolutely no issues. Have you tried it recently?
Can you independently set desktop wallpapers on the two screens? I know this seems nitpicky but it's literally impossible with Ubuntu/Gnome as far as I know; I have one vertical and one horizontal and have to just go with a solid color background to make that work.
Yes. It was actually more tedious to do the inverse when I wanted three screens to do a rotating wallpapers from the same set of folders as I had to set the list of folders three times
KDE is in better shape than GNOME, but there are still some nits. Nearly all the available third party themes for example are blurry or otherwise render incorrectly with fractional scaling on.
To my understanding, doing that wouldn't be helpful due to hard technical limits that can't be reconciled. Most window chrome themes are Aurora themes, which don't play nice with HiDPI, and to change that they'd need to be rewritten as C++ themes (like the default Breeze theme is), which is beyond the capabilities of most people publishing themes.
I've been using fractional scaling on Gnome for years (including on the laptop I'm typing this on) and haven't had any issues. I haven't tried it with two displays that are set differently though. Is that a common thing?
reply