Move of kglobalacceld from plasma-workspace to kglobalaccel framework

[šumski]

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.merry at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20141217/27b0493b/attachment-0001.sig>