Building RKWard on Mac (continued from private discussion)

[Thomas Friedrichsmeier]

Hi,

The whole KDE-Mac thing is apparently still very confidential,
given the lack of activity on the mailing list.

Perhaps we should continue our discussion, there, then?

We could start CC'ing the list, but realise that lack of activity
also may mean lack of people reading the messages...

I believe we're all on the list, already. So let's apply some
calculated optimism, and assume that seeing others talk about KDE on
Mac might remind other application maintainers of the existence of Macs
as well.

Also note that KDE on Windows has recently made some _really_ good
progress in making it easy and fast to set up a KF5-Windows development
environment. Maybe that will help create some momentum for
cross-platform KDE in general.

On Wed, 07 Jun 2017 21:01:58 +0200

Ok, I now have a running kf5-rkward-devel port, with only minimal

Good news! :)

additional tinkering (setting the git branch to
work/frameworks-Mac,

Why, given that the port's git.branch is set to a commit in that
branch?

Because I needed some commits later on that branch.
https://cgit.kde.org/rkward.git/log/?h=work/frameworks-Mac

I'm still missing all icons to be loaded from the theme.

That's curious, supposing you installed port:qt5-kde that should
work. Unless you didn't install any icon themes, maybe? Note that I'm
not really certain what theme would be selected if you don't specify
%> sudo port install Ciment-icons +OSXdg+kf5
(that should also install kf5-oxygen-icons5 and the hicolor theme)

For the record, I already had kf5-breeze-icons installed. Adding this
did not change anything.
kiconfinder5 edit-find
returns nothing.

Any environment variables involved or some such?

Interestingly,
_without_ any failure message, so somehow, a valid nothing appears
to get loaded.

Yes, icon-from-theme lookups fail silently and just return an empty
icon.

Hm, not very useful, if you ask me, but I suppose that's Qt's fault?

I tried installing kf5-osx-integration-devel, thinking this
might be the missing ingredient, but that fails to build.

Ah? That shouldn't happen, I'd be interested in a logfile (preferably
made with build.jobs=1). I build the code regularly myself, though
not usually from scratch, and always with the +menukey variant.

Pretty trivial git failure, it would seem:
https://paste.kde.org/ph9eiipvq

Ok, please check
https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Mac

Will do ASAP.

For qt5-kde I see your point. BTW, is qt5-kde expected to break
something that works with qt5, ATM,

No, qt5-kde is supposed to be a drop-in replacement for the
"official" Qt5 ports, with the usual caveats when it provides a newer
Qt version as it currently does. Going back to the Qt5 ports is less
trivial and probably requires rebuilding. But anything that breaks
would be a bug.

i.e. would this continue to be a
separate variant/sub-port? Or would the plan be to _replace_ qt5,
eventually?

No. We have a 2-captains-on-a-ship situation there, 2 highly complex
ports with different approaches that can also not be merged into a
single port. The only hope here would be upstreaming the most crucial
patches into Qt, but frankly I don't really see that happening
anymore.

I have no actual idea on the technicalities, but somehow I fail to
imagine what technical issues could totally prevent the ports to be
merged. Is this more of an "I don't believe your patches are
needed"-kind of problem?

Just asking, because having two mutually exclusive qt5 ports does not
seem like a terribly elegant solution to me, in the long run...

Regards
Thomas

[René J.V. Bertin]

On Thursday June 08 2017 10:13:35 Thomas Friedrichsmeier wrote:

Hi,

Post by Thomas Friedrichsmeier
environment. Maybe that will help create some momentum for
cross-platform KDE in general.

Let's hope so! In my experience the cross-platform nature is still a bit (too much) considered as a mostly unintentional side-effect of using Qt...

Post by Thomas Friedrichsmeier
Because I needed some commits later on that branch.
https://cgit.kde.org/rkward.git/log/?h=work/frameworks-Mac

Ah, of course, if I'm no longer the only one committing to that branch... :)

Post by Thomas Friedrichsmeier
Sigh. clang considers Mac to be case-insensitive, and so will consider
rinterface.h the same as Rinterface.h.
Further clang and cmake (don't know which is to blame) think it's fun to
look
for <include.h> in the local dirs, first, then in the system path. Thus,

The first bit is probably a result of you using a case-insensitive filesystem? That, combined with the generally bad idea of distinguishing filenames by their case only can lead to very annoying build issues.
Without a precise log I cannot say exactly what happens, but one has to consider that
1) the underlying system calls like [f]open() will wrap case when opening a file on a case-insensitive HFS filesystem, so it'll open /path/to/foo even if you asked for /paTH/To/fOo. Filename matching will still be case-sensitive though, so depending on how headerfiles are located you'll get failure or the wrong file if case has been changed at some point.
2) directory name case will reflect the case used during the last time the directory was (re)created. IOW, when unpacking a archive containing /path/to/foo.h and /path/To/Foo you will end up with files Foo and foo.h in a directory called either "To" or "to" depending on which was unpacked last (or rather the order in which the unarchiver did the `mkdir -p` to ensure the target directories exist).

