KAction to QT migration plan

[Kevin Ottens]

Hello,

So here are my 0.02€.

On Sunday 26 February 2012 12:56:33 Valentin Rusu wrote:
> As previously discussed here, I prepared a migration plan for KAction
> class. It takes the form af a spreadsheet available here:
> https://docs.google.com/spreadsheet/ccc?key=0Aj05Q1-vupr3dFFoUUYyc2pTZlltUFd
> RX3M5Z1Y2aGc
> 
> After doing this, 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.

The problem I see there is that there's no chance for KGlobalAccel kded module 
to go in Qt. There's no Qt equivalent to kded in the first place.
 
> This brings second issue : should KAuth go to Qt?
>  From the actual kdelibs state I understand that "no".

That's correct, kauth is here to stay as an independent part.

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

Well, from the approach you apparently followed that's the only conclusion 
possible indeed. If you think in terms of "pick a method from KAction and move 
it in QAction" there will always be left overs. So I think it should partly be 
approached from a different angle:
 a) Which features from KAction makes sense for Qt in general?
 b) From the left overs, how can we make a different API for them?

Regarding (a), I tend to think only the support for default shortcuts make 
sense, it's definitely missing from Qt to handle action settings properly. And 
if it fails to put that part in Qt then we'd treat it in the (b) case.

Now for (b), it seems that most of the cases are of the type "attach some bit 
of information to an action that is then consumed at some other place". It's 
not like any of the KAction specific properties add behavior, so I'm thinking 
that maybe instead we should change to an API where we register the actions to 
their consumption point. For instance, for the gestures support, instead of 
having a setShapeGesture method on a KAction, we'd have a gesture manager on 
which you can register an action for a given gesture... now looking at KAction 
code it's exactly what's done internally, we just register the action to a 
KGestureMap singleton. Solution could just be to improve this KGestureMap API 
in this case.

So mostly food for thought here. Hope that helps a bit nonetheless.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120227/1e54bb65/attachment-0001.sig>