In issue 2776, GitHub user keefer223 reported a one-line Dogecoin Core GUI startup error that’d flashed past on my screen a few times, but I’d ignored:
Attribute Qt::AA_EnableHighDpiScaling must be set before QCoreApplication is created.
In my defense, I’ve used Linux on the desktop for enough years (first when
startx was a command you had to know, then through the X11 to X.org
transition and now to Wayland) that I’m used to GUI applications providing a
lot of warnings when launched from the command line.
I’ve written before that reviewing compiler warnings is important, and the same goes for runtime warnings. Maybe something isn’t wrong, but something’s unexpected and potentially interesting.
You Can’t Get There From Here
If you look for the text of that error online, you’ll see that the solution almost immediately presents itself.
The Qt GUI toolkit has a lot of configuration options, and some of them you can change when the program is running. Others you can’t. Modern versions of Qt support high-DPI mode, so for machines with a lot of tiny pixels, Qt will scale its widgets to look crisper and cleaner, instead of fuzzy.
You just have to tell it do to that when it can do something about it.
PR 2778 is really small and almost not worth talking about. It’s almost a verbatim cherry-pick of Bitcoin’s PR 16245, with a minor change in ancillary code.
There’s nothing exciting in this code or the process, and with one person commenting “Yep, that PR looks like it does exactly what the Bitcoin PR does” and another saying “I’ve tried this and see it has the desired effects”, there’s no controversy or anything. It just works.
What’s interesting is what happens next.
It’s Fixed on My Machine
A few weeks after we merged this code and closed the bug, GitHub user carlray1988 fixed issue 2855, asking for the exact scaling improvements this PR provided.
Some people might grumble “Hey, this is a duplicate of another issue that’s already been closed!” but that’s the wrong attitude, in my opinion. I’m actually glad to see this bug report, because it shows that people are using the software, finding things they’d like to improve, and writing good bug reports (this is a good bug report!).
These are all great things!
It’s important for developers to remember that software that isn’t released in a form usable by end-users isn’t released. Just because we merged that backport PR doesn’t mean that high-DPI scaling is fixed, from the point of view of users.
It will be when we release 1.14.6. Until that happens, there’s not much users can do but wait.
Even then, we don’t know that it’s fixed entirely in 1.14.6. I tested on Linux. Patrick tested on Mac OS. carlray1988 reported the issue on Windows 11. While it’s likely that moving a couple of lines fixed everything for everyone, we won’t be certain until we get more eyeballs on the GUI before and after this change.
Testing Pre-Releases and Code in Development
How do we address this?
The obvious answer is “anyone who files an issue is savvy enough to build and test the code themselves from a git branch”, but I think that’s both true and slightly wrong.
My response to issue 2855 was “We believe we’ve fixed this, and we could use help testing on your platform, but I know this might be more work than you’re comfortable doing”.
I felt pretty good about that, but then Patrick came in (as he often does) to go above and beyond. He built preview binaries for Windows that anyone can use to test this code in progress.
There’s a great big red flag stop sign warning on those binaries: not that
they’re unreliable, because they use the same gitian build process the
official releases do, but that they’re only for testing. Do not use them for
day-to-day operations unless you know exactly what that means and why.
But if you’re comfortable running through a few tests of new features and options and improvements and you’ve backed up your wallet and data and isolated it from your test environment, you can do everyone a big favor and help improve our confidence that the code does what it says.
I don’t know that there will be regular gitian builds on a fixed schedule, but when 1.14.6 gets closer to release, it seems likely we’ll have preview binaries for selective testing.
As always, you can download and compile the code yourself, but you shouldn’t have to do that to help find and report bugs.
What Should You Learn From This?
Reporting bugs and missing features is good! Please keep doing it!
Not everyone who reports a bug or a missing feature is able to test that it’s been fixed or added, so if you see a PR come in and you want to test that it does what it says, feel free!
If you’re interested in doing this but aren’t in a position to compile development versions yourself, there are options!
As a side note, I tweeted the other day about the annual release cadence of Perl that I helped the project get into many years ago. It has tremendous benefits. Dogecoin Core might be a ways off from that regular cadence, but it’s possible we could get there.
We’ll get there sooner if you help, so keep reporting bugs, asking for features, testing out PRs, and testing out the development branches.
