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

List:       kde-mac
Subject:    Re: Install presence
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2021-06-21 11:04:16
Message-ID: 3311416.O2KdjdJdb8 () bola
[Download RAW message or body]

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


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