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. 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. R _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