The other issue sounds like a cmake issue interacting with the case issue. CMake is powerful, but in the KF5 buildsystem it generates command lines that I think are getting (way) too long and complex.

Post by Thomas Friedrichsmeier
For the record, I already had kf5-breeze-icons installed. Adding this
did not change anything.
kiconfinder5 edit-find
returns nothing.

Just installing Breeze won't do anything of course when another theme is the default, and until now I've avoided adding Breeze to the default theme inheritance as it looks more out of place on Mac than Oxygen.

But I misinformed you. Qt5-kde did indeed set the icon path with an earlier version of the "QSP patch" that was activated at runtime. I removed that patch when the QSP patch was modified to be activated at build time (there were good reasons for that): when you add an icon theme search path, even "pure Qt" applications using the native Mac style get icons on buttons all of a sudden. I find that acceptable as a side-effect from installing port:kf5-osx-integration but not as a general effect.

Could you try `env QT_QPA_PLATFORMTHEME=kde kiconfinder5 edit-find`? You may have to create a ~/.config/kdeglobals file with the appropriate variables set to make that work.

Post by Thomas Friedrichsmeier

Yes, icon-from-theme lookups fail silently and just return an empty
icon.

Hm, not very useful, if you ask me, but I suppose that's Qt's fault?

What else would you have it do? You can specify the fallback result as a 2nd argument to the lookup method.

Post by Thomas Friedrichsmeier
https://paste.kde.org/ph9eiipvq

AAAARGHHH, completely forgot to update the URL after the project was moved...
Better late than never I guess :)

Post by Thomas Friedrichsmeier
I have no actual idea on the technicalities, but somehow I fail to
imagine what technical issues could totally prevent the ports to be
merged.

It's not feasible. mcalhoun's qt5 ports are organised as subports for each Qt component, while my port installs the equivalent of Qt 5.3 minus QtWebkit as a single subport, with QtWebkit, QtWebEngine and its derivatives as subports and stubs for all the other subports. Then, we don't use the same installation layout; mine follows how things are installed in a standard Unix install while mcalhoun puts all into a $prefix/libexec/qt5 (which I only use for the binary stuff that could conflict with Qt4).

Of course the ports could be merged, but we'd end up with a Portfile containing 2 huge sections. That's too cumbersome and risky. As I said, 2 captains on a ship, and one of them (me) doesn't even have commit rights.

Post by Thomas Friedrichsmeier
Is this more of an "I don't believe your patches are
needed"-kind of problem?

No, though there is a "you've made too many changes and I just don't want to spend time testing them all and I don't trust your testing". The qt5 maintainer is of the type who goes MIA from time to time, and then all of a sudden starts changing things. Over 2 years ago I set out doing the necessary work to make the Qt4 and Qt5 ports co-installable with minimal changes because neither of their maintainers had the time (or was MIA, see above...). Evidently my versions evolved because I couldn't commit the concurrency changes and then at some point, months later, mcalhoun woke up, first took my changes to push a messed-up version (IIRC) and then just put everything in its own prefix. I still regret not having pushed for a maintainership transfer when he was MIA, that would have made things a lot easier for us.

