Proposal for new modifiers/shortcuts system

[todd rme]

On Sun, Jun 12, 2011 at 11:33 AM, Dmitry Kazakov <dimula73 at gmail.com> wrote:
>
>> Why calligra only?  This sounds like it is something that would be
>> generally useful to all of KDE.
>
> Well, it could be good idea to make it kde-wide, but there are two problems:
> 1) It is supposed to work with tools right now, so we will have to make it
> more abstract somehow
> 2) It might take much time to implement this abstraction and make it
> kde-wide-usable
>
> But we can discuss variants, maybe, there is some optimal work/abstraction
> tradeoff =) Do you have any idea?


Your system would probably benefit from being divided up into several
different systems, built hierchically:

Keyboard shortcut system: Looking at the KAction API, there is a
"triggered" signal.  Perhaps adding a "released" signal that activates
when the action trigger stops might work at the basic level.  So
applications that want the current behavior would not have to make any
changes, while applications that want to do what you are doing just
have to connect something to the "released" signal.  The changes under
the hood might need to be more significant, though.

Context handler: probably a subclass of KAction, probably just
implemented in Calligra (although implemented in such a way that it
could be ported upstream if there was demand for it).  This would
watch the general state of the program.  It would have signals
connected to the triggered and released signals in various KActions.
When the context manager's signal is triggered (or released), it looks
at the state of the Calligra program and decides which other KAction
it should pass that signal to.

Dock Widget: The goal of this would be to support showing or hiding
dock widgets easily, something I did not see in the document but that
would seem like a logical extension of this.  It would involve either
modifying or subclassing the normal KDockWidget.  The goal would be to
easily add a KAction to the widget.  The KAction could be set in two
forms, one that toggled the widget, and the other that toggles the
widget on press and showed the widget temporarily on hold.  The
default would be to not use a KAction at all.  This may be convenient
for Dolphin which already uses KActions to show or hide the
DockWidget.  The KAction would need to be able to be enabled or
disabled dynamically.  There would also need to be a method to return
the KAction.  In order to differentiate between a press and hold, it
would check whether the press and release were within the keyboard
keypress repeat period.  If yes, it would be counted as a press, if
not it would be counted as a hold (alternatively, this could be built
into the KAction, requiring a "press" signal).

Mouse gesture system: This would use the same context handler.  I am
unclear on whether you mean, for example: shift+drag in general, or
shift+drag on the button.  If the former, it would need to use the
gesture system if I am not familiar with.  If the latter, it would
probably be a subclass of whatever type of button it is.  The
abstraction would probably be to have a default KAction on press, but
be able to define additionl KActions based on the direction of the
drag and what other keys are pressed at the time.  In order to handle
the Calligra-specific bits, the signals from these KActions could be
connected to the signals of context handlers, which would then connect
to the signals of other KActions to actually carry out the operation.


So under this system pretty much everything is generic.  The only
thing that would be Calligra-specific would be the context handlers.
Whether there would be one context handler with an arbitrary number of
signals and slots for routing, or multiple context handlers with one
slot and a bunch of signals I am not sure.

-Todd