why not give grantlee the ability to understand QColor? I mean we already have special lookups and it make sense to have the feature for complete kdepim.

How? I did not find a way to add string conversions for custom types externally. And I can't do this in Grantlee itself, as it would add a dependency on QtGui which it currently does not have.

use something like this:
GRANTLEE_BEGIN_LOOKUP(QColor)
if ( property == "name" )
return object.name();
else if ( property == "age" )
return object.age();
else
return object.name()
GRANTLEE_END_LOOKUP

http://www.grantlee.org/apidox/generic_types_and_templates.html

and see messagelib/messageviewer/src/messagepartthemes/default/messagepartrenderermanager.cpp for more examples...

the naming is also a little bit wired as we dont used this KPk before.

I think if i now enters KDE Pim it should exist in in KPim namespace.

"KPk" is not the namespace here, "K" is. "PkPass" is the name of the file format (and Apple came up with that one, hard to change for me ;-) ).

That doesn't seem to be widely used, but I can of course change the library accordingly (it will need to be done there first though).

That's for property access to custom types, not for turning a custom type into a string (and it's in use in this file even). This is usable in theory by adding a dummy property such as "name" to QColor, but that is just as clunky as the current solution. What we would want is turning a QColor directly into a string, without any such indirection, and that's the part I haven't found a solution for yet.

A okay- well I parsed the KP as shorthand for kde pim. What about KPimPkPass?

that is right - because everyone thought that we need to use the KF5:: namespace. And we didn't wanted to move everything to KPIm:: later on, that's why only new libs using this namespace.

can't you can return a default value, if no property is given. In messagelib/messageviewer/src/messagepartthemes/default/messagepartrenderermanager.cpp i needed to write my own lookup functions, maybe the macros are not working for this anymore.

And KPim::PkPass in CMake, yes. Also makes a possible future migration to KF5 easier, "KPim" is easier to search/replace than "K".

I don't think this works, as Grantlee seems to use the lookup functions only when encountering a "." followed by a string, for a type with a custom lookup function registered.

A custom string conversion function is possible in theory via QMetaType::registerConverter, but that does not accept a conversion between two built-in types, so that also does not help in the case of QColor.

update the name here too

either <PkPass or <KPimPkPass to be consitent

also rename the classes PkPass::Barcode, PkPass::Field ?

I still think that having the .name inside the template is the more clean solution, but well this is only minor personal syntax style.

Indeed, I'll fix that.

This now follows the KF5 naming patterns, ie. namespacing the library with "KF5" (or "KPim" here), and namespacing the C++ namespace with "K". I used the pattern you suggest initially in KF5::SyntaxHighlighting, and had to change it to the KSyntaxHighlighting namespace in review. So for consistency I'd follow KF5 here.