Building RKWard on Mac (continued from private discussion)

[René J.V. Bertin]

On Thursday June 08 2017 20:37:58 Thomas Friedrichsmeier wrote:

Hi,


>However, suppose I already have qt5 and a bunch of dependent ports
>installed: What would be the best way to switch to qt5-kde?

That'd be a little bit tricky. It would be something like
%> sudo port deactivate -f "qt5-qt*"
%> sudo port install qt5-kde [and possible qt5-kde-qtwebkit, qt5-kde-qtwebengine, qt5-kde-assistant]

Then you can do
%> sudo port -v rev-upgrade

to check for missing or broken dependencies.


>For the record: You'll also have to specify a theme name to use.
>QIcon::setSearchPaths() and QIcon::themeName().

Evidently, yes. But the latter is something you could decide to do yourself everywhere, in order to provide a consistent look ;)

There are other applications that just impose a fixed icon (or widget) theme, regardless of what the user configured in kdeglobals.

>Sweet. So that works without adjustments to the code. _But_ can I just
>depend on this, then? Or won't this interfere with pure Qt apps, once
>again?

It will do exactly the same kind of thing the plasma-integration plugin does on Linux: all Qt applications get the same treatment. As long as the user doesn't install a personalised kdeglobals file the effects will be minimal, probably only the appearance of some icons in certain buttons. I've tailored the built-in default to match the platform defaults as closely as possible. Sadly there is nothing I can do about the icon isssue.

Wait, actually there is. The osx-integration package now includes tweaked Cocoa QPA and Macintosh style plugins, so I *should* be able to make the style respect the ButtonsHaveIcons attribute.

Also: in its default configuration the plugin is loaded only when KDE_SESSION_VERSION=5 in the environment, or when it is requested explicitly via the aforementioned QT_QPA...=kde trick. As long as those aren't set, the plugin won't be loaded. This is one reason why my KF5 ports all install wrapper scripts in /opt/local/bin, but you can also replace the bundle exec with a script that sets the appropriate env. variables before calling the actual executable.

>For our binary standalone package, we won't care. But for playing
>nice with MacPorts I'll have to go the search paths + theme name route
>outlined above, in addition, right?

port:kf5-rkward doesn't depend on kf5-frameworkintegration so doesn't impose the installation of kf5-osx-integration ;)
So yeah, you could check if an icon theme search path and an icon theme name have been set, and set them if they haven't.

>I wonder: Would it be feasible to create something (a framework?) where
>I can simply write:
>  MagiKPlatform::doAllThatPlatformSpecificStuffToGetSaneKDEBehavior();
>and be done with? Including all fonts, icons, dbus, whatever comes up
>now or in the future?

That sounds like a "single KF5 framework or class that is called be each and every application at startup", which is a no-go in KF5 dogma. You could write a class that does a number of those initialisations, and call it early enough. It won't be the same as a platform theme plugin though, which is initialised before main() is called, and which can also do things you cannot do in a normal application (to my knowledge). The font roles for instance can only be handled in a platform integration plugin.

>In turning this around, does that mean that all kf5 ports (currently in
>your personal tree, only), could be expected to "mostly" work with
>non-patched qt5?

Yes, with the same issues you have seen: they won't be able to find any runtime resource via QSP because they'll be pointed to native locations which are not where the build system installs said resources.

>And they would automatically profit from switching to
>qt5-kde, at some later point?

No, sadly, at least not for the major qt5-kde different. Remember that the QSP patch is activated when you compile code. This is the only way you can load say a KF5-based plugin into a "pure Qt" application like Qt Designer, and use the XDG-compliant QSP locations in the KF5 code but the native locations in the pure Qt app.
So you'd have to rebuild all KF5 code.

>_If_ so, wouldn't it also be useful to try getting the kf5 ports into
>MacPorts, independent of qt5-kde?

That could be useful as a means to put some pressure on getting qt5-kde in, but it could also turn out to be counterproductive.

Cheers,
René