Post by Thomas Friedrichsmeier
Just asking, because having two mutually exclusive qt5 ports does not
seem like a terribly elegant solution to me, in the long run...

Nope, but there could be some justification in the idea of having a mostly stock version that also installs more like how Qt's own installer installs things, and a port that installs a "linuxified" version. I'm also not disappointed that I don't get to do the maintenance of the Qt 5.6 LTS port and legacy ports for older OS X versions (beyond the "hidden" legacy variant installing Qt 5.3.2 on 10.6, and apparently the patching required to build the upcoming Qt 5.9 on OS X 10.9).

Cheers,
René

[Thomas Friedrichsmeier]

Hi,

On Thu, 08 Jun 2017 12:10:43 +0200
René J.V. Bertin <***@gmail.com> wrote:
[...]

Post by René J.V. Bertin

Post by Thomas Friedrichsmeier
Sigh. clang considers Mac to be case-insensitive, and so will consider
rinterface.h the same as Rinterface.h.
Further clang and cmake (don't know which is to blame) think
it's fun to look
for <include.h> in the local dirs, first, then in the system path. Thus,

The first bit is probably a result of you using a case-insensitive
filesystem? That, combined with the generally bad idea of
distinguishing filenames by their case only can lead to very annoying
build issues. Without a precise log I cannot say exactly what
happens, but one has to consider that 1) the underlying system calls
like [f]open() will wrap case when opening a file on a
case-insensitive HFS filesystem, so it'll open /path/to/foo even if
you asked for /paTH/To/fOo. Filename matching will still be
case-sensitive though, so depending on how headerfiles are located
you'll get failure or the wrong file if case has been changed at some
point. 2) directory name case will reflect the case used during the
last time the directory was (re)created. IOW, when unpacking a
archive containing /path/to/foo.h and /path/To/Foo you will end up
with files Foo and foo.h in a directory called either "To" or "to"
depending on which was unpacked last (or rather the order in which
the unarchiver did the `mkdir -p` to ensure the target directories
exist).
The other issue sounds like a cmake issue interacting with the case
issue. CMake is powerful, but in the KF5 buildsystem it generates
command lines that I think are getting (way) too long and complex.

Yes, it's the combination that broke our back, here. Having a header
named "rinterface.h", when also linking against a library that has
"Rinterface.h" has never been a terribly good idea, but not an issue -
not even on Windows - as long as we could rely on "#include <>" looking
in the system path, first (which AFAIU gcc does, but not clang).

Post by René J.V. Bertin

Post by Thomas Friedrichsmeier
For the record, I already had kf5-breeze-icons installed. Adding
this did not change anything.
kiconfinder5 edit-find
returns nothing.

Just installing Breeze won't do anything of course when another theme
is the default, and until now I've avoided adding Breeze to the
default theme inheritance as it looks more out of place on Mac than
Oxygen.
But I misinformed you. Qt5-kde did indeed set the icon path with an
earlier version of the "QSP patch" that was activated at runtime. I
removed that patch when the QSP patch was modified to be activated at
build time (there were good reasons for that): when you add an icon
theme search path, even "pure Qt" applications using the native Mac
style get icons on buttons all of a sudden. I find that acceptable as
a side-effect from installing port:kf5-osx-integration but not as a
general effect.
Could you try `env QT_QPA_PLATFORMTHEME=kde kiconfinder5 edit-find`?
You may have to create a ~/.config/kdeglobals file with the
appropriate variables set to make that work.

Ok, for some reason kiconfinder5 still doesn't find anything (or
doesn't produce any output to the terminal), but starting rkward with
than environment variable does the trick, indeed. Hooray!

(Oh, or maybe not hooray. I just noted that this will also attach the
menubar to the main window, and probably other things that look alien
on Mac).

