moving classes to kde4support
Valentin Rusu
kde at rusu.info
Sat Apr 28 21:37:38 UTC 2012
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-vupr3dFFoUUYyc2pTZlltUFdRX3M5Z1Y2aGc
I think that further discussion is needed to decide some issues.
The more important issue is: should KGlobalAccel go to Qt?
More details on this:
- KGlobalAccel communicates with kglobalaccel KDED,
- if KGlobalAccel goes to Qt, then the KDED module should also go, in my
opinion.
- if KGlobalAccel goes to Qt, then KAction class will only hold KAuth
specifi code.
This brings second issue : should KAuth go to Qt?
From the actual kdelibs state I understand that "no".
So KAction class will not dissapear as it'll have at least the KAuth
specific code.
Finally, a pragmatic approach would be to port the methods I identified
on the spreadsheet in a first step, then proceed with other steps along
our decisions.
Waiting for feedback...
--
Valentin Rusu (IRC valir, KDE vrusu)
KSecretsService (former KSecretService, KWallet replacement)
More information about the Kde-frameworks-devel
mailing list