In D15580#605913, @davidhurka wrote:

In D15580#605611, @simgunz wrote:

aacid requested to write some autotest for the ToggleActionMenu before merging this. I'll merge master in this review and work on the autotests soon.

It’s okay to me that you write the autotests. If you wish, I could do that instead.

I am new to autotests, so I will have to learn how to do that. I am also unsure about what should be tested. The ToggleActionMenu itself, or its behaviour in Okular?

In D15580#605611, @simgunz wrote:

aacid requested to write some autotest for the ToggleActionMenu before merging this. I'll merge master in this review and work on the autotests soon.

This is huge, i would really welcome if it could be moved over to invent.kde.org since i'm 92% sure some of the clazy/clang-tidy checks will fail.

Thanks!

aacid requested to write some autotest for the ToggleActionMenu before merging this. I'll merge master in this review and work on the autotests soon.

Looks like the dependent patch has landed, so we can more forward with this.

I am closing this, as suggested.
The progress of this patch can now be tracked through this merge request.

Could you please discard this and submit it via a merge request in https://invent.kde.org/kde/okular ?

This was landed, maybe phabricator not seeing it because we're using gitlab now

I'm going to merge this because it's been hanging around for more than 6 months and Simone is vouching for it, but honestly for stuff like this we should have UI autotests since it's the thing that will *defenitely* break in the future because it does so many things people will not even be sure what was the intended behaviour.

I compiled and it works. Looks good to me.

• Do modifications suggested by @simgunz

I’m getting a bit dizy about the repository. I thought I merged master, but apparently I made a mistake. Thanks for pointing me along the right way.

• Merge branch 'master' into create-configurable-toggleactionmenu

You need to merge master into this review or rebase because there is a merge conflict. I suggested you the modifications that were introduced in master (qAsConst) and few other changes.

pong :) Sorry, I wasn’t available for the last weeks.

Should be fixed in stable for now.

Very few people know about this problem (es, nl, pt, pt_BR). And even some those who do know just forgot to update the docbook (de, uk). Some docbooks cannot be updated because the translations are now incomplete (et, fr, ru). Thus there should be some coordinated effort to fix this from the translator side.

I guess the translators need to re-generate them

The localized man pages are still broken in 19.12.1 - what does it need to happen for them to pick up the change?

i'd say shelf it for KF6 then, thanks :)

If they have X-KDE-Library=kf5/parts/okularpart then yes, likely.

Does this break generators that are not inside the okular codebase?

Embed JSON metadata

You can always QWebEnginePage::printToPdf and open the PDF depending how terribly slow that is

The only think Okular knows how to show is QImages.

Ahh ok, than I don't know, if porting is even possible, without putting tremendous effort into it. Or QWebEngine somehow gets the featurem to render QImages. But I doubt that, since it is using a completely different render framework.

So Okular would probably need a new Generator base class, to display HTML Documents using QWebEngine?

there is a kchmviewer that uses qtwebengine directly for rendering. I don't know how that fits in the okular way of doing things.

Okular already uses the kchmviewer backend code, which supports two modes, QWebEngine and using KTHML. But switching to QWebEngine would break the current workflow used in okular, which is basically to render a page with khtml as a QImage and than return this QImage. AFAIK this is not possible with QWebEngine. So Okular would probably need a new Generator base class, to display HTML Documents using QWebEngine?

@davidhurka friendly ping. :)

In D26190#582672, @arojas wrote:

In D26190#582670, @aacid wrote:

You should have commited this to the stable branch and then merged to master.

I'll cherry-pick -x to stable now, it's worse, but relatively acceptable

I assumed this was a string freeze break since the page is localized.

In D26190#582670, @aacid wrote:

You should have commited this to the stable branch and then merged to master.

I'll cherry-pick -x to stable now, it's worse, but relatively acceptable

You should have commited this to the stable branch and then merged to master.

In D26190#582196, @ltoscano wrote:

Uhm, but it shouldn't be an issue, really. As a workaround this is fine, but maybe an XSLT issue? Why was this seen only on Arch?

Uhm, but it shouldn't be an issue, really. As a workaround this is fine, but maybe an XSLT issue? Why was this seen only on Arch?

Fine if it works for you. Thanks.

Thanks for the research and additional information. Indeed in the light of this, this patch has to wait until the KF6 branching. Putting it on hold for now.

Oh, and the Calligra plugins for Okular (edit: when used with the KPart) will also break, as they (edit: desktop files they deploy for that use-case) also have X-KDE-Library=okularpart, given then they also work by being subplugins to the Okular KPart binary, so need to reference it,

