Making Purpose part of KF5

[Aleix Pol]

On Fri, Nov 10, 2017 at 1:16 AM, David Edmundson
<david at davidedmundson.co.uk> wrote:
>
>
> On Thu, Nov 9, 2017 at 11:45 PM, Aleix Pol <aleixpol at kde.org> wrote:
>>
>> On Thu, Nov 9, 2017 at 7:35 PM, David Edmundson
>> <david at 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