KAction to QT migration plan

[todd rme]

On Mon, Feb 27, 2012 at 10:40 PM, Kevin Ottens <ervin at kde.org> wrote:
> 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

I have been thinking for a long time now that kglobalaccel needs to be
reworked.  Its current restriction to just keyboard shortcuts and its
lack of extensibility seems too limiting.  I think a better approach
would be to have it act as an intermediary, where plug-ins would send
it events, and it would then map these events to actions.

So, for example, the keyboard button or gesture handler would both
just feed events to kglobalaccel.  So could a mouse button handler
(Qt5 will have support for extra mouse buttons), kremotecontrol, even
simon.

This would require some major changes and a public api (or dbus?), but
I think it would bring the shortcut system in line with the rest of
kde in terms of flexibility and extensibility.

-Todd