I must admit I did not quite understand what this means in terms of a
"real" solution. Do I install / depend on kf5-osx-integration, set the
environment variable, or add theme search paths in the code?

Post by René J.V. Bertin

Post by Thomas Friedrichsmeier

Yes, icon-from-theme lookups fail silently and just return an
empty icon.

Hm, not very useful, if you ask me, but I suppose that's Qt's fault?

What else would you have it do? You can specify the fallback result
as a 2nd argument to the lookup method.

I would have expected to get a null QIcon(), i.e.
QIcon::fromTheme("nah-thats-wrong").isNull() == true

Post by René J.V. Bertin

Post by Thomas Friedrichsmeier
I have no actual idea on the technicalities, but somehow I fail to
imagine what technical issues could totally prevent the ports to be
merged.

It's not feasible.

[...]

Hm, ok, thanks for the explanation.

Regards
Thomas

[René J.V. Bertin]

On Thursday June 08 2017 15:01:55 Thomas Friedrichsmeier wrote:

Hi,

Post by Thomas Friedrichsmeier
(Oh, or maybe not hooray. I just noted that this will also attach the
menubar to the main window, and probably other things that look alien
on Mac).

That's to be expected when you use Qt's built-in KDE theme (which is only available with qt5-kde). It means you're not getting platform integration features, including the menubar.

Post by Thomas Friedrichsmeier
I must admit I did not quite understand what this means in terms of a
"real" solution. Do I install / depend on kf5-osx-integration, set the
environment variable, or add theme search paths in the code?

The easiest thing to ensure icon support would be to add $prefix/share/icons to the icon theme search path explicitly when you start the UI, at an appropriate and sufficiently early location. I would of course advise to install the osx-integration package, because with that you also get full colour palette and font role support. Esp. the latter should make the application look a bit better because you no longer get the fallback to the standard 13pt Lucida Grande system font.

Post by Thomas Friedrichsmeier
I would have expected to get a null QIcon(), i.e.
QIcon::fromTheme("nah-thats-wrong").isNull() == true

Isn't that the same as an empty icon, in practice?

Post by Thomas Friedrichsmeier
I don't get to see the issue (probably it's a race condition), so

Do you get rbackend showing up as a generic non-GUI application (terminal icon) with a very curious menubar when you activate it?

Post by Thomas Friedrichsmeier
could you try: The best place might be rbackend/rkrinterface.cpp lines
327-342. The main window widget can be obtained using
RKWardMainWindow::getMain().

Doing that from the backend wouldn't work on Mac, the only thing that's currently supported is activating the entire application from with the application itself.

Anyway, I just remembered I still had a .Rprofile lying around that did some probably naughty things tailored for R 2.1 or so at the latest. Removing that file solved the issue.

R.

[Thomas Friedrichsmeier]

On Thu, 08 Jun 2017 15:58:23 +0200

Post by René J.V. Bertin
The easiest thing to ensure icon support would be to add
$prefix/share/icons to the icon theme search path explicitly when you
start the UI, at an appropriate and sufficiently early location.

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

Which of course adds a rat-tail of problems, such as supporting primary,
and fallback themes, user preferred themes, etc.. At least if you're
looking for more than the quick-and-dirty.

Post by René J.V. Bertin
I
would of course advise to install the osx-integration package,
because with that you also get full colour palette and font role
support. Esp. the latter should make the application look a bit
better because you no longer get the fallback to the standard 13pt
Lucida Grande system font.

Ok, disregarding the fonts and all, and focusing on the icons, only:
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?

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?

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?

Post by René J.V. Bertin

Post by Thomas Friedrichsmeier
I would have expected to get a null QIcon(), i.e.
QIcon::fromTheme("nah-thats-wrong").isNull() == true

Isn't that the same as an empty icon, in practice?

In use, yes, but it would make it easier to diagnose the error
condition. Essentially isNull() vs isEmpty().

Post by René J.V. Bertin

Post by Thomas Friedrichsmeier
I don't get to see the issue (probably it's a race condition), so

