Port away from `new QAction` retaining i18n strings
ClosedPublic

Authored by abrahams on Oct 30 2015, 6:23 PM.

Details

Summary

This replaces most calls to new QAction with KisActionRegistry::makeQAction(), getting rid of static data in the code.

Now, instead of i18n() calls in the code right next to each action, krita.action (and the other .action files) become the primary source of strings.

To handle this, we make a small modification to the script extractrc, which I've called action_i18n.pl. This is intended for testing, the ultimate goal being to merge the changes to upstream extractrc.

Messages.sh is modified to include action_i18n.pl for the generation of translation strings.

Depends on D478

Tasks: T947

Diff Detail

Repository
R37 Krita
Branch
KisActionRegistry-3
Lint
No Linters Available
Unit
No Unit Test Coverage
abrahams updated this revision to Diff 1114.Oct 30 2015, 6:23 PM
abrahams retitled this revision from to Basic porting away from `new QAction`.
abrahams updated this object.
abrahams edited the test plan for this revision. (Show Details)
abrahams added reviewers: rempt, kossebau.
abrahams retitled this revision from Basic porting away from `new QAction` to Port away from `new QAction` retaining i18n strings.Oct 30 2015, 6:24 PM
abrahams updated this object.Oct 30 2015, 6:26 PM
abrahams updated this object.Oct 30 2015, 6:55 PM
abrahams updated this revision to Diff 1133.Nov 2 2015, 1:31 AM
  • Show shortcuts in groups
rempt edited edge metadata.Nov 3 2015, 7:13 AM

I really like where this is going, but shouldn't the factory class make KisAction?

I agree it would be nicer if KisActionRegistry were a factory for KisActions. There is a problem though.

KisAction is defined in (and cannot be extracted from) krita/ui. KisActionRegistry needs to be used in flake, widgetutils, and so on. Therefore KisActionRegistry has to live in widgetutils, yet it cannot be a factory for KisActions.

There is a separate question of what should be the factory for KisActions. I have found right now that the most natural class for that is KisActionManager, since every call to new KisAction() is followed by KisActionManager::addAction(), so it is straightforward to fold those together into one call, KisActionManager::createAction().

The thing I'm most concerned about here is the i18n. Do you think the the basic idea here is feasible? Since posting this patch I've been following a policy of "get the refactoring done and translation strings can get sorted out in the end" in my local work.

abrahams updated this object.Nov 13 2015, 8:44 AM
abrahams edited edge metadata.
abrahams updated this revision to Diff 1276.Nov 13 2015, 9:26 AM
  • Fix build
This revision was automatically updated to reflect the committed changes.