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