I cannot reproduce Part 1 of your test plan. When I delete my okularpartrc and start Okular (with the patch), then the freshly created okularpartrc file contains all colors as RGB, not ARGB. This doesn't seem to have any negative consequences, however.

Part 2 seems to work alright.

In D15279#320991, @sander wrote:

I cannot reproduce Part 1 of your test plan. When I delete my okularpartrc and start Okular (with the patch), then the freshly created okularpartrc file

When is your new okularpartrc created exactly? Afaikt, it should not be created right on startup, but only when you modify some tool in the config dialog.

contains all colors as RGB, not ARGB.

Strange, for me it works. New okularpartrc looks like this

AnnotationTools=<tool id="1" type="note-linked"><engine hoverIcon="tool-note" color="#ffff00" type="PickPoint"><annotation icon="Note" color="#ffffff00" type="Text"/></engine><shortcut>1</shortcut></tool> [...]

Are you sure you looked at <annotation color="...">, and not at <engine color="...">? The first one is what matters.

This doesn't seem to have any negative consequences, however.

Existing annotations don't consider alpha channel, so you don't notice it for now. But it would have negative consequence for typewriter.

When is your new okularpartrc created exactly? Afaikt, it should not be created right on startup, but only when you modify some tool in the config dialog.

No. It is created right at program startup. I don't even have to open a document.

Are you sure you looked at <annotation color="...">, and not at <engine color="...">? The first one is what matters.

Yes.

Existing annotations don't consider alpha channel, so you don't notice it for now. But it would have negative consequence for typewriter.

I wanted to check that the new ARGB code handles an existing okularpartrc with RGB colors correctly. And it does.

So what now? The patch seems to do something reasonable, but it does not do what you claim it does.

So what now? The patch seems to do something reasonable, but it does not do what you claim it does.

It must work, else we couldn't go on. I've got sneaking suspicion, a wrong tools.xml is loaded in your setup. Can you watch okular in strace

$ strace -e openat /devroot/usr/bin/okular 2>&1 | grep -F tools.xml
openat(AT_FDCWD, "/devroot/usr/share/okular/tools.xml", O_RDONLY|O_CLOEXEC) = 10

Does okular really take the new patched tools.xml from your development installation? Or does it maybe load that one from your distro, which would be wrong and explain the misbehavior.

It really does take the file tools.xml from my development installation (tested with strace). Indeed, I deliberately purged my distro's okular from my computer a while ago, to avoid confusions like this.

I'm going to push, and want to do it on behalf of @dileepsankhla who did the original work. I.e. my Phab revision, but git commit author should be him.
Has anybody tried with arc land? Will this work?

$ git commit --amend --author="Original Author <email@address.com>"
$ arc land

Thank you Tobias for making it landable. Please go ahead :)