Do you get rbackend showing up as a generic non-GUI application
(terminal icon) with a very curious menubar when you activate it?

Umm, no? OSX 10.9, here.

Post by René J.V. Bertin

Post by Thomas Friedrichsmeier
could you try: The best place might be rbackend/rkrinterface.cpp
lines 327-342. The main window widget can be obtained using
RKWardMainWindow::getMain().

Doing that from the backend wouldn't work on Mac, the only thing
that's currently supported is activating the entire application from
with the application itself.

That's still in the frontend process. Just the backend as seen by the
frontend, so to speak. The directory layout may not be all that
helpful, indeed, but part of the problem is that backend and frontend
processes share some of the same code (think of it as the protocol), so
it's not trivial to come up with a clear layout.

Post by René J.V. Bertin
Anyway, I just remembered I still had a .Rprofile lying around that
did some probably naughty things tailored for R 2.1 or so at the
latest. Removing that file solved the issue.

Ok.

Regards
Thomas

[René J.V. Bertin]

On Thursday June 08 2017 10:13:35 Thomas Friedrichsmeier wrote:

Hi

Post by Thomas Friedrichsmeier
Because I needed some commits later on that branch.
https://cgit.kde.org/rkward.git/log/?h=work/frameworks-Mac

We should find the right place to make the frontend activate itself after starting up. Right now the user must click on it because something during the startup process steals focus. I suspect the rbackend (which doesn't behave entirely like an "agent" should, probably because R attempts to give it a UI).

R.

[Thomas Friedrichsmeier]

On Thu, 08 Jun 2017 12:37:27 +0200

Post by René J.V. Bertin

Post by Thomas Friedrichsmeier
Because I needed some commits later on that branch.
https://cgit.kde.org/rkward.git/log/?h=work/frameworks-Mac

We should find the right place to make the frontend activate itself
after starting up. Right now the user must click on it because
something during the startup process steals focus. I suspect the
rbackend (which doesn't behave entirely like an "agent" should,
probably because R attempts to give it a UI).

I don't get to see the issue (probably it's a race condition), so
could you try: The best place might be rbackend/rkrinterface.cpp lines
327-342. The main window widget can be obtained using
RKWardMainWindow::getMain().

Regards
Thomas

[René J.V. Bertin]

Ok, please check
https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Mac

Some quick remarks:
- theme icons aren't in fact the most crucial reason for patching Qt. As you've learned by now, the qt5-kde patches do not in fact enable theme lookups. There are also other patches to improve the KDE experience, among which a patch to prevents Qt from guessing which menu actions can be moved and put under the "About" and "Preferences" menu items in the Application menu. Their text-based heuristics (guessing from the action name) can give surprising results with more complex applications.

- the only reason you might want to associate my ports tree with a non-default prefix is if indeed you wish to run official Qt5 ports from MacPorts using the official port:qt5-* ports. The main drawback with that is that you will have to build *everything* from source in the KF5 prefix. I also think it's confusing to end up with 2 different Qt5 versions, and one MacPorts install in which you have to jump through certain steps periodically in order to ensure that the Qt5 PortGroup files are correctly installed in the 2 required locations. You also have to be certain to use the appropriate `port` command every time.

qt5-kde is designed to be (and "somewhat tested") a drop-in replacement for qt5-qtbase c.s. Once you install it all ports depending on Qt5 change their "depspecs" and will thus not attempt to install a wrong Qt5 port in addition to what you already have. Despite being a drop-in replacement you'll still rebuilding the Qt5 ports from source, though. That's hopefully not more than a precaution, but a necessary one if I want to get my ports accepted.

- please point the user to the more exhaustive instructions for adding a personal ports tree in the MacStrop repo. You missed the fact that the line has to be prepended to the list of sources, not appended!

- you could add the remark that just about all KF5 ports have a +docs variant which installs the documentation (handbook and/or apidocs). An overview of the variants a given port has can be obtained with `port variants foo`. This prints the description provided by the port author, as well as conflict indications. It can also be useful sometimes to verify a port's notes before installing it (`port notes foo`). These remarks apply in particular to a port like kf5-osx-integration-devel .

