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

Nicolás Alvarez nicolas.alvarez at gmail.com
Wed Sep 23 03:06:39 UTC 2015


2015-09-22 19:28 GMT-03:00 Albert Astals Cid <aacid at kde.org>:
> El Dimarts, 22 de setembre de 2015, a les 23:04:22, René J.V. Bertin va
> escriure:
>> 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)

I agree that we should support self-contained .app bundles for our
applications, and maybe even AppStore-requirement-compatible bundles,
but we're currently far from being able to do that. If there is no
place to put binaries shared between all our apps, which app would
ship the kioslaves, kded5, etc? How would we ship dbus? How can apps
talk to each other via dbus if each app starts its own daemon?

-- 
Nicolás


More information about the Kde-frameworks-devel mailing list