• Rename "Size" to "Width"
• Set better accelerators

Yes I meant the brushes (that behave as the freehand annotation). For me setting it to Width is fine.

• Add opacity spin to file attachment annotation

• Add color button and opacity spin manually in each annotation
• Add vertical space to separate groups of settings

Not only straight line, but also freehand line, geometrical shape and polygon (with the same meaning). I agree with you, but on the other hand in drawing software like Krita or Gimp it is called Size so maybe the users are used to it. I have not a strong preference on this matter.

I am also in favor of the white space. Lines or group boxes seem to me too heavy for this type of configuration (and it is what I wanted to remove in the first place). Any idea on how to add the vertical white space in a QFormLayout?

• Fix label buddy not working of PixmapPreviewSelector
• Fix keyboard shortcut of Author conflicts with Add (now selected automatically)
• Same order of Size and Fill color for GeomShape and Polygon
• Make annotation type the first element before color

Hi,
yes I can try to think of something to expose this feature. As @tobiasdeiminger suggested, I would open a task regarding the straight line tool, where we can also discuss the point on how to deal with the proper line ending (see BUG: 407463). I would like to first push my changes regarding the new annotation toolbar, so we can discuss how to expose this feature, also taking into consideration that new interface.

Using the QFormLayout simplified the code a quite a bit!

• Use form layout instead of grid layout
• Set label alignment and field growth policy
• Resort code of line annotation
• Fix wrong widget set as parent
• Move line termination styles before leaders style
• Align combobox to top

So in createAppearanceWidget() we create a QFormLayout (instead that a QGridLayout) and then this is passed down to all the createStyleWidget methods, is that ok?

"Shape fill" maybe can be renamed "Fill color".

Here a visual list of all the modifications:

Rebase to master, fix layout of FileAttachment and Caret

This diff was on hold because of the work I am doing on the new annotation toolbar, that may make all the annotation configuration dialogs obsolete. But I now think those dialogs may still be useful, so that we can move this review forward. I am going to rebase it and possibly fix the layout of the newly added fields in a few days.

I am going to rebase it to master and push some new changes in a few days.

In D21156#465844, @mwolff wrote:

you are removing a feature, but only partially - a lot of code would become superfluous by this change and should be cleaned up accordingly

