Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework
On Friday 19 December 2014 17:46:07 šumski wrote: On Thursday 18 of December 2014 20:15:52 Martin Klapetek wrote: On Wed, Dec 17, 2014 at 9:11 PM, šumski hrvoje.sen...@gmail.com wrote: Hi, i've checked your clone, and what new requirements will that bring, and if the CMakeLists there are accurate, that will create a problem. We will have a dependency circle between kglobalaccel, kinit, kio and kxmlgui. Bah, I think you're correct. Basically the only link in this dep circle is KBookmarks using KActionCollection from xmlgui if I'm reading it correctly. If this is removed, then I think the circle would be gone. KIO requires both KBookmarks and KXMLGui, so i am not sure how changing something in KBookmarks only would change the cycle... One possible solution, but no idea would that be OK, is to make the kglobalaccel 'regular' executable, instead of a kdeinit one... That's definitely an option, it only makes a difference in terms of startup time, for one daemon we can do without the kdeinit optimization, if it solves a circular dependency. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework
On Fri, Dec 19, 2014 at 8:36 AM, Martin Gräßlin mgraess...@kde.org wrote: I don't get what you want to attempt to solve the circle - remove KActionCollection dependency from KBookmarks? Remove KActionCollection usage from KBookmarks, that will remove the dep on KXmlGui. It's used only in one single class and in two places in there only. Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework
On Thursday 18 of December 2014 20:15:52 Martin Klapetek wrote: On Wed, Dec 17, 2014 at 9:11 PM, šumski hrvoje.sen...@gmail.com wrote: Hi, i've checked your clone, and what new requirements will that bring, and if the CMakeLists there are accurate, that will create a problem. We will have a dependency circle between kglobalaccel, kinit, kio and kxmlgui. Bah, I think you're correct. Basically the only link in this dep circle is KBookmarks using KActionCollection from xmlgui if I'm reading it correctly. If this is removed, then I think the circle would be gone. KIO requires both KBookmarks and KXMLGui, so i am not sure how changing something in KBookmarks only would change the cycle... One possible solution, but no idea would that be OK, is to make the kglobalaccel 'regular' executable, instead of a kdeinit one... Cheers, Hrvoje I checked the usage and it's not too much. Should it be attempted? Or what other options do we have? Cheers signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework
On Fri, Dec 19, 2014 at 5:46 PM, šumski hrvoje.sen...@gmail.com wrote: On Thursday 18 of December 2014 20:15:52 Martin Klapetek wrote: On Wed, Dec 17, 2014 at 9:11 PM, šumski hrvoje.sen...@gmail.com wrote: Hi, i've checked your clone, and what new requirements will that bring, and if the CMakeLists there are accurate, that will create a problem. We will have a dependency circle between kglobalaccel, kinit, kio and kxmlgui. Bah, I think you're correct. Basically the only link in this dep circle is KBookmarks using KActionCollection from xmlgui if I'm reading it correctly. If this is removed, then I think the circle would be gone. KIO requires both KBookmarks and KXMLGui, so i am not sure how changing something in KBookmarks only would change the cycle... One possible solution, but no idea would that be OK, is to make the kglobalaccel 'regular' executable, instead of a kdeinit one... Oh indeed. Well, we need newer frameworks dependency graphs xD I have pretty much zarro knowledge around the kdeinit stuff, so if someone will ok it, I'll get it done. Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework
El Dijous, 18 de desembre de 2014, a les 20:15:52, Martin Klapetek va escriure: On Wed, Dec 17, 2014 at 9:11 PM, šumski hrvoje.sen...@gmail.com wrote: Hi, i've checked your clone, and what new requirements will that bring, and if the CMakeLists there are accurate, that will create a problem. We will have a dependency circle between kglobalaccel, kinit, kio and kxmlgui. Bah, I think you're correct. Basically the only link in this dep circle is KBookmarks using KActionCollection from xmlgui if I'm reading it correctly. If this is removed, then I think the circle would be gone. I checked the usage and it's not too much. Should it be attempted? Or what other options do we have? Create a kglobalaccel-clients (or servers or daemons or whatever) repo. Cheers, Albert P.S: Yes, i hate creating new repos, can't the people that want to use it just get the big tarball and compile the part they want? Cheers ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework
On Wed, Dec 17, 2014 at 9:11 PM, šumski hrvoje.sen...@gmail.com wrote: Hi, i've checked your clone, and what new requirements will that bring, and if the CMakeLists there are accurate, that will create a problem. We will have a dependency circle between kglobalaccel, kinit, kio and kxmlgui. Bah, I think you're correct. Basically the only link in this dep circle is KBookmarks using KActionCollection from xmlgui if I'm reading it correctly. If this is removed, then I think the circle would be gone. I checked the usage and it's not too much. Should it be attempted? Or what other options do we have? Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework
On Thursday 18 December 2014 20:15:52 Martin Klapetek wrote: On Wed, Dec 17, 2014 at 9:11 PM, šumski hrvoje.sen...@gmail.com wrote: Hi, i've checked your clone, and what new requirements will that bring, and if the CMakeLists there are accurate, that will create a problem. We will have a dependency circle between kglobalaccel, kinit, kio and kxmlgui. Bah, I think you're correct. Basically the only link in this dep circle is KBookmarks using KActionCollection from xmlgui if I'm reading it correctly. If this is removed, then I think the circle would be gone. I checked the usage and it's not too much. Should it be attempted? Or what other options do we have? I don't get what you want to attempt to solve the circle - remove KActionCollection dependency from KBookmarks? signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework
On Monday 15 of December 2014 13:55:04 Martin Gräßlin wrote: On Friday 12 December 2014 12:38:20 Martin Klapetek wrote: On Fri, Oct 3, 2014 at 1:16 PM, Alex Merry alex.me...@kde.org wrote: On 2014-09-17 10:47, Martin Gräßlin wrote: Hi all, I just prepared moving kglobalacceld from plasma-workspace into kglobalaccel. You can find the code in my personal clone of kglobalaccel at [1] in branch master. The following steps were performed so far: * filter-branch on plasma-workspace to just have all kglobalacceld commits * move all files to src/runtime * merge code in kglobalaccel * adjust CMakeLists to find additionally needed dependencies for runtime part * raise tier to 3 in metadata Please have a look at it, whether I have forgotten something or should do something differently. Git history looks sensible. Things I'm unsure about is: * how does the raise of framework needs to be reflected in cmake It doesn't. * how do one expose the different licences? A License section in README.md? * is it needed to export the new dependencies? After all they are just runtime deps? No, because they are not needed at compile-time by software that uses KGlobalAccel. Do we want an option to disable compilation of the runtime? Is the runtime needed on all platforms? I seem to remember some discussion suggesting it either wasn't or needn't be, but I can't remember the details. Alex Quoting from IRC just now: jleclanche we'd like to use it [kglobalaccel] in lxqt, but the framework is useless without its client atm Martin - what's the status of this? Is any help needed? Can we get this into Frameworks 5.6? Given the basically non-existing feedback on the thread (modulo Alex's reply) I would assume that everything is fine and we can just move the code. If you want to take care of it, I would certainly appreciate this. Hi, i've checked your clone, and what new requirements will that bring, and if the CMakeLists there are accurate, that will create a problem. We will have a dependency circle between kglobalaccel, kinit, kio and kxmlgui. Cheers, Hrvoje Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework
On Wednesday 17 of December 2014 21:11:04 šumski wrote: On Monday 15 of December 2014 13:55:04 Martin Gräßlin wrote: On Friday 12 December 2014 12:38:20 Martin Klapetek wrote: On Fri, Oct 3, 2014 at 1:16 PM, Alex Merry alex.me...@kde.org wrote: On 2014-09-17 10:47, Martin Gräßlin wrote: Hi all, I just prepared moving kglobalacceld from plasma-workspace into kglobalaccel. You can find the code in my personal clone of kglobalaccel at [1] in branch master. The following steps were performed so far: * filter-branch on plasma-workspace to just have all kglobalacceld commits * move all files to src/runtime * merge code in kglobalaccel * adjust CMakeLists to find additionally needed dependencies for runtime part * raise tier to 3 in metadata Please have a look at it, whether I have forgotten something or should do something differently. Git history looks sensible. Things I'm unsure about is: * how does the raise of framework needs to be reflected in cmake It doesn't. * how do one expose the different licences? A License section in README.md? * is it needed to export the new dependencies? After all they are just runtime deps? No, because they are not needed at compile-time by software that uses KGlobalAccel. Do we want an option to disable compilation of the runtime? Is the runtime needed on all platforms? I seem to remember some discussion suggesting it either wasn't or needn't be, but I can't remember the details. Alex Quoting from IRC just now: jleclanche we'd like to use it [kglobalaccel] in lxqt, but the framework is useless without its client atm Martin - what's the status of this? Is any help needed? Can we get this into Frameworks 5.6? Given the basically non-existing feedback on the thread (modulo Alex's reply) I would assume that everything is fine and we can just move the code. If you want to take care of it, I would certainly appreciate this. Hi, i've checked your clone, and what new requirements will that bring, and if the CMakeLists there are accurate, that will create a problem. We will have a dependency circle between kglobalaccel, kinit, kio and kxmlgui. Another issue is the translation domain. It collides with kde-runtime's kglobalaccel translations, which would break KF5 co-installability... Cheers, Hrvoje Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework
On Friday 12 December 2014 13:04:59 Aleix Pol wrote: On Wed, Sep 17, 2014 at 11:47 AM, Martin Gräßlin mgraess...@kde.org wrote: Hi all, I just prepared moving kglobalacceld from plasma-workspace into kglobalaccel. You can find the code in my personal clone of kglobalaccel at [1] in branch master. The following steps were performed so far: * filter-branch on plasma-workspace to just have all kglobalacceld commits * move all files to src/runtime * merge code in kglobalaccel * adjust CMakeLists to find additionally needed dependencies for runtime part * raise tier to 3 in metadata Please have a look at it, whether I have forgotten something or should do something differently. Things I'm unsure about is: * how does the raise of framework needs to be reflected in cmake * how do one expose the different licences? * is it needed to export the new dependencies? After all they are just runtime deps? Cheers Martin [1] kde:clones/kglobalaccel/graesslin/kglobalaccel ___ +1 I guess this means it will only have the daemon on X11/Linux, no? What happens with the other platforms? I do not understand your question. The deamon is multi-platform, but needs porting for non-X11 platforms. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework
On Friday 12 December 2014 12:38:20 Martin Klapetek wrote: On Fri, Oct 3, 2014 at 1:16 PM, Alex Merry alex.me...@kde.org wrote: On 2014-09-17 10:47, Martin Gräßlin wrote: Hi all, I just prepared moving kglobalacceld from plasma-workspace into kglobalaccel. You can find the code in my personal clone of kglobalaccel at [1] in branch master. The following steps were performed so far: * filter-branch on plasma-workspace to just have all kglobalacceld commits * move all files to src/runtime * merge code in kglobalaccel * adjust CMakeLists to find additionally needed dependencies for runtime part * raise tier to 3 in metadata Please have a look at it, whether I have forgotten something or should do something differently. Git history looks sensible. Things I'm unsure about is: * how does the raise of framework needs to be reflected in cmake It doesn't. * how do one expose the different licences? A License section in README.md? * is it needed to export the new dependencies? After all they are just runtime deps? No, because they are not needed at compile-time by software that uses KGlobalAccel. Do we want an option to disable compilation of the runtime? Is the runtime needed on all platforms? I seem to remember some discussion suggesting it either wasn't or needn't be, but I can't remember the details. Alex Quoting from IRC just now: jleclanche we'd like to use it [kglobalaccel] in lxqt, but the framework is useless without its client atm Martin - what's the status of this? Is any help needed? Can we get this into Frameworks 5.6? Given the basically non-existing feedback on the thread (modulo Alex's reply) I would assume that everything is fine and we can just move the code. If you want to take care of it, I would certainly appreciate this. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework
On Mon, Dec 15, 2014 at 1:55 PM, Martin Gräßlin mgraess...@kde.org wrote: Given the basically non-existing feedback on the thread (modulo Alex's reply) I would assume that everything is fine and we can just move the code. If you want to take care of it, I would certainly appreciate this. I've relicensed the daemon to LGPLv2.1+ so now it all has the same license. I've updated the README.md and basically have it ready to commit. Are there any other objections or comments? Otherwise I'll push this tomorrow. Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework
On Monday 15 December 2014 19:29:03 Martin Klapetek wrote: On Mon, Dec 15, 2014 at 1:55 PM, Martin Gräßlin mgraess...@kde.org wrote: Given the basically non-existing feedback on the thread (modulo Alex's reply) I would assume that everything is fine and we can just move the code. If you want to take care of it, I would certainly appreciate this. I've relicensed the daemon to LGPLv2.1+ so now it all has the same license. I've updated the README.md and basically have it ready to commit. Are there any other objections or comments? Otherwise I'll push this tomorrow. Thanks for taking care of it! signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework
On Fri, Oct 3, 2014 at 1:16 PM, Alex Merry alex.me...@kde.org wrote: On 2014-09-17 10:47, Martin Gräßlin wrote: Hi all, I just prepared moving kglobalacceld from plasma-workspace into kglobalaccel. You can find the code in my personal clone of kglobalaccel at [1] in branch master. The following steps were performed so far: * filter-branch on plasma-workspace to just have all kglobalacceld commits * move all files to src/runtime * merge code in kglobalaccel * adjust CMakeLists to find additionally needed dependencies for runtime part * raise tier to 3 in metadata Please have a look at it, whether I have forgotten something or should do something differently. Git history looks sensible. Things I'm unsure about is: * how does the raise of framework needs to be reflected in cmake It doesn't. * how do one expose the different licences? A License section in README.md? * is it needed to export the new dependencies? After all they are just runtime deps? No, because they are not needed at compile-time by software that uses KGlobalAccel. Do we want an option to disable compilation of the runtime? Is the runtime needed on all platforms? I seem to remember some discussion suggesting it either wasn't or needn't be, but I can't remember the details. Alex Quoting from IRC just now: jleclanche we'd like to use it [kglobalaccel] in lxqt, but the framework is useless without its client atm Martin - what's the status of this? Is any help needed? Can we get this into Frameworks 5.6? Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework
On Wed, Sep 17, 2014 at 11:47 AM, Martin Gräßlin mgraess...@kde.org wrote: Hi all, I just prepared moving kglobalacceld from plasma-workspace into kglobalaccel. You can find the code in my personal clone of kglobalaccel at [1] in branch master. The following steps were performed so far: * filter-branch on plasma-workspace to just have all kglobalacceld commits * move all files to src/runtime * merge code in kglobalaccel * adjust CMakeLists to find additionally needed dependencies for runtime part * raise tier to 3 in metadata Please have a look at it, whether I have forgotten something or should do something differently. Things I'm unsure about is: * how does the raise of framework needs to be reflected in cmake * how do one expose the different licences? * is it needed to export the new dependencies? After all they are just runtime deps? Cheers Martin [1] kde:clones/kglobalaccel/graesslin/kglobalaccel ___ +1 I guess this means it will only have the daemon on X11/Linux, no? What happens with the other platforms? Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework
On 2014-09-17 10:47, Martin Gräßlin wrote: Hi all, I just prepared moving kglobalacceld from plasma-workspace into kglobalaccel. You can find the code in my personal clone of kglobalaccel at [1] in branch master. The following steps were performed so far: * filter-branch on plasma-workspace to just have all kglobalacceld commits * move all files to src/runtime * merge code in kglobalaccel * adjust CMakeLists to find additionally needed dependencies for runtime part * raise tier to 3 in metadata Please have a look at it, whether I have forgotten something or should do something differently. Git history looks sensible. Things I'm unsure about is: * how does the raise of framework needs to be reflected in cmake It doesn't. * how do one expose the different licences? A License section in README.md? * is it needed to export the new dependencies? After all they are just runtime deps? No, because they are not needed at compile-time by software that uses KGlobalAccel. Do we want an option to disable compilation of the runtime? Is the runtime needed on all platforms? I seem to remember some discussion suggesting it either wasn't or needn't be, but I can't remember the details. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Move of kglobalacceld from plasma-workspace to kglobalaccel framework
Hi all, I just prepared moving kglobalacceld from plasma-workspace into kglobalaccel. You can find the code in my personal clone of kglobalaccel at [1] in branch master. The following steps were performed so far: * filter-branch on plasma-workspace to just have all kglobalacceld commits * move all files to src/runtime * merge code in kglobalaccel * adjust CMakeLists to find additionally needed dependencies for runtime part * raise tier to 3 in metadata Please have a look at it, whether I have forgotten something or should do something differently. Things I'm unsure about is: * how does the raise of framework needs to be reflected in cmake * how do one expose the different licences? * is it needed to export the new dependencies? After all they are just runtime deps? Cheers Martin [1] kde:clones/kglobalaccel/graesslin/kglobalaccel signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
