• Add warning regarding broken stamp support in PDF

@andreask Given that you gave your availabilty to work on the new Okular icons, I have opened this bug (408283) with a (messy) list of what icons are needed. I did not provide icon names yet.

In D22064#498964, @aacid wrote:

Small code improvements that can be ignored if you want.

• Move to init list
• Add translation context
• Use new connect syntax
• Add tooltip to custom stamp button

Do you have to move this to gitlab anyway?

@davidhurka Thanks for looking up the bug numbers

Fix bad rebase

I messed up something... I see many files I have not modified that are marked as modified here. Probably because I changed the origin remote and my master was not in sync with upstream. I'll fix this with the next arc diff, now it does not let me arc diff again because it says that the diff is empty.

• Fix action deselected if favorite tool with the same type is activated
• Fix geom shapes action disabled when okular reparses config
• Disable text annotation when file does not support them

In T8076#186897, @davidhurka wrote:

How will you do what currently a double-click does? It should still be possible to do more than one annotation in one go.

• Add i18n
• Move default value to declaration
• Add tooltips

I have managed to re-enable the action Tools > Review to show/hide the annotation toolbar.

• Clean parseTool
• Initialize private members
• Add action to toggle annotation toolbar, set default position below

@aacid Can you also have a look at this revision when you have the time?

In D21156#486870, @kfunk wrote:

Oh, I usually squash my changes into the original commit before uploading the change (i.e. via arc diff). I do not use an extra branch either.

Phew. Anyhow. Let me sum this all up with: Please make your life easier and rather start using KDE's GitLab instance: It's much easier to use since it shares the same workflow as all other major Git hosting platforms out there: https://invent.kde.org/kde/kdevelop

Phabricator is just horrible to adapt to and integrates badly with the usual Git workflow. For KDE development, Phabricator will likely be displaced by GitLab anyway in near future.

In D21156#486838, @kfunk wrote:

Huh? It's easier than that:

• If you do not have the commit yet locally:
  
  ` arc patch --nobranch <ID> git push `

Or probably a simpler approach is to run these two commands irregarding the fact that I have the commits locally or not. So I just pull the 'clean' modification with the correct commit message and then push to a target branch. E.g: git push origin 5.3

• If you do have the commit and it is the latest one in your history: ` arc amend git push `

Sorry but it is still not clear if this would work. In this diff I have three commits (modification_1, modification_2, revert modifications_2) in a feature branch forked from master. I need to push to 5.3. If I run those two commands I expect that three commits are pushed (not a single one with the total modification) and I would expect that those are pushed to origin/my-feature-branch not in 5.3. Isn't it?

Wouldn't make more sense to do arc land --onto 5.3 (and then merge 5.3 into master)? In this way the Differential Revision would be closed automatically.

I suggest to do a arc amend (to basically update the commit message with current reviewers, "Differentiatl Revision" line, etc.) and then git push your change manually to the right branch. Let's you use your normal git command-line to actually push changes, which to me is a much more thrust-worthy approach than to rely on arc to do that for me...

In D21156#486717, @aacid wrote:

If you're not using arc you should have included the "Differential Revision" line in the commit so it would close automatically as stated in https://community.kde.org/Policies/Commit_Policy#Special_keywords_in_GIT_and_SVN_log_messages

I'll close this manually for you :)

Added the enum, much better now.

• Define enum for preview position

I have pushed to 5.3 and then merged to master manually, as specified in the Phabricator page guide. How do I close the revision now?

@yurchor Are you willing to update the documentation regarding this modification after we merge this? (I saw you changed the doc regarding the refactor of the annotation tools config dialogs, and it seems you have experience with the documentation aspect).

@sander Thanks. It worked.

Tried to land this, but I got this error message:

Perfect. I can land this tomorrow evening.

Just waiting for your OK.

In D21755#483532, @davidhurka wrote:

In D21755#482891, @simgunz wrote:

I have tested this patch and added some inline comments. It seems to me that ToggleActionMenu requires way more external code to make it work, compared to ToolAction, which is quite automated. I think that some things could be made default in ToggleActionMenu, and some aspect hidden as well e.g. manage the QActionGroup internally without having the user have to manage it and set the action eveytime.

What would be a use case for an integrated QActionGroup? At least it couldn’t be used for the Selection Tools menu, because there are more mouse modes.

To be more clear, I think that the code below should provide a default working action menu (basically as it was before, but customizable if necessary):

I have tested this patch and added some inline comments. It seems to me that ToggleActionMenu requires way more external code to make it work, compared to ToolAction, which is quite automated. I think that some things could be made default in ToggleActionMenu, and some aspect hidden as well e.g. manage the QActionGroup internally without having the user have to manage it and set the action eveytime.

