Re: Making Purpose part of KF5
El dijous, 11 de gener de 2018, a les 2:15:06 CET, Aleix Pol va escriure: > On Thu, Nov 9, 2017 at 5:10 PM, Aleix Pol wrote: > > Hi, > > I would like to include Purpose [1] into the frameworks umbrella. > > It's been around for a while now, used by few applications and > > reasonably stable. > > > > Any thoughts? > > > > Aleix > > > > [1] https://phabricator.kde.org/source/purpose/ > > So... can I play along? > Can we take the 3 months of silence as a yes? Totally, silent acclamation. Cheers, Albert > > Aleix
Re: Making Purpose part of KF5
On Thu, Nov 9, 2017 at 5:10 PM, Aleix Pol wrote: > Hi, > I would like to include Purpose [1] into the frameworks umbrella. > It's been around for a while now, used by few applications and > reasonably stable. > > Any thoughts? > > Aleix > > [1] https://phabricator.kde.org/source/purpose/ So... can I play along? Can we take the 3 months of silence as a yes? Aleix
Re: Making Purpose part of KF5
El dijous, 9 de novembre de 2017, a les 17:10:28 CET, Aleix Pol va escriure: > Hi, > I would like to include Purpose [1] into the frameworks umbrella. > It's been around for a while now, used by few applications and > reasonably stable. > > Any thoughts? Given that now Okular optionally uses it, +1 from my side. Cheers, Albert > > Aleix > > [1] https://phabricator.kde.org/source/purpose/
Re: Making Purpose part of KF5
On Fri, Nov 10, 2017 at 1:20 PM, Hartmut Goebel wrote: > Am 10.11.2017 um 12:50 schrieb Aleix Pol: >> 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. > > This means: purpose is the framework and ought to be in"frameworks". > Maybe it should be called "purpose-framework" to emphasis this. > > The plugins have more dependencies and should not go into the framework, > though. > > If purpose would introduce higher level dependencies, how should this be > build then? You'll end up with cyclic dependencies, which are a horror > to build. > > Please move the plugins into a separate repository or at least make them > to be build *completely* separate (like a subproject.) The fact that there's plugins in the repository now doesn't mean by far that there can't be plugins inside. For example note that kio has some ioslaves in src/ioslaves and I'd say that's perfectly fine. Aleix
Re: Making Purpose part of KF5
Am 10.11.2017 um 12:50 schrieb Aleix Pol: > 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. This means: purpose is the framework and ought to be in"frameworks". Maybe it should be called "purpose-framework" to emphasis this. The plugins have more dependencies and should not go into the framework, though. If purpose would introduce higher level dependencies, how should this be build then? You'll end up with cyclic dependencies, which are a horror to build. Please move the plugins into a separate repository or at least make them to be build *completely* separate (like a subproject.) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Making Purpose part of KF5
On Fri, Nov 10, 2017 at 1:16 AM, David Edmundson wrote: > > > On Thu, Nov 9, 2017 at 11:45 PM, Aleix Pol wrote: >> >> On Thu, Nov 9, 2017 at 7:35 PM, David Edmundson >> 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
Re: Making Purpose part of KF5
On Thu, Nov 9, 2017 at 7:35 PM, David Edmundson wrote: > I think having src/plugins in the framework will cause problems. Can you please elaborate? 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 ;-) ). > > 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 mean. Aleix
Re: Making Purpose part of KF5
On Thu, Nov 9, 2017 at 5:10 PM, Aleix Pol wrote: > Hi, > I would like to include Purpose [1] into the frameworks umbrella. > It's been around for a while now, used by few applications and > reasonably stable. > > Any thoughts? > +1 I actually included it in kdesrc-build quite a while ago because it's needed to build suff (peruse, back then) > Aleix > > [1] https://phabricator.kde.org/source/purpose/ >
Making Purpose part of KF5
Hi, I would like to include Purpose [1] into the frameworks umbrella. It's been around for a while now, used by few applications and reasonably stable. Any thoughts? Aleix [1] https://phabricator.kde.org/source/purpose/
