On Sun, Jun 12, 2011 at 11:33 AM, Dmitry Kazakov <dimul...@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 _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
