Queries regarding adding a new 'typewriter' annotation tool to the toolbar

[Tobias Deiminger]

This is about engine colors and misc. Almost through now:)

Am Freitag, 18. Mai 2018, 17:04:09 CEST schrieb Dileep Sankhla:
> 6. tools.xml has <engine color> and <annotation color> tags. The engine
> color is used -
> i) to colorize the overlay icon with engine color that is drawn
> on tool-base-okular icon for every annotation toolbar icon[1].
> ii) to set annotation background color to engine color if <annotation
> color> tag is absent[2].
> It is clear that we should omit <annotation color> tag and wherever it 
> is
> calling Okular::Annotation::Style::setColor() function, we should pass
> QColor(255,255,255,0) //alpha is 0, so transparent
> But we need engineColor to colorize our overlay icon. We can't omit it.

I'll add another question to this. If a 3rd party PDF composer (e.g. 
LaTex pdfcomment) sets both /IT = /FreeTextTypewriter and /C = [ <some 
color> ] but no /AP, how shall this be rendered? It's valid PDF. Okular 
can't do much about it, it's solely poppler that decides. Maybe we want 
to ignore /C for typewriter and force background to transparent also 
inside poppler?

> 6.1 We want to set overlay icon's color as the current font color being 
> set
> for typewriter only if we implement font color. Else we will have a 
> black
> colored icon. So if the community agrees on implementing the font color
> feature, do I need to first demo this with typewriter icon? Or should 
> we
> agree on black font and implement it only when the font color feature 
> is
> done?

Imho it's not bad if we start with an always-black icon. Regarding demo, 
I believe that tool GUI is the easier part wrt font color, so a 
dedicated GUI demo is not absolutely required, but doesn't hurt either. 
API design and core functionality in okular and poppler are the harder 
parts regarding font color.

> I don't know how to make a demo. Maybe something like
> Okular::Annotation::Style::setFontColor() which will save color in 
> private
> data without applying it to the annotation and set a demo by simply
> choosing, saving, reading font color and set the same icon color? This 
> is
> how we do for annotation color but here not applying to the annotation 
> at
> all.

For which purpose do you want to demo? Shall it be a tool GUI/config 
demo or an annotation API demo?

Annotations (i.e. Okular::Annotation objects) live independent from the 
tool that once has created them. If you want to demo the tool, you want 
to persist data in tools.xml/okularpartrc, not in docdata. In a demo, 
PickPointEngine can simply omit passing a font color to the 
Okular::Annotation object it creates.

To extend item AnnotationTools from tools.xml/okularpartrc you have to 
extend DOM parsing in every place it happens. From KConfig perspective, 
Settings::annotationTools() is just a list of strings. It doesn't know 
that those strings actually contain XML data. Therefore KConfig can't 
generate setters and getters for the deeper attributes like shortcut, 
engine, type. They're only accessed by Okular code like in 
PageViewAnnotator::reparseConfig. To add a new attribute you have to 
find all places where strings from Settings::annotationTools are parsed, 
and parse for your new attribute "fontcolor".

How will the demo be isolated from a functional patch? I'm asking 
because we should aim for a patch that can be merged to master. It must 
not have non-functional GUI elements. If you do a second patch dedicated 
for demo, that's fine. If it's all mangled into one patch, the patch 
probably wont land.

> 6.2 Now engineColor is also responsible for annotation color, which we 
> want
> transparent. I don't know if <annotation color="#00ffffff"> will set it 
> to
> transparent or should we omit this tag?

I'd say we should omit a color attribute in config places where it has 
no meaning. For typewriter it has no meaning, because we force it to 
transparent anyway.

> Basically, annotation color is set as a common attribute to all 
> annotation
> types at the end of the file and if we should bypass it with an if
> condition that will set annotation color for type "typewriter" 
> hardcoded to
> QColor(255,255,255,0).
> I have tried harcoding it for inline note and in the appearance 
> settings, I
> got a transparent color but as soon as I create a note, it's background
> turns to white. and I find color: white in the appearance settings 
> again.
> Will it work for the typewriter then?

No, if it doesn't work for inline note it also won't work for 
typewriter. We have seen transparent background working in our Qt5 
poppler demo 
https://cgit.kde.org/scratch/dileepsankhla/okular-gsoc2018-typewriter.git/tree/src/main.cpp#n24. 
So the alpha channel obviously gets lost somewhere inside Okular. Can 
you try to hunt the QColor down the stack and see where this happens?

Cheers
Tobias