Install presence

[René J.V. Bertin]

On Sunday June 20 2021 20:53:55 Jeremy Whiting wrote:

Hi,

>any/all of the above distributions) we need to fix that first. Maybe if the
>homebrew qt5 packages can be fixed the macports people will see it can be
>done and become more approachable.

What's in a word ...most people outside of the KDE sphere (i.e. probably the vast majority esp. on Mac and MSWin) will argue that Qt doesn't need fixing on this point. And it's true that a QSP "fix" wouldn't actually require that it works or can work with XDG paths. As a wise man *) once pointed out, you'd only need "fix" the writable locations. Then again, if you follow that minimal approach the build system and who knows how many source files would have to be updated so the target/query the appropriate platform-specific locations.
Either way, the HB people are likely to share the MacPorts standpoint that the Qt library they provide should be as little patched as possible, and/or should allow non-KDE applications to work without any changes. My own patched Qt version does allow that (mostly and definitely with respect to the QSP locations).

*) well, he did design the QSP class but I guess we can't hold that against him ;)

Which reminds me that I have been saying for a very long time that the build system should use a small binary to figure out what the standard locations are on the build platform (Qt's `qtpaths` should do fine but maybe not in cross-build scenarios?)

>quite some time myself. Barring that maybe the issues could be fixed
>upstream in Qt6 itself. I remember the efforts that went in to trying in
>Qt5, but times change, maybe it would be more approachable now. I'm not
>sure.

Well, that would definitely be a good reason to consider Qt6 (oh wait, it won't run on my Mac... :] )
But honestly, with Apple making the OS less and less accessible to people like us, do you really think the Qt guys are going to be more open to introduce what they'll see as a hack to support a running mode that could be moribund? One big reason to reject modifications has been that this could cause problems with Apple Mac/App store acceptation.

>All of the above is based on the idea that yes, we want KDE applications to
>work well on MacOS. I'm not sure if that's the consensus or not.

I certainly don't get the impression that it's something many KDE developers care about...

>(in the many variants) and MacOS. But I do find it overwhelming to start to
>figure out how each platform works and what needs to be done to make things
>work better on each platform.

You can't expect anyone to do that, much as it can be rewarding to get your code to run on as many platforms as you have access to (it's a great way to uncover latent bugs in my experience). Well, you could pay them for it, but who would remain interested for any amount of time?

>I tried putting the qml and sound files in
>resources at one point, thinking that would make it work better on MacOS,

Probably easier to stick them somewhere in the app bundle's Contents/Resources if you go that route.


On Monday June 21 2021 17:18:23 Ian Wadham wrote:

>> It's also not very dependent on other libraries/systems to work. I don't think it uses kparts or kio or anything like that.
>
>Here’s the rub. Although I worked as a KDE developer for 14 years and tried many times to find out what “kparts” and “kio” are and what they actually do, but was never able to find out (i.e.no definitive documentation).

I know enough of what they are and do myself, but I have little idea how they do it and what's required for them to work. AFAICT, kparts are not an issue (mostly at least) but kio can be a nightmare on Linux too if for some reason it doesn't work, e.g.

"There was an error loading the module WebEngine.
The diagnostics is:
Cannot load library /opt/local/share/qt5/plugins/kf5/parts/webenginepart.so: (/usr/lib/x86_64-linux-gnu/libtdb.so.1: version `TDB_1.3.17' not found (required by /opt/local/lib/libsmbconf.so.0))"

and 

"Could not open library '/opt/local/share/qt5/plugins/kf5/kio/smb.so'.
Cannot load library /opt/local/share/qt5/plugins/kf5/kio/smb.so: (/usr/lib/x86_64-linux-gnu/libtdb.so.1: version `TDB_1.3.17' not found (required by /opt/local/lib/libsmbconf.so.0))
kf5.kio.core: couldn't create slave: "klauncher said: Error loading '/opt/local/share/qt5/plugins/kf5/kio/smb.so'."
"

This is because I have samba4 installed under /opt/local but (evidently) kept the older system version. Applications that link to samba directly work without issues because I build with the appropriate rpath settings, but it's as if something in kded or kdeinit or kio drops that information, and I have no idea how to figure out how or why. I don't even try to begin to start tinkering on Mac (like when konqueror wouldn't find or load the html kioslave).
Sometimes I can fix thatby setting `LD_PRELOAD=/opt/local/lib/samba/libtdb.so.1` before I launch kded5 via kdeinit5