With the Alt key the bug does not appear, because the existing code disables correctly the browse mode when Alt is released. For some reasons key press and release events are different for Ctrl key but are the same for Alt. Probably the method avoidMenuAltFocus manages this behavior correctly for the Alt key (I have not analyzed in detail what it does) and then we enter correctly in the if at line 230 where source browse mode is disabled. So removing the redundant Ctrl key solves the bug completely (at least I haven't manage to reproduce it).

• Disable Ctrl and keep only Alt

@ngraham Thanks for the guidelines

I never landed a diff before because I just got my KDE developer account.
Few general questions:

• Is it enough that one reviewer accept the revision, or all the listed ones should accept it? (or depends on the project?)
• Can I directly land it once the condition above is satisfied, or is it always better to ask before landing it?

Perfect. Thanks!

• Revert lessons ids
• Substitude non ASCII characters

Note that the uuid of the course is the same while the uuids of the lessons have changed. Not sure what should be changed and what not.

Maybe @andreask knows what are the most suitable icons to use.

Yes, that is what I meant.

Point 2:
Probably the collapsed by default (current situation) is ok if there is the button.

I use the side review panel only when I need to go through all the reviews one by one, so it is annoying having to expand all the elements by hand. Maybe a expand/collapse all solution would be a better solution. (The long answer is in T8553 ).

Elaborating a bit on why I proposed some changes based on my main usage pattern.

I have not even started working on this task, so your help is more than welcome. I agree that may be useful discussing the points before writing too much code. In particular, I think that the architecture of the proxy model should be done properly given that it is the culprit of some points in the list. For me it was not straightforward how to implement it properly.

Ok, I think it should be ok now.

• Add lesson with all accented letters, better word balance for rare words

I would like to add few improvements to this lesson (to fix few problems I am noticing only now), so I ask you to wait before working on this review.

I completely agree with you, having two different lessons can be beneficial.

• Fix lesson title and description

In D15580#339425, @ngraham wrote:

To test this revision
Temporary move the file .config/okularpartrc or the annotation tools may not match the ones in the buttons.

This won't be a necessity for the final version, right? We wouldn't want users to have to do this.

In T8076#163208, @ngraham wrote:

I finally got the chance to test out D15580. Overall pretty nice! Since I noticed many bugs (e.g. with certain tools creating the wrong annotation), I assume it's a work in progress, which is just fine!

Current situation on a 1680px wide screen:

@ngraham @tobiasdeiminger See bug 399362 regarding the long pressing of the buttons. I'll put all the items by themselves in the new annotation toolbar, there should be enough space.

Should compile now. Typewriter tool is not included yet. I add few more actions but the color picker works only for text annotation tools for now.

• Check if chosen color is valid before storing it
• Notify PageViewAnnotator when the color has changed
• Add missing annotation tools actions
• Add XML annotation tools and connect corresponding actions

Another UI problem to solve is how to deal with some specific annotation tools "advanced" configurations:

• Some tools have an icon (popup note, stamp)
• Straight line tool has Line extensions
• Inline note has font, font size, alignment

Yours should go first. I think the toolbar thing is going to take some time both because I'll work on it intermittently and because it may require many changes under the hood. Let's see if I can manage to get it ready for KDE Applications 18.12.

@tobiasdeiminger ..and yes I would like to coordinate so we don't waste effort.

@tobiasdeiminger mentioned in D15580 that long pressing to select different geometrical shapes (polygon, ellipse) is not very intuitive. I agree on this. I implemented it that way to be consistent with the other tool buttons of okular, for example the selection button (text selection, table selection, ...). In particular the buttons are based on ToolAction which derives from KSelectAction. I would change the default button mode of ToolAction to QToolButton::MenuButtonPopup, but I believe we can open a new bug for this and do it for all Okular buttons.

@tobiasdeiminger I'll continue the discussion on the task T8076 related to this diff. So we can discuss the more UI related topics there.

I have added the revision D15580 where I implemented a first (very rough) version of the toolbar, so we can start discussing the best way to implement it.

To test this code temporary move .config/okularpartrc or the annotation tools may not match the ones in the buttons.

Just tested again with my solution on top of sander one and the bottom border disappears, but not the upper one. Strange, I didn't remember this effect when I tested it months ago.

I arrive a little late, but testing Okular today I noticed a minor bug with your solution. If you slowly scroll the page by dragging it with the browse tool the upper/lower dark border are not drawn sometimes when the word is at the border of the page. See bug 398553. With the "solution" I proposed instead this was not happening IIRC.

Much better now. Thanks!

I was thinking that a way to facilitate a newcomer getting into a project could be to find him a code buddy, another newcomer working on the same project.

The link to the Mentoring page is literally the last word of the Getting involved page. I did read the getting involved page (maybe with not too much attention), but I did not reach the mentoring page and did not figured out I could contact a developer directly. Maybe this link can be highlight better somehow?

I repost here the comment previously posted in T7116 as requested by @neofytosk on my personal experience with the setup of the development environment.

@andreask Thanks for the quick reply. I'll soon make a list of the icons required and let you know.

Here are my 2 cents.

Ok, thanks for testing again. I re-tried your patch with the latest master (just to check that there weren't modifications that solved the problem) and I still can reproduce the error. With my modification it goes away. So let's wait for aacid to review the diff.

This is a first mockup of the annotation toolbar.

Have you tried also what I suggested to reproduce it? i.e. Position an highlighted word that match the search at the top boundary of the view so that it is half visible and then scroll to show it completely. (Just to confirm this is not reproducible)

@sander Have you had the time to try the fix I suggested?

• Focus text edit of annotation when double-clicking on annotation icon

I'll have a look at it. I think that focusing it makes sense also to locate which popup note is associated with the annotation clicked (especially if they are not overlapped).

Indeed I noticed that analyzing the code. I'll try to rewrite the proxies to solve these problems.