• Remove unuseful annotation separators
• Correctly set favorites action enabled
• Properly trigger favorite action
• Allow unchecking annotation actions
• Minor refactor
• Save state of continuous mode

• Document feature

I reverted the commit were the Ctrl feature was disabled, going back to the first fix I proposed

In D15580#481323, @davidhurka wrote:

Don’t have UI feedback that asks for action already in this patch. :)

In D15580#481270, @simgunz wrote:

• Maybe the 4 left buttons should indicate that they require further action (drawing). Currently they look like buttons in a word processor, where you have to select the text first. *1) Using the existing dynamic annotation icons might look better, as soon as someone made them more low-resolution friently.

• Fix and simplify width action
• Fix and simplify opacity action
• Fix annotation tools actions
• Rename color action
• Formatting

In D21755#481293, @davidhurka wrote:

In D21755#481269, @simgunz wrote:

Currently I am using ToolAction in the new annotation toolbar to selected among different geometrical annotation. [...]
For this purpose I need that the action are checkable, and that the ToggleActionMenu is checkable displaying the selected action (exaclty as ToolAction).

[...] For my use case, I would probably need to be able to display tooltips for each action in the ToggleActionMenu, to describe what they are.

[...] I need to use it for Geometrical annotations and for the Stamp annotation. For this last one I would need to display the different available stamps, so each action in the ToggleActionMenu should just be a checkable action with a full width image and no text. [...]

Maybe it’s better to use a KSelectAction directly? Not sure whether it shows the current selection on the toolbar button, but probably it does so in combobox mode.

For the stamps, you probably need a combobox with a custom item view.

Favorite annotations:
The Star adds the currently selected tool to the favorite list, the bookmark symbol displays the list of the favorite tools:

In D21755#480908, @davidhurka wrote:

From my point of view, this is complete now. 3 TODOs left (see revision description at the top).

ToolAction used its own tooltip for the toolbar buttons. Tell me if that is still needed.

@simgunz you just told that you will use ToolAction? If you show me your implementation, it’s ok for me to use that instead. Otherwise you can tell me what you need (tooltips?). :)

Added the favorite tools.

• Added opacity action
• Cleaned width action
• Added action to access advanced settings for all annotations
• Big code refactor:
  • m_toolDefinition is now a QDomDocument, so that the toolElement are not randomly deleted when the associated QDomDocument goes out of scope.
  • AnnotationActionHandler acts directly on PageViewAnnotator instead of emitting signals
• Further code cleaning in pageview.cpp
• Annotations work only in Normal mouse mode, and switch to it when they are selected

• Fix code formatting

• Properly cast QObject

Fix author accelerator, remove 'for pdf only' tooltips

I renamed PageViewToolBar and moved to a file by itself. I took inspiration from Dolphin for the name.

• Use draw-polyline icon for Polygon
• Increase version of part.rc
• Change icon of strikethrough (remove symbolic suffix)
• Add TODO in code
• Rename PageViewToolBar to AnnotationActionHandler
• No need to forceHide mechanism
• Use KToggleAnnotationToolBar to show/hide toolbar (not working)

In D15580#474436, @simgunz wrote:

Or: Why is this still PageViewToolBar? It is not anymore in the PageView?

I'll move it, added to TODO

Or: Why is this still PageViewToolBar? It is not anymore in the PageView?

If we remove the sticky button, we have two options:

• set sticky by default, we will make some users that use the non-sticky mode unhappy
• set non-sticky by default and use double click to stick, we go back to the current situation (bug 358057)

I we keep the sticky button, the double click to stick becomes pretty irrelevant.

There is a TODO list of the working and planned feature on task T8076. Some of your suggestions are already there and I added the missing one. I have updated the description of this review to point to that TODO for better clarity.

Probably the current “implicit” tool should be configurable trough the dialog too, so not all controls need to be in the toolbar, but the user does not need to make a favourite for a very special annotation he/she will use only once. (This is probably what you meant in the second section.)

Just pushed few more changes to the toolbar.

In my opinion we should not aim at something extremely complicated and fully featured as the CAD one (no one actually requested this feature as far as I know). I was more thinking at reducing the clutter in the straight line annotation tool, by creating a sort of clone of it dedicated to this 'dimension line'. So expose the possiblity to add text and avoid the conflicting line ending / leader line.

Still very rough, but most of the tools and corresponding basic settings are now there.

• Change string that inform the user about how Identity info are used

What should we do regarding the message at line 71 of conf/dlgannotationsbase.ui ? I think is the last thing to possibly change.