Very nice!

Awesome!

Rebase on master.

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.

If you say “at this low level”, would being more abstract make more sense?

I haven't tested it and haven't tried understanding the code farther than "this is a bunch of painting code".

Honestly i don't think documenting things at this low level makes sense, it'll break because people will never remember to update comments even if it's just on the line above the code they are changing.

I’m complaining a lot about the source code. Don’t understand that as arrogant demand to fix it, just tell me to do it. Anyway, the code works, so no need to change it?

Giving up for today, there are sooooo many functions of the format open*(url).

Now if somebody spends time testing this and makes sure it doesn't regress for the rest of us using reasonable pakcages i'm not against this landing.

You're hurting yourself for no reason. You either stay in old versions or use new versions. Mix and match is a good recipe for pain like you're experiencing here.

Don't draw a line end if line end style is LineAnnotation::None.

Did exactly this (and some more)

• Improve code documentation of updateViewActions() and showMenu()
• Document random member functions of Part, including showMenu()
• Document more random member functions of Part, including openUrl(), and improve thats code comments
• Document even more open*(url) functions, and slotPrint(). Also complain about source code.
• Remove TODOs (but not all)

In D21364#469241, @jangmarker wrote:

Now it looks like this:

Looks ok, but if someone makes PageViewAnnotator::makeToolPixmap() return a QIcon(Engine) instead of a pixmap, it will look better.

Why do you move EditAnnotToolDialog to GuiUtils? / How does the annotation tool bar (shown with F6) get its icons?

In D21376#469822, @davidhurka wrote:

Your code:

Wouldn’t static_cast<>() be better than a C-style cast?

You are not touching “Highlight with Comment”-style texts, which is probably good. (And would fit in another commit anyway.)
There was a discussion about this in D10797, and in T8533 in more general, but this patch is probably fine.
(T8533 is why I thought the annotations would have been y-ordered.)

Add some const.

My OS (AstraLinux) is based on Debian stretch and has poppler 0.48, Qt 5.11, KF5 5.46.
And probably it will be a headache to update poppler on it, cause it's rather low-level library (cups-filters depends on it).

Would be easier to test this change if it is rebased against current master, as many changes landed in annotationwidgets.{h,cpp} recently.

Thanks. If nobody objects I'll land this tomorrow.

This change doesn't cleanly apply on the current master branch. Would you rebase the changes, or is there a branch it could be built against (I don't see annotation-toolbar branch yet)?

Add Q_ASSERT for the configs.

One proposal i have is actually saying we don't support poppler 0.50

Fix crash, m_{start,end}StyleCombo are guarded by m_lineType == 0 check for Straight Line tool.

Now it looks like this:

Instead of showing colorful rectangles, use same icons as for annotation tool

In D21364#469215, @davidhurka wrote:

In D21364#469159, @jangmarker wrote:

I think captionForAnnotation() does not include the comment's text currently, so this change should probably be done in another commit.

It would make sense to show icons to indicate the annotation type, e.g. a different icon for highlight, freehand lines, underlines etc. And if these were colored according to the annotation's color, that would be perfect IMO.

That’s what I meant. :)

In D21364#469159, @jangmarker wrote:

I think captionForAnnotation() does not include the comment's text currently, so this change should probably be done in another commit.

In D21364#469111, @davidhurka wrote:

Nice, makes the list more intuitive. :) (Didn’t test this)

Thank you :-) Currently it looks like this:

Nice, makes the list more intuitive. :) (Didn’t test this)

Sorry. I didn't add #include <config-okular-poppler.h> to formfields.h.
Correct fix: D21363.

In D21332#468893, @tobiasdeiminger wrote:

Btw., can we do polylines yet? The only way I found was to tweak engine points attribute for tool type straight-line in ~/.config/okularpartrc.

Rebase against current master

arc patch fails, could you please rebase on current master? You may also want to add CCBUG: 381629 to the description.

My error. Apologies!

makes sense

ok, i guess, the padding was a bit arbitrary and to first page only anyway ^_^

Makes sense

I've reverted the changeset since it was breaking the build

This broke the compilation process on my machine. I just tested with a clean version of KDE Neon, Poppler 0.62, and it doesn't compile, something about FormFieldsSignatures.

Probably it should be described how dropped URLs are handled in general? Sometimes the Part uses them and wildly opens files, sometimes not.

• Part::Part() 'QObject is a widget' -> 'QObject is an object'
• Document some D-Bus methods and Part signals, minor improvements in Document

Documentation and fixing spaces

Implemented setInterval/clearInterval. WidgetScripts are now supported on pageOpening/Closing.

Thanks everybody

In D21238#468127, @tobiasdeiminger wrote:

@knambiar The config dialog for polygon annotations has seemingly regressed with recent changes:

So I will keep it this way.

Their user interfaces are different; the selection button offers three different types of selections, but allows a click-and-don't-hold to activate the last one. I'm not the hugest fan of this UI; I would prefer three different buttons or a dropdown menu that opens on click-and-don't-hold. But there's no reason to emulate it since the UI you have here is different.

In D21195#468008, @ngraham wrote:

+1 for this. I think it makes sense. Trying it out, I like it a lot.

In D21202#466067, @joaonetto wrote:

In D21202#466066, @aacid wrote:

Do you have some files that exercise this?

Who would we autotest this?

I intend to test this when all the functions needed to work are implemented.

Or would you like a test for every function?

@knambiar The config dialog for polygon annotations has seemingly regressed with recent changes:

Thanks @aacid. I've tested this and verified that it works. The code changes are a little bit over my head but @sander has reviewed them. I think it makes sense to land this.

Fix review comments. Minor cleanups.

Please revert the QStringLiteral with utf8 inside, after that you can commit if you're convince there will be no regressions :)

I have not reviewed this, i am not thrilled about the licensing situation, but at least relicensing wouldn't be harder than for other people so if other people have reviewed this and made sure it breaks nothing and is a good improvement i won't get mad if this lands.

Moving Continuous into the sub-menu amounts to a regression for menubar users since it becomes less noticeable in there. However I think there's an obvious solution: add the View Mode action to the default toobar, next to the Zoom combobox. Then all of this functionality becomes much much more noticeable for everyone, which is good because it's a part of the core functionality IMO.

+1 for this. I think it makes sense. Trying it out, I like it a lot.

Ping ?

• NormalizedPoint: Revert some stuff and mention mouse click events

Should the section “Coordinate System” of NormalizedPoint mention the “Trimmed Margins” feature? To prevent that someone sloppily codes a feature, which draws something on the page and fails if Trim Margins is active.

The part is created by the shell, see around line 85.

In D21281#467283, @aacid wrote:

In D21281#466844, @davidhurka wrote:

Is there some more KParts literature? I could find KParts on api.kde.org and the tutorials on community.kde.org, but couldn’t really transfer that to Okular.

Why you couldn't transfer it to okular? If you don't say what you don't understand is hard to explain *everything*

@aacid ping?