At least Kile tries to load the Okular KPart via the binary name and using the constructor of KPluginLoader which only searches in the normal Qt plugin paths, not subdirs, Possibly there are others who copied that code. No idea what to do, besides promoting the use of metadata-based plugin searching...

In fact, webenginepart and others had a better idea already: plugins/kf5/parts.

Actually, let's make it plugins/kparts for proper namespacing.

It does not compile indeed. My fault in the review process, I missed the last commit. I have added the inline comments to fix the bug.

Needs a rebase for sure

Is it me or this thing doesn't compile?

Created a pull request on invent.kde.org. https://invent.kde.org/kde/okular/merge_requests/73

Trying to land this diff I get these errors:

Ping

The class has the features needed for both D15580 and D21195 and I do not see evident bugs. For me, this revision is good enough for now, and in case we can fix it later (it used in few places so it should not be hard to adapt the code if needed).

Moved to GitLab: https://invent.kde.org/kde/okular/merge_requests/71

Sorry, this technical discussion is beyond me. :)

This was moved to invent at https://invent.kde.org/kde/okular/merge_requests/22

Rebase.

In D25684#572361, @aacid wrote:

Please rebase your patch on current master, since it will fail to merge properly, i prefer you do the work and not me ^_^

Please rebase your patch on current master, since it will fail to merge properly, i prefer you do the work and not me ^_^

::distanceSqr() is going to be made const, so qAsConst isn't needed
It's cheaper to copy basic types than reference them
qAsConst isn't needed when iterating over member variable containers in const methods

Thanks for the patch!

Moved to https://invent.kde.org/kde/okular/merge_requests/69 .

Since you've moved it over there, you can Abandon this from the Add Action... menu.

An MR is drafted at invent, see https://invent.kde.org/kde/okular/merge_requests/69 .

Yes, I have found this, if okular is build / using new poppler versions, but I don't know why. (poppler version poppler-0.77.0 and poppler-0.62.0 is working)

Behaviorally this works great, but visually there's now a big regression: the content itself is no longer visible during the zoom operation; the view blanks out and displays the default white background.

rebase

Moved to gitlab.

Can you put this on invent instead?

In D25628#569866, @davidhurka wrote:

Hey Yegor, I like this idea.

Hi @davidhurka, thank you

Hey Yegor, I like this idea. I’m not sure what you mean with adding visual controls.

It took me a while to realize what the feature was, but now that I do, I think I would prefer it to the normal method of scrolling. As someone who frequently loses their place while reading, this would help a lot with that.

Fixed code styles

Thanks, this looks great. It works just fine and the UI seems sane to me. I have some code comments:

• Added "undo tab close"
• Added a test

I think we can assume that, but check in the code. I don't think we necessarily need to save anything in memory except the URL for the document shown in the closed tab.

In D25484#567258, @ngraham wrote:

Yes this helps the case that @pino brings up, but it handles a different use case. Most of the time a tab won't have unsaved changes because Okular is primarily a reading app. An "Undo last closed tab" feature is for these other cases.

In D25484#567112, @bdbai wrote:

In D25484#566490, @pino wrote:

...

In D25484#566483, @romangg wrote:

The solution to accidentally clicks is not disabling it by default and making it configurable, but providing the functionality to "restore" a tab after closing it accidentally. Dolphin and Chrome allow me to restore the last closed tab with Ctrl+Shift+T.

And this "solution" does not always work, for example when a page was the result of a form submission, redirection, or other kind of interactivity.

@ngraham In Okular, when a tab with unsaved changes is about to close, the user will be prompted first. Does this help?

In D25484#566490, @pino wrote:

...

In D25484#566483, @romangg wrote:

The solution to accidentally clicks is not disabling it by default and making it configurable, but providing the functionality to "restore" a tab after closing it accidentally. Dolphin and Chrome allow me to restore the last closed tab with Ctrl+Shift+T.

And this "solution" does not always work, for example when a page was the result of a form submission, redirection, or other kind of interactivity.

The KDE Community is transitioning away from Phabricator and towards GitLab. The transition is not yet complete, which is why the documentation still points you towards Phab. Individual apps--such as Okular--have already made the jump as "early adopters", so to speak.

In D25484#567076, @aacid wrote:

...
Also please remember to use invent.kde.org and not phabricator for okular merge requests

As a sidenote i don't think this makes sense at all, but i don't think allowing tabs in okular makes sense either and i let them in so i'll just say it and then go back to my cave

Remember any UI change as this should have it's UI autotest to make sure things don't break in the future.

Undoable tab closing seems totally uncontroversial to me. Web browsers have it, Dolphin has it... It's really just a matter of consistency. On that subject, here's how Dolphin does it: