GtkAction migration

Background: what are actions?

An "action" is a thing that Inkscape can do. In its simplest form, it contains two things:

• The name of the action (e.g., "ObjectFlipHorizontally")
• A pointer to some code that performs the action (e.g., a few lines that flip the object horizontally)

In the Inkscape application, we can attach actions to widgets so that when the user interacts with that widget (e.g. clicks on the "Flip horizontally" button in the toolbar), the action is triggered.

How is this different from GUI events?

GUI elements (buttons etc) provide their own signals (e.g, "clicked") that are emitted in response to user interaction. We then need to connect a callback function to handle that specific GUI event. If we have multiple GUI elements (e.g., a menu item, toolbar button etc) that all do the same thing, we need to hook up the callback function to each of the GUI elements.

With actions, it's a little different: the action has an "activated" signal. We now only need to connect the callback function to that one signal. Each GUI element is now just attached to the action rather than directly to the code that we want to run.

The advantages of actions are as follows:

• Less code to write: we only need one signal handler for the "activate" signal; not multiple handlers for each GUI event
• Easier look-up: Each action is identified by a unique text ID, and so we can access it by name.
• It is trivial to allow actions (with or without arguments) to be called from the command line.
• There is a built in DBus interface.

Background: Action implementations

There are a few different implementations of actions:

GAction or Gio::Action

These are probably the simplest implementation, and the way we "should" be doing this. The Gio::Action class [1] really just defines a name for the action, along with possible states and parameters.

These actions need to be listed in an action-map, which is essentially a table that lists each action and the function that handles its "activate" signal. There is an action map associated with the application (Gtk::Application or Gio::Application) and an action map associated with windows (Gtk::ApplicationWindow). The latter is useful for window dependent functions like zoom level where two different "views" of the same document can have different zoom levels. Another action map can be "manually" attached to a document to handle document level actions (such as snapping preferences).

Actions are defined in src/actions

Verb to Action Migration

Inkscape has a custom built Verb class that duplicates much of the functionality of Actions. This class has some problems, the biggest is that most Verbs require a desktop. This means that they cannot be used in a headless Inkscape. We are in the process of converting Verbs to Actions. This is a long term process as there are many verbs.

Best Practices

• Tie an action to the appropriate map: Application, Window, or Document.
• Actions should not rely on Window (desktop) unless absolutely necessary (e.g. scale by window pixels).
• If actions need to relay information to the user, use a standard (to be decided) mechanism to isolate dependency on desktop.
  • boolop_display_error_message();
  • selection_display_message();
  • InkErrorHandle (Pops up Error Box) (Derived from silly Inkscape::ErrorReporter class.)
  • Note, a selection does have a link to desktop (which can be nullptr).
• Many actions work on a selection. A standard way to find the selection should be used. (Radical idea, a selection could have an action map.) Selections are tied to windows with a special selection tied to the document in command line mode.
  • get_document_and_selection(app, &document, &selection);
  • app->get_active_selection();
  • At the moment we rely on INKSCAPE.action_context_for_document() to create a selection for a document in command-line mode.

Migrating widgets

Use the following replacements for old GtkAction-based widgets:

• ege-adjustment-action => SpinButtonToolItem
• SPWidget => Nothing... just put your widget directly in the toolbar

Containers

• ConnectorToolbar
• DropperToolbar

Known bugs

• SpinButtonToolItem: Pressing enter or escape does nothing (it should drop focus to canvas)