D11830: Switch the pkpass formatter plugin to use KPkPass

[Sandro Knauß]

knauss added inline comments.

INLINE COMMENTS

> vkrause wrote in CMakeLists.txt:124
> "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 ;-) ).

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

> vkrause wrote in CMakeLists.txt:15
> 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 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.

> vkrause wrote in pkpass_plugin.cpp:105
> 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.

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.

REPOSITORY
  R81 KDE PIM Addons

REVISION DETAIL
  https://phabricator.kde.org/D11830

To: vkrause, #kde_pim
Cc: knauss, dvasin, winterz, vkrause, mlaurent, dvratil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20180401/ce7afa5d/attachment.html>