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
