@dfaure David, what is correct, should the part or the shell provide the print action?

Any reason you guys decided to not involve security@kde.org ?

When double clicking an already open annotation, we bring it to front, but it doesn't get keyboard focus (the text cursos doesn't blink), which is a different behaviour from when the annocation is closed.

Are you sure you need s_doNotDeleteLinks ? I mean the links where deleting in resolveMediaLinks doesn't look like they can be nextActions, since it's the Opening/Closing/Activation actions we're resolving on

void PDFGenerator::resolveMediaLinkReferences( Okular::Page *page )

no?

ok

ok, i guess

I'll land it

In D10932#248786, @ngraham wrote:

+1 for keeping this open and refining the behavior rather than abandoning it.

In D10932#248618, @rkflx wrote:

FWIW, Foxit Reader does have a Reset Form button, which upon clicking shows a dialog asking "This option will reset all form fields to their default values. You may lose some data. Are you sure?".

Let me know if you have specific example documents I should test this applications with, to see how they solved some of the more complicated aspects.

Do you have a game number we can use to compare how this is better than the existing code?

Ok, i guess, after all you're the maintainer now so i shouldn't be blocking your changes ;)

Ok

threre's not so many unneded stuff in there to be honest, maybe kross, kate and the emoticonthemes, but doesn't seem terrible. One would improve that by not depending on the whole kf5umbrella probably?

"Fix Page and Author tree elements are collapsed at every change of page when "Show revisions for current page only" is selected" is probably the same root cause as " Do not collapse tree elements when adding a new annotation". The proxymodels are not very well coded, basically rebuildIndexes does resetModel all the time, which is very bad.

For symmetry i will add the disconnect line in the setSourceModel, i'm not even sure we even use that if codepath but it's nice to be symmetric

yeah i think that's easier to understand

All the other elements of that list have an entry like

I'm a bit unhappy about the icon duplication, but that's life i guess :/

In D12171#248840, @hein wrote:

Personally I sort of, well, hate this and it was a very conscious design decision to make the menu widths uniform, so I'd like some more VDG opinions to convince me otherwise first.

Sorry for the late answer.

Looks like it works, i'll commit in a minute (with a small improvement from my side).

I'll push it, i've fixed the removal of the #if 0 in scripter.cpp

I honestly don't see the need to install stuff in a non standard folder.

I'm not convinced at all parts are not in that folder.

This doesn't seem to work

HAVE_KWALLET is never defined

This is not ok.

This is how it looks now

Hmmm, not happy with things that need to be updated manually for each release :/

is appendix something people would understand? because for me is "the things that kills you if you're unlucky", "the end chapter of a book".

In T8426#138032, @ngraham wrote:

In T8426#138029, @ltoscano wrote:

@mak the context is in the previous messages, but tl;dr: are the releases.release tags supposed to

• contain release notes in addition to few metadata
• be translatable? A quick read of https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html seems to point to "no" for both.

I think you missed this part:

Each release tag may have a description tag as child, containing a brief description of what is new in the release. The description tag is structured as described in <description/>.

And <description> tags are translatable.

In T8426#138028, @ngraham wrote:

In T8426#138027, @aacid wrote:

In T8426#137964, @ngraham wrote:

The strings in <release> tags are translatable just like all other strings in AppStream metadata files. See Krita's (for example) see how it's done: https://cgit.kde.org/krita.git/tree/krita/org.kde.krita.appdata.xml#n59

I don't understand this sentence. You mention the krita file, but it doesn't have the release tag translated? Or am i looking at the wrong thing?

The release tag is translateable in the same manner as the description tag is currently translated.

In T8426#137985, @ltoscano wrote:

To be honest

In T8426#137964, @ngraham wrote:

In T8426#137934, @rkflx wrote:

@ltoscano I've got a question relating to translations and AppStream metadata:

Once this is finalized, we could also add the information into Gwenview's AppStream file in a new <release> tag, which will result in all the notes showing up for users of KDE Discover and other software center apps.

Was just about to prepare patches for Gwenview, Spectacle and Dolphin, but then got doubts whether that would break the string freeze. I know that the release notes will still be translated once they are ready, but does this also apply to AppStream strings? Is <release><description> even enabled for translation?

Essentially I want to avoid showing untranslated strings in Discover… Any tips/comments?

( @aacid too ).
I have no idea. This is a first and I don't know the impact on the tooling and on the workflow (including the issues with merging from a stable branch to master).

As discussed on IRC with Kai it seems more a bug in Ark since Konqueror seems to have it correctly work

Is this going to fail on my translated nm output?

Doesn't this mean that when you open okular you end up with two print actions?

Update commit author to kdab.com hat

I was thinking about that yesterday when i saw the script Riddell has that creates pages, i guess it would be possible, there's two issues i can think of that make it non-trivial (i think):

• We somehow need to update pages to cross link to all the other languages pages (if we want to keep the header like language selection we have in the announcements now, i.e. the "Also Available in" https://www.kde.org/announcements/announce-applications-18.04-rc.php)
• We need a way to segment whole pages into sensible .pot translation units. You don't want the whole page to be a single .pot entry because it would mean exposing html stuff to translators, that is easy to make mistakes with, and also because if you change one word you want to "dirty" the smallest possible unit (ideally sentence, at realistically paragraph) for retranslation not the whole page.

Personally i don't really have big requirements, since i do all the releases by just copy&pasting the old releases manually. I guess i could do the same thing on the webpage.

What the translators would like is something that doesn't make them change their workflow.

In D10797#241744, @simgunz wrote:

I have created a new revision D12013 by mistake. That can be deleted.

I have removed the commit with the asterisk I have added before, because when I just tried to revert it phabricator was complaining and didn't let me update the revision. Is pushing a rebased branch to the phabricator diff a bad practice (usually it is in git)?

Not really an experct in phabricator use myself, so no idea :D

In D11901#241751, @ahmadosama wrote:

I tried rotating using ( const QTransform matrix = rotationMatrix() ) but it only works when rotating a page from its original orientation, this is why I modified the RotationJob::rotationMatrix in a way similar to Okular::buildRotationMatrix to allow rotating from different orientations.