[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-mac
Subject:    Re: Building RKWard on Mac (continued from private discussion)
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2017-06-08 20:53:45
Message-ID: 1768393.WA2SRTK9ng () bola
[Download RAW message or body]

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é


[prev in list] [next in list] [prev in thread] [next in thread]