Re: kio-extras into applications
On Tuesday 30 June 2015 11:03:21 Sebastian Kügler wrote: On Tuesday, June 30, 2015 12:00:31 Jonathan Riddell wrote: Plasma 5.3.2 is out and in August the 3 releases are closely aligned so it's a chance to move things about while minimising the overlap. kio-extras has been suggested to be moved to Applications instead of Plasma as it's needed by people who use Applications but don't use Plasma. Should I request the move and into which sub-module? Doesn't this give us the same problem, only the other way around? I don't see that. You install a Plasma desktop. Then you need a text editor, you install kwrite. Then you need support for sftp://, you install kio-extras. The latter integrates with the desktop differently than the former, but other than that, it's all about additional features at runtime, which you can install from KDE Applications, no matter which workspace/desktop you're using. I strongly believe kio-extras should be in applications. I am not opposed to having it in frameworks if that's the consensus, but I find it arguable. It brings features to users (like apps), not to application developers (like frameworks). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kio-extras into applications
On Thursday, July 02, 2015 12:38:24 David Faure wrote: On Thursday 02 July 2015 13:07:45 Alexander Potashev wrote: 2015-07-02 12:54 GMT+03:00 Sebastian Kügler se...@kde.org: If for example I want to use fish:// for my desktop folderview, I'd have to install something from applications. That's what I meant. Yes, and you also need to install something from applications if you want to edit that image file that you see in folderview. You see it as a very different thing because one is a plugin and one is an application, but to the end user, it's both need something more, install something more, very broadly speaking. I think you also need to install something from applications if you want to read the help file for desktop folderview Nitpicking: there are application outside of KDE Application that let you access fish://, for example Krusader. You are both right, no contradiction there. But still, there is nothing wrong in installing only kio-extras from KDE Applications and nothing else from it. Yep. On the other hand, telling people to install a part of Plasma to get fish:// support in kwrite sounds very wrong to me. Surely it does, as soon as an app developer wants to integrate a specific protocol for their app (and not just any protocol, like KIO), then this would be needed. I imagine getting something from a webdav server, or storing a file on a specific backup service.) If an app developer wants to integrate WebDAV with the help of KIO, then kio-extras will be a run-time dependency, so there's absolutely no reason for having kio-extras in Frameworks. Bad example, since WebDAV is implemented by kio_http which is in kio itself But yeah, you could come up with a case where an application developer specifically needs a particular kioslave as the central piece of the application; in such case I could actually be convinced to add it to kio.git, provided that it doesn't add dependencies. Or as you say, that's just a matter of documenting a runtime dependency. I'm sure we have other cases of apps that need each other at runtime... Thanks, that's useful information, and a possible strategy for improvement should that case arise. I'm OK with moving kio-extras into applications. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kio-extras into applications
On Thursday, July 02, 2015 11:34:56 David Faure wrote: On Tuesday 30 June 2015 11:03:21 Sebastian Kügler wrote: On Tuesday, June 30, 2015 12:00:31 Jonathan Riddell wrote: Plasma 5.3.2 is out and in August the 3 releases are closely aligned so it's a chance to move things about while minimising the overlap. kio-extras has been suggested to be moved to Applications instead of Plasma as it's needed by people who use Applications but don't use Plasma. Should I request the move and into which sub-module? Doesn't this give us the same problem, only the other way around? I don't see that. You install a Plasma desktop. Then you need a text editor, you install kwrite. Then you need support for sftp://, you install kio-extras. The latter integrates with the desktop differently than the former, but other than that, it's all about additional features at runtime, which you can install from KDE Applications, no matter which workspace/desktop you're using. If for example I want to use fish:// for my desktop folderview, I'd have to install something from applications. That's what I meant. I strongly believe kio-extras should be in applications. I have no strong preference, was just wondering how it makes the situation better. (Ok, maybe the example I gave is very power-usery, so it may indeed be more widely used by apps, but it's not really an apps-specific thing, more something like a runtime extension for possibly everything.) I am not opposed to having it in frameworks if that's the consensus, but I find it arguable. It brings features to users (like apps), not to application developers (like frameworks). Surely it does, as soon as an app developer wants to integrate a specific protocol for their app (and not just any protocol, like KIO), then this would be needed. I imagine getting something from a webdav server, or storing a file on a specific backup service.) Don't count this as veto, just food for thought, please. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kio-extras into applications
Hi Sebastian, Please find my comments below. 2015-07-02 12:54 GMT+03:00 Sebastian Kügler se...@kde.org: If for example I want to use fish:// for my desktop folderview, I'd have to install something from applications. That's what I meant. Nitpicking: there are application outside of KDE Application that let you access fish://, for example Krusader. But still, there is nothing wrong in installing only kio-extras from KDE Applications and nothing else from it. I am not opposed to having it in frameworks if that's the consensus, but I find it arguable. It brings features to users (like apps), not to application developers (like frameworks). Surely it does, as soon as an app developer wants to integrate a specific protocol for their app (and not just any protocol, like KIO), then this would be needed. I imagine getting something from a webdav server, or storing a file on a specific backup service.) If an app developer wants to integrate WebDAV with the help of KIO, then kio-extras will be a run-time dependency, so there's absolutely no reason for having kio-extras in Frameworks. -- Alexander Potashev ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kio-extras into applications
On Thursday 02 July 2015 13:07:45 Alexander Potashev wrote: Hi Sebastian, Please find my comments below. 2015-07-02 12:54 GMT+03:00 Sebastian Kügler se...@kde.org: If for example I want to use fish:// for my desktop folderview, I'd have to install something from applications. That's what I meant. Yes, and you also need to install something from applications if you want to edit that image file that you see in folderview. You see it as a very different thing because one is a plugin and one is an application, but to the end user, it's both need something more, install something more, very broadly speaking. I think you also need to install something from applications if you want to read the help file for desktop folderview :-) Nitpicking: there are application outside of KDE Application that let you access fish://, for example Krusader. You are both right, no contradiction there. But still, there is nothing wrong in installing only kio-extras from KDE Applications and nothing else from it. Yep. On the other hand, telling people to install a part of Plasma to get fish:// support in kwrite sounds very wrong to me. I am not opposed to having it in frameworks if that's the consensus, but I find it arguable. It brings features to users (like apps), not to application developers (like frameworks). Surely it does, as soon as an app developer wants to integrate a specific protocol for their app (and not just any protocol, like KIO), then this would be needed. I imagine getting something from a webdav server, or storing a file on a specific backup service.) If an app developer wants to integrate WebDAV with the help of KIO, then kio-extras will be a run-time dependency, so there's absolutely no reason for having kio-extras in Frameworks. Bad example, since WebDAV is implemented by kio_http which is in kio itself :-) But yeah, you could come up with a case where an application developer specifically needs a particular kioslave as the central piece of the application; in such case I could actually be convinced to add it to kio.git, provided that it doesn't add dependencies. Or as you say, that's just a matter of documenting a runtime dependency. I'm sure we have other cases of apps that need each other at runtime... -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kde/workspace git module rename
On Thursday 02 July 2015 10:36:09 Jonathan Riddell wrote: On Tue, Jun 30, 2015 at 12:59:41PM +0200, Martin Gräßlin wrote: On Tuesday 30 June 2015 12:01:47 Jonathan Riddell wrote: projects.kde.org has a module called kde/workspace that's used for Plasma bits. The name term workspace is obsolete and it's confusing having it under kde where all the applications modules are. I'd like to rename it to plasma. I guess this will break kde-srcbuild and maybe other build scripts. Is the tidying up worth the hassle? It will not just break kdesrc-build but also the local src code and build trees on our developer's systems. E.g. I have the structure setup with kdesrc- build and imported the projects into kdevelop using the src, build and install structure generated by kdesrc-build. This change would mean dropping all projects from kdevelop and reimport them, having to deal with branches not being moved to the new git structure, etc. etc. I expect that this would cost me several hours of work on each system (I have a build tree on three to four devices). Assuming that other plasma devs have similar setups we waste several person days just with shuffling repositories around. So given that I think this is not worth the hassle. ok I'll drop the idea then One idea would be a kdesrc-build feature that allows it to keep using a checkout 'at the old place' while it exists, rather than moving to 'the new place' I'm pretty sure this already exists with an explicit put this module in that dir per-module setting, but I mean more generally a global setting that makes kdesrc-build conservative about location when stuff is moved, and the developer would get things in the new place only after deleting the old checkout, if he ever wants to. Or never, if he doesn't delete it ever. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kio-extras into applications
El Dijous, 2 de juliol de 2015, a les 02:39:58, Alexander Potashev va escriure: 2015-07-02 2:10 GMT+03:00 Albert Astals Cid aa...@kde.org: El Dimarts, 30 de juny de 2015, a les 16:45:18, Alexander Potashev va escriure: Same question for kross-interpreters. Its Qt5/KF5 version hasn't been released yet and it should probably go through a review process, but it's still unclear if it fits KDE Applications. KDE SC 4.x contained kross-interpreters, but I'm not sure if this was the best decision. Is there anything in Plasma or KF5 that needs kross-interpreters? (I guess not since otherwise it'd be failing now) If not we can just release it with KDE Applications. If there is potentially a reason for Plasma to use it, i'd say move the release to KF5, since really what do you need kross for if you kross for if you don't have any interpreter to do stuff? Albert, OK, adding kross-interpreters into KA5 would work. I was just thinking it doesn't really belong to KDE Applications: any application/product using Kross may benefit from kross-interpreters. yeah the name of KDE Applications is not the best ever, we also release libraries in there, but it's the least worst we could come up with :D Cheers, Albert kross-interpreters is only a run-time dependency, that's why nobody noticed it was missing (except for may be people who use Lokalize KF5 and expect Python scripts to work.) Even if Plasma starts using Kross, this doesn't imply that kross-interprers should be released with Plasma. Can we release kio-extras and kross-interpreters separately from KA5 and KP5? The more releases the more complex stuff gets, let's try not to. Okay, not this time ;) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kde/workspace git module rename
On Thu, July 2, 2015 12:41:32 David Faure wrote: On Thursday 02 July 2015 10:36:09 Jonathan Riddell wrote: On Tue, Jun 30, 2015 at 12:59:41PM +0200, Martin Gräßlin wrote: On Tuesday 30 June 2015 12:01:47 Jonathan Riddell wrote: projects.kde.org has a module called kde/workspace that's used for Plasma bits. The name term workspace is obsolete and it's confusing having it under kde where all the applications modules are. I'd like to rename it to plasma. I guess this will break kde-srcbuild and maybe other build scripts. Is the tidying up worth the hassle? It will not just break kdesrc-build but also the local src code and build trees on our developer's systems. E.g. I have the structure setup with kdesrc- build and imported the projects into kdevelop using the src, build and install structure generated by kdesrc-build. This change would mean dropping all projects from kdevelop and reimport them, having to deal with branches not being moved to the new git structure, etc. etc. I expect that this would cost me several hours of work on each system (I have a build tree on three to four devices). Assuming that other plasma devs have similar setups we waste several person days just with shuffling repositories around. So given that I think this is not worth the hassle. ok I'll drop the idea then One idea would be a kdesrc-build feature that allows it to keep using a checkout 'at the old place' while it exists, rather than moving to 'the new place' I'm pretty sure this already exists with an explicit put this module in that dir per-module setting, but I mean more generally a global setting that makes kdesrc-build conservative about location when stuff is moved, and the developer would get things in the new place only after deleting the old checkout, if he ever wants to. Or never, if he doesn't delete it ever. That's doable, I guess. Would be a matter of storing the saved srcdir/builddir in the existing persistent data store for each module-name and I don't think it would be very difficult from there, if that's something people would desire. Regards, - Michael Pyne ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kde/workspace git module rename
On Thu, July 2, 2015 17:37:33 Aleix Pol wrote: I'm pretty sure this already exists with an explicit put this module in that dir per-module setting, but I mean more generally a global setting that makes kdesrc-build conservative about location when stuff is moved, and the developer would get things in the new place only after deleting the old checkout, if he ever wants to. Or never, if he doesn't delete it ever. It would be better if kde-src-build didn't adopt the nested tree. It doesn't buy much and it wouldn't have such problems. https://kdesrc-build.kde.org/documentation/conf-options-table.html#conf-ignore-kde-structure might help if you prefer the dir layout to be flat. Regards, - Michael Pyne ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
