Action system refactor

[Dmitry Kazakov]

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.
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?

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