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