In D15347#496156, @sander wrote:

In bug 409638 it's probably a TabletEnterProximity event instead.

That's unlikely, because TabletEnterProximityEvents are a bit special. From https://doc.qt.io/qt-5/qtabletevent.html :

"The [...] TabletEnterProximity and TabletLeaveProximity [...] are only sent to QApplication"

Interestingly, if we remove QTest::mouseMove and just keep QTest::mouseClick in above test, the test passes OK as expected.

In D15347#495392, @sander wrote:

Agreed. I think the first step should be to write a unit test that triggers https://bugs.kde.org/show_bug.cgi?id=409638. That way we get a reproducible way to trigger the problem even for people without a stylus.

In D15347#495182, @sander wrote:

@tobiasdeiminger , that hidden bug you mention, could it be the cause of https://bugs.kde.org/show_bug.cgi?id=409638 ?

In D21836#482214, @sander wrote:

Ping?

Sorry, just realized my above comments are somewhat off-topic as long as the title of T11014 is Dimension line annotation tool. Can we broaden it to cover line annotations as a whole? Or shall we open additional tasks?

In T11014#186870, @simgunz wrote:

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'.

In T11014#186860, @davidhurka wrote:

Then it’s time I want to ask this:

Why do we need dimension annotations? Just because it’s almost implemented with Straight Line as defined in PDF? Okular is not a CAD tool, and PDF documents usually do not have all the information needed for dimensioning.

In T11014#186857, @davidhurka wrote:

Moving sideways is probably not possible, but moving up and down would change the lenght of the leader lines.

In D21416#472774, @davidhurka wrote:

Not wrong but not important. How often does one change the color theme while chosing a line ending? I could only imagine that the color theme changes automatically based on enviromnent light sensors, for people who work in a vehicle passing many tunnels. But how often does one chose the line ending while entering/leaving a tunnel the same time?

In D21416#471897, @tobiasdeiminger wrote:

In D21416#471795, @davidhurka wrote:

For dark color themes: maybe the color of the adjacent text would be good as foreground color for the icons. Don’t know, but maybe QGuiApplication::pallete().color(QPalette::WindowText)?

Makes sense, thanks. Never tried this before, give me some time to check it out...

Consider QGuiApplication::palette, to improve icon visibility in dark themes.

In D21248#470113, @aacid wrote:

I'd say give it some time (a week?) in case people want to review and otherwise just commit it.

Renamed transformation arguments to make it a bit clearer what they are doing.

Does anybody feel like adding a nice UI for this feature? :-)

In D21416#471795, @davidhurka wrote:

For dark color themes: maybe the color of the adjacent text would be good as foreground color for the icons. Don’t know, but maybe QGuiApplication::pallete().color(QPalette::WindowText)?

Define TermStyle list outside the loop.

Rebase on master.

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

Add some const.

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

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

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

Fix review comments. Minor cleanups.

• rebase on master
• remove the "Only for PDF documents" tooltips
• change drawing of (R)OpenArrow, (R)ClosedArrow, Slash so that combination with leader line makes sense for dimensioning purpose (I think poppler should be adapted accordingly)
• fix drawing leader lines

Added circle, expose LineAnnotPainer.

Thanks, LGTM. If nobody objects I'll accept and land this on master the day after tomorrow.

What about QMatrix or QTransform?

Thanks, using QTransform now, it's already widely used in Okular.

@knambiar If this once lands, you can remove your "for PDF only" tooltip.

@aacid Should this small fix land on Applications/19.04 branch, or master only?

In D21092#465127, @sander wrote:

I'm afraid we'll have similar objections to the endStyle, though, specifically “PDF only” — would that be okay?

IMO it would be okay. Plus, with the help of Tobias maybe you can even teach Okular how to draw the start/end markers for non-pdf documents in a separate patch? I remember him saying that that is not very difficult.

@knambiar
Rajeesh, would you be around for another patch? PDF / poppler allow to draw arrows on both ends of a line (aka start style, end style). Your patches currently target only the line end. Would you implement "start style" in the UI too?

There's a few #ifdef HAVE_POPPLER_mm_nn checks in the code, may be we could adapt it for 0.72?

What would be a better alternative?

At least squares and diamonds are incorrect, too.

Ok, so at least we're consistent in doing wrong :) I'll fix it.

In D20760#461314, @sander wrote:

At least squares and diamonds are incorrect, too.

In D20760#461261, @sander wrote:

Is this really how they are supposed to look? If not, is this a poppler bug, or is Okular missing some further line ending setup code?

In D20760#456328, @davidhurka wrote:

Isn’t there a coding convention against non-ascii symbols in source code?

In D20760#455307, @knambiar wrote:

In D20760#455290, @tobiasdeiminger wrote:

Would it be useful if I tried to provide an SVG as replacement for the unicode symbols in an upcoming version, to resemble the exact line end drawing instructions as we do them in poppler code?

Certainly. Meanwhile I read the documentation and see that QComboBox::setItemIcon can be used to set the icon for combo box text.

In D20760#455266, @knambiar wrote:

Add Unicode symbols to the line ending style. Didn’t find suitable symbols for ‘Right Closed Arrow’ and ‘Slash’.

• Add test to check PageView position after Document::setViewportPage
• Fix review issues

In D16941#366267, @sander wrote:

It passes on my Debian Testing laptop.

In D16941#364473, @aacid wrote:

How hard would be to extend the test to do a F5/refresh and check position is the same? That was also a bug and this fixes it, right?

Add test to check PageView position after Document::setViewportPage

@aacid When is the last chance to get something into 18.12 release? Already passed?

In D16941#361164, @sander wrote:

It is still not perfect

Assert correctly.

In D16941#360741, @aacid wrote:

Can we have an autotest?

In D16457#350089, @aacid wrote:

I.e. if desiredTab is 4 but openinng url 1 fails we need to use 3 as desiredTab and not 4.

In D16457#350089, @aacid wrote:

we should count the number of times openUrl fails and adapt desiredTab accordingly.