Action system refactor

[Sven Langkamp]

On Thu, Feb 14, 2013 at 9:36 AM, Dmitry Kazakov <dimula73 at gmail.com> wrote:
> Hi, Sven!
> This is a very cool idea! Probably, these two use cases could be
> covered by your idea as well:
> 1) These action classes might probably be merged with the actions of
> the KisInputManager? It might help much.

It could be merged, but I don't see many benefits there.

> 2) There is a use case when a tool has some specific key shortcuts,
> e.g. selection mode keys in the selection tools. When these keys are
> parsed in event handlers, it unavoidably leads to shortcut collisions.
> Probably, you could make some actions (for input manager or just
> kaction based) that would be enabled on the activation of some
> particular tool?

That would be possible. Although of course the tools sometimes change
the action based on the tool state e.g. the selection action are
disabled when vector selection is on.

> On 2/14/13, Sven Langkamp <sven.langkamp at gmail.com> wrote:
>> Hi,
>>
>>
>> I recently got a bit fed up with the way in which we handle action
>> enable/disable. Currently every place that adds new actions needs to
>> implement a updateGUI method and update every action manually. In
>> several place this updating logic is broke because it doesn't cover
>> all the cases. I started a refactoring to clear this situation.
>>
>> The basic idea is as following: There is a central class which updates
>> the action (KisActionManager), every KisAction (inherits from KAction
>> and is a drop in replacement) has flags to control activation and
>> condition that need to be met.
>>
>> Exampe:
>>     m_fillForegroundColor  = new KisAction(i18n("Fill with Foreground
>> Color"), this);
>>     m_fillForegroundColor->setActivationFlags(KisAction::ACTIVE_DEVICE);
>>
>> m_fillForegroundColor->setActivationConditions(KisAction::ACTIVE_NODE_EDITABLE);
>>     actionManager->addAction("fill_selection_foreground_color",
>> m_fillForegroundColor, collection);
>>
>> In this case the action would be enabled if there is an active device
>> and the active node is editable. There can ActivationFlags be multiple
>> flags/conditions by combing them like option1 | option2. The action
>> will only be active if one of the flags and all of the conditions are
>> active.
>>
>> Currently I have identified these:
>>     enum ActivationFlag {
>>         NONE = 0,
>>         ACTIVE_NODE = 1,
>>         ACTIVE_DEVICE = 2,
>>         ACTIVE_LAYER = 4,
>>         ACTIVE_SHAPE_LAYER = 8,
>>         PIXELS_SELECTED = 16,
>>         SHAPES_SELECTED = 32,
>>         PIXEL_SELECTION_WITH_PIXELS = 64,
>>         PIXELS_IN_CLIPBOARD = 128,
>>         SHAPES_IN_CLIPBOARD = 256
>>     };
>>
>>     enum ActivationCondition {
>>         NO_CONDITION = 0,
>>         ACTIVE_NODE_EDITABLE = 1,
>>         SELECTION_EDITABLE = 2
>>     };
>>
>> The advantage of the system is that for many actions no explicit
>> update is needed, it's easier to see what the action does and it's
>> consistent. One downside is that not every action is covered by this
>> e.g. some action need special cases so some of the updateGUI code will
>> remain.
>>
>> Comments?
>>
>>
>> Sven
>> _______________________________________________
>> kimageshop mailing list
>> kimageshop at kde.org
>> https://mail.kde.org/mailman/listinfo/kimageshop
>>
>
>
> --
> Dmitry Kazakov
> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop