moving classes to kde4support

David Faure faure at kde.org
Sat Apr 28 22:16:05 UTC 2012


On Saturday 28 April 2012 23:37:38 Valentin Rusu wrote:
> Hello,
> 
> On 04/28/2012 09:23 PM, David Faure wrote:
> > On Wednesday 28 March 2012 16:14:32 Giorgos Tsiapaliwkas wrote:
> > We'll come back to kwidgets and kactions with a more precise master
> > plan, I'll post about this soon.
> 
> Back in february I prepared a migration plan for KAction class. As it
> seems to me that my initial message got lost, I'll gice it a second
> chance :)
> 
> The migration plan takes the form af a spreadsheet available here:
> https://docs.google.com/spreadsheet/ccc?key=0Aj05Q1-vupr3dFFoUUYyc2pTZlltUFd
> RX3M5Z1Y2aGc

Good job.
Just one thing wrong: you wrote there are not users of the shortcutConfigurable 
property, but lxr finds many:

http://lxr.kde.org/ident?i=setShortcutConfigurable

> I think that further discussion is needed to decide some issues.
> The more important issue is: should KGlobalAccel go to Qt?

That would be great, IMHO, but difficult, because a daemon is needed on unix 
systems, and simple Qt apps don't like to start daemons ;)
This should be discussed on the qt development mailing-list though, I can't 
speak for the Qt project.

> So KAction class will not dissapear as it'll have at least the KAuth
> specific code.

Yeah but most users of kaction don't need kauth, this is an additional 
feature, it can stay in a KAuthAction subclass, for instance.
TODO: check what the calling code of this kauth+kaction feature looks like...

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5



More information about the Kde-frameworks-devel mailing list