On Fri, Nov 10, 2017 at 1:16 AM, David Edmundson <da...@davidedmundson.co.uk> wrote: > > > On Thu, Nov 9, 2017 at 11:45 PM, Aleix Pol <aleix...@kde.org> wrote: >> >> On Thu, Nov 9, 2017 at 7:35 PM, David Edmundson >> <da...@davidedmundson.co.uk> wrote: >> > I think having src/plugins in the framework will cause problems. >> >> Can you please elaborate? >> > You'll have to have every dependency possible, and then no-one will use the > lib because of that. > >> >> I'm not excited about having all the plugins inside TBH, but then I >> don't see another way around that isn't having a purpose-plugins >> repository (or a purpose-nextcloud, purpose-kdeconnect, etc à la ktp >> ;-) ). > > > So like kio & kio-extras? I don't think that's a huge problem.
My thinking is that it should be good enough to make the dependencies of the plugins optional rather than creating a whole separate repository. I share the concern in fact, part of the reason why I didn't push it earlier was to be able to have it proper tier2. My reasoning for leaving it as this is that it just adds an extra step users will have to take to install the plugins and it's not a very useful one (to pull the plugins). Without plugins, purpose is useless. > >> >> >> > >> > Also the docs need a thorough cleanup >> > >> > "To import it from QML, import >> > import org.kde.people 1.0" >> >> Fixed. *rolls eyes* >> >> > and the c++ headers need some too. >> >> If you know other issues tell me and I'll fix it, I'm not sure what you > > > I opened a few header files, half the methods had some docs, the other half > did not. > I'm not going to list them. Oh, api documentation, I guess, will add to my to do list. > ------- > > One question about the way the whole thing fundamentally works: > We're moving towards a world where apps are sandboxed, binary plugins aren't > going to be a thing we can really use. > > As one of our resident flatpak experts, is this future proof? > If not, can we expand on the whole external process concept so that a job > can be proxied through a portal? It can, it's not implemented. At the moment we already have the concept of executing the plugins out of process, so making an implementation that would move this outside of the sandbox is easily doable. But then we are requiring the host system to have Purpose installed, and that's a bit odd. There's nothing fundamentally wrong in shipping Purpose and plugins within the sandbox, in fact it's what we do nowadays for many things such as KIO and I don't see us changing this in the foreseeable future. One thing I was thinking of doing was to actually expose some API in the QuickShare plasmoid so that when we share something it happens there, thinking of a dbus interface that can optionally be used. This would fit very well with flatpak/snap story but still be a mere fallback. The big advantage being that it would allow us to not have every plugin on earth present in the container and use the systems', although we will always need to have a fallback for users without quickshare or even plasma. HTH, Aleix
