kf5-systemsettings: Not built for high DPI

[Tatsh]

Applies to only macOS.

I think this may apply to a lot of kf5-* apps, but Quassel is built with high DPI support. It is possible to patch after compilation in the Info.plist by adding an entry:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <!-- ... -->
    <key>NSHighResolutionCapable</key>
    <true/>
</dict>
</plist>

This is not a full fix as far as I know as I think KDE/Qt packages have various options to enable this properly. In the case that there is no support, I would support patching the Info.plist.in (or equivalent) during the patch{} phase.

[RJVB]

Around here we only do camelCase for variables and functions; the operating system is referred to as the Mac OS ;)

This is not a full fix as far as I know as I think KDE/Qt packages have various options to enable this properly. In the case that there is no support, I would support patching the Info.plist.in (or equivalent) during the patch{} phase.

IIRC there's a Qt function to enable the support in software. I've never looked at exactly what it does but it might set the plist entry in software, like how I set the LSUIElement entry for applications that don't have a plist (= non bundled).

The problem is that the majority of applications get an Info.plist that is generated automagically by Qt or CMake, so I can only patch it in the post-destroot. That's something for which the MacPorts base layer should provide a feature. Not a patch but some code that can insert and XML snippet into a random XML plist.

The applications from my ports tree aren't the only ones concerned by this request. If I understand correctly, Quassel is an example. I also think you installed my version of the port in its default configuration (no +kde or +qtwebkit variants) which means you got exactly the same build as you would have gotten from the mainstream port. I don't have one of these screens myself so I feel a bit awkward asking for support for a mode that won't benefit me, would you mind filing an issue about this on trac.macports.org or else on the macports-devel ML?

I'll try to grab the binary pre-built Quassel package for 10.13 or 10.14 later today and see if anything has changed with a more recent Qt version.

[RJVB]

Reading the Qt documentation for "High DPI Displays" I see that

Newer versions of qmake will generate Info.plist's with the NSPrincipalClass key, which is sufficient since NSHighResolutionCapable is true by default.

Sadly they don't mention from which version onwards but I see the key in a template plist in the various Mac-specific qmake/mkspec resources. You can also experiment by setting the QT_AUTO_SCREEN_SCALE_FACTOR env. variable (I assume you know how to use these on Mac).

I also see that quassel comes with its own plist template which contains the hi-res key...

[RJVB]

I pushed a cmake upgrade which hopefully will enable high-dpi support in applications that do not provide their own Info.plist . Can you check please?

[Tatsh]

This works.