KAction to QT migration plan
ervin at kde.org
Mon Feb 27 21:40:34 UTC 2012
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:
> 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
> - 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.
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the Kde-frameworks-devel