- In theory doing something wild like `port install kf5-kate` should pull in all dependencies; in practice this hasn't been tested very often. It might be a good idea to install port:qt5-kde first; that will exclude all possibility that you end up installing port:qt5-qtbase c.s. through some weird dependency cascade.

- a good way to get most common frameworks installed is `port install kf5-frameworkintegration`. This will also pull in kf5-osx-integration-devel (default install variant).

- why do you need port:coreutils with the other MacPorts-based approach?

That's all for now,

Cheers,
René

[Thomas Friedrichsmeier]

Hi René,

thanks for taking a look. I've tried to incorporate your remarks as
far as I understood them.

On Thu, 08 Jun 2017 17:40:37 +0200
René J.V. Bertin <***@gmail.com> wrote:
[...]

Post by René J.V. Bertin
qt5-kde is designed to be (and "somewhat tested") a drop-in
replacement for qt5-qtbase c.s. Once you install it all ports
depending on Qt5 change their "depspecs" and will thus not attempt to
install a wrong Qt5 port in addition to what you already have.
Despite being a drop-in replacement you'll still rebuilding the Qt5
ports from source, though. That's hopefully not more than a
precaution, but a necessary one if I want to get my ports accepted.

Ah, good to know, indeed (but not something to detail in the Wiki, I
think).

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

Post by René J.V. Bertin
- why do you need port:coreutils with the other MacPorts-based
approach?

Craft needs "realpath". Or something similar. Don't press me on the
details, but I actually tried without coreutils, myself, before adding
this bit.

Regards
Thomas

[René J.V. Bertin]

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

Hi,

Post by Thomas Friedrichsmeier
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.

Post by Thomas Friedrichsmeier
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.

Post by Thomas Friedrichsmeier
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.

Post by Thomas Friedrichsmeier
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.

Post by Thomas Friedrichsmeier
I wonder: Would it be feasible to create something (a framework?) where
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.

Post by Thomas Friedrichsmeier
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.

Post by Thomas Friedrichsmeier
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.

Post by Thomas Friedrichsmeier
_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é

[René J.V. Bertin]

Post by René J.V. Bertin
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.

Done :)

R

[Thomas Friedrichsmeier]

On Thu, 08 Jun 2017 22:53:45 +0200

Post by René J.V. Bertin
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.

Ah, that's the part I had been missing. So, without that wrapper (or
manual user config), kf5-osx-integration simply does nothing, right?
And you're already adding the wrapper for all KF5-ports.

Then, why not just make all ports of kf5 applications depend on it, and
get sane behavior out of the box, without pushing the responsiblity to
read up on all this to the user?

Sure, I suppose a select few KF5-applications may want to play
different on Mac, but then _those_ would be special cased, while all
others will "just work".

Regards
Thomas

[René J.V. Bertin]

Post by Thomas Friedrichsmeier
On Thu, 08 Jun 2017 22:53:45 +0200

Post by René J.V. Bertin
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.

Ah, that's the part I had been missing. So, without that wrapper (or
manual user config), kf5-osx-integration simply does nothing, right?

Yes and no. First, you can set the env. variable(s) globally, even such that they apply to applications launched via the Finder. Then you don't need wrappers anymore. But yes, without them the platform theme plugin from kf5-osx-integration will not be loaded unless you build it to override the standard Cocoa plugin.

Also, with the latest changes I pushed to the repo it shouldn't have any noticeable effect on "pure Qt" ports as long as you don't have a kdeglobals file that redefines things.

Post by Thomas Friedrichsmeier
And you're already adding the wrapper for all KF5-ports.

True, but only for starting them from the commandline.

Post by Thomas Friedrichsmeier
Then, why not just make all ports of kf5 applications depend on it, and
get sane behavior out of the box, without pushing the responsiblity to
read up on all this to the user?

