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. > > > > > 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. ------- 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?
