On Wed, 23 Sep 2015, Nicolás Alvarez wrote:
2015-09-22 19:28 GMT-03:00 Albert Astals Cid <aa...@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?
Well, that's simple. As on Windows, applications on OSX shouldn't use
those things. It is vanishingly unlikely that dbus is necessary for
inter-application communication on OSX -- it's already really rare that
_applications_ need to talk to each other using dbus on any platform,
as opposed to desktop system components.
For me, as someone who is going to have to publish an application on OSX,
any work on macports, fink or whatever is useless. I need to be able
to make a bundle, that's it. And as on Windows, caches, daemons, ipc,
out-of-process kio slaves, all that is simply out of the question. One
bundle, one process, no external dependencies. Anything else leads
to madness.
On the other hand, I won't ever be able to publish Krita on the Mac App
store anyway, let alone the iOS app store (though Steam is a possibility).
Boudewijn
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
