[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.
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
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.
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
More information about the kde-mac