I find it's still a bit early for that without having more feedback from the field.
The problem is also that both the Applications and Plasma categories contain applications and libraries. Setting a platform theme plugin as a dependency for a library feels a bit unelegant, and I don't really want to have to remember declaring it manually either :)

Post by Thomas Friedrichsmeier
Sure, I suppose a select few KF5-applications may want to play
different on Mac, but then _those_ would be special cased, while all

What do you have in mind?

[Thomas Friedrichsmeier]

On Fri, 09 Jun 2017 09:49:44 +0200

Post by René J.V. Bertin

Post by Thomas Friedrichsmeier
And you're already adding the wrapper for all KF5-ports.

True, but only for starting them from the commandline.

Yeah, that's another thing I might quizz you about, later. I'll
certainly want RKWard to load its icons regardless of how it was
started...

Post by René J.V. Bertin

Post by Thomas Friedrichsmeier
Then, why not just make all ports of kf5 applications depend on it,
and get sane behavior out of the box, without pushing the
responsiblity to read up on all this to the user?

I find it's still a bit early for that without having more feedback
from the field. The problem is also that both the Applications and
Plasma categories contain applications and libraries. Setting a
platform theme plugin as a dependency for a library feels a bit
unelegant, and I don't really want to have to remember declaring it
manually either :)

I can see there are corner cases. But it's fairly important: I don't
think there is any KF5-application that is better off without any
icons. And in fact, both as an application maintainer and as a user,
that's definitely something I would expect packaging to take care of.

If that means adding an unnecessary dependency to a few
libraries/subports, I would consider that the lesser evil. (Also keep
in mind, that at least for the time being, the primary dependents of
frameworks libraries are KDE applications, anyway).

Post by René J.V. Bertin

Post by Thomas Friedrichsmeier
Sure, I suppose a select few KF5-applications may want to play
different on Mac, but then _those_ would be special cased, while all

What do you have in mind?

I'm absolutely not up to speed on MacPorts but could you make it such
that any port that has kf5.add_app_wrapper in it will also get a
dependency on kf5-osx-integration. Then only in those -
hypothetical?(*) - cases, where this is not desired, you'd add

depends_lib-delete port:kf5-osx-integration

or something.

Regards
Thomas

(*) Are you aware of any applications among your kf5 ports which would
_not_ want kf5-osx-integration?

[René J.V. Bertin]

Post by Thomas Friedrichsmeier
I can see there are corner cases. But it's fairly important: I don't
think there is any KF5-application that is better off without any
icons. And in fact, both as an application maintainer and as a user,
that's definitely something I would expect packaging to take care of.

You certainly have a point.

Post by Thomas Friedrichsmeier
I'm absolutely not up to speed on MacPorts but could you make it such
that any port that has kf5.add_app_wrapper in it will also get a

That's actually a clever thought. The problem is that that macro is currently intended to be called in the "post-destroot".
That means I'd have to rewrite it, and modify all ports to call it from the toplevel.
I'll have to test that.

Post by Thomas Friedrichsmeier
(*) Are you aware of any applications among your kf5 ports which would
_not_ want kf5-osx-integration?

No. In fact it's quite important to me that it works with any Qt port because it allows me to use my fonts and hand-tuned QtCurve theme across the board.

R.

[Thomas Friedrichsmeier]

Sorry to bombard you with questions, but one more:

On Thu, 08 Jun 2017 17:40:37 +0200

Post by René J.V. Bertin
qt5-kde is designed to be (and "somewhat tested") a drop-in
replacement for qt5-qtbase c.s. Once you install it all ports
depending on Qt5 change their "depspecs" and will thus not attempt to
install a wrong Qt5 port in addition to what you already have.
Despite being a drop-in replacement you'll still rebuilding the Qt5
ports from source, though. That's hopefully not more than a
precaution, but a necessary one if I want to get my ports accepted.

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? And they would automatically profit from switching to
qt5-kde, at some later point?

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

(Note that any really detailed answer may be lost on me, so no need to
elaborate. Just testing your defenses, so to speak...)

Regards
Thomas