[KDE/Mac] [OS X] adding a link module to all KF5 targets

Albert Astals Cid aacid at kde.org
Tue Sep 22 22:28:10 UTC 2015

El Dimarts, 22 de setembre de 2015, a les 23:04:22, René J.V. Bertin va 
> On Tuesday September 22 2015 22:35:40 Albert Astals Cid wrote:
> > Shouldn't KF5 work with those sandboxing? I'd expect that KF5 goal is that
> > you can use it in applications that end up in the App Store.
> It might be possible that someone will someday write an application that
> uses (a) KF5 framework(s) and that might be suitable for the App Store if
> it conforms to all the rules. I strongly doubt that current KDE/KF5
> applications (Kate, KDevelop, KDE PIM apps, you name it) will be able to
> conform, with all the interdependencies on helpers, agents and what not.
> The only way I can see to comply with those rules is if each application
> has the full set of its link and runtime dependencies installed in a prefix
> somewhere in the app bundle (using relative paths because app bundles are
> supposed to work regardless of their install location). If someone wants to
> jump through all those hoops (and pay Apple 99$/year plus 30% of sales)
> that's fine and I'm not proposing anything that would make it impossible
> (just a non-default option). But it shouldn't be compulsory for everyone.

Why not?

As far as i know it's how mac apps work, you download a bundle and it has 
everything in it, anything else than that is not a "real mac app" (i've used 
macs for like 2 months of my life so i may be wrong :D)

> In any case, I already pointed out that I strongly believe we should first
> try to get KF5 (frameworks + applications) to work with an installation
> layout that is as close as possible to the one used on the main development
> platform. I don't know why exactly applications like Kate crash on OS X
> currently, but not so long ago the issue was clearly that applications
> couldn't find stuff they needed, in other words, the unexpected and
> incomptable locations returned by QStandardPaths. I'm not going to claim
> that all issues will miraculously disappear when using XDG-style locations,
> but at least we'll have removed one source of error (of unknown
> complexity). Support for Apple-style QSP locations is a step that has to be
> taken when everything else works as it should.

I'm not saying that a linux-like installation layout should be banned for KF5 
on Mac, but i think it should be non default, and the bundle solution should 
be default.

Asking linux-like installation layout on Mac because it's what we use on Linux 
is similar to suggesting KF5 on Mac should use X11 because it's what we use on 
the Linux, and I hope we agree it's not a good idea.

Again from my "I've used Mac OS X for like 2 months in my life" point of view, 
I think "KDE Frameworks" on Mac OS X should default to work on a bundle-like 
environment, if "KDE Applications" are not ready for it, adding a workaround 
at the application level may an acceptable way to bootstrap the applications 
running, but I don't think it should be the end goal.


> R
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

More information about the kde-mac mailing list