Created attachment 1354 [details] add plugin to display QR-Code for avatar This adds a plugin to display QR-Code for avatar.
Created attachment 1355 [details] add plugin to display QR-Code for avatar Updated patch, cleaned some rough edges.
Created attachment 1356 [details] Screenshot Screenshot showing the new QR-Code avatar.
Just curious, what's the use case for this? I mean, you open a mail, the plugin renders the QR with the sender address, and you scan it with you phone for adding it to phone contacts? or is anything else?
For me there are at least two use cases: * Get a unique icon for every sender, just like libravatar's fallback to identicon, retro or whatever. QR-Codes are just black and white, but you will recognize some pixel combinations just easily. * Scan with your phone: Add the person to your phone's address book or send a mail (if for any reason claws-mail can display the message but sending is not possible). (* Currently claws-mail does not print the avatar. If it does you could easily answer a mail printed to paper.) And possible more. :D Other than that it is just a nice example for what is possible with the avatar API. And it would not hurt anybody, just not loading (or even compiling) the plugin brings no extra cost.
(In reply to comment #4) > For me there are at least two use cases: > > * Get a unique icon for every sender, just like libravatar's fallback to > identicon, retro or whatever. QR-Codes are just black and white, but you > will recognize some pixel combinations just easily. Well, there's an important difference, libravatar fallbacks are, with more or less degree of success, designed to be distinguishable by humans, where QRs are designed to be parseable by software. It's easy to tell if two QRs are different when seen together, but I doubt a user can keep all that noise in your memory to the point to being able to recognise addresses. (Un)fortunately human brain evolved to recognise faces, not black and white dot patterns. Yes, some can be recognised, but for most of people I think that's just visual noise. > * Scan with your phone: Add the person to your phone's address book or send > a mail (if for any reason claws-mail can display the message but sending is > not possible). I thought it won't because of blur, and it took a while, but this worked! :) > (* Currently claws-mail does not print the avatar. If it does you could > easily answer a mail printed to paper.) So not a real use case. > And possible more. :D I'm afraid you're being too optimistic here ;) > Other than that it is just a nice example for what is possible with the > avatar API. And it would not hurt anybody, just not loading (or even > compiling) the plugin brings no extra cost. Right, no problem as example, but releasing it always has an extra cost: maintenance :) Thinking again about this, I believe that would be better to try to incorporate this as another fallback option to libravatar.org server itself. That way libravatar plugin can support it easily, and everybody else could be enjoying the hackish QR avatars in their pages (or other mailers). Don't you think?
(In reply to comment #5) > Thinking again about this, I believe that would be better to try to > incorporate this as another fallback option to libravatar.org server itself. > > That way libravatar plugin can support it easily, and everybody else could > be enjoying the hackish QR avatars in their pages (or other mailers). Don't > you think? libravatar is designed to associate an image with an addresse, not vice versa. The image is requested by MD5 has and the addresse can not be calculated from that. The idea is to keep the address private, so probably this is a no-go.
(In reply to comment #6) > (In reply to comment #5) > > Thinking again about this, I believe that would be better to try to > > incorporate this as another fallback option to libravatar.org server itself. > > > > That way libravatar plugin can support it easily, and everybody else could > > be enjoying the hackish QR avatars in their pages (or other mailers). Don't > > you think? > > libravatar is designed to associate an image with an addresse, not vice > versa. The image is requested by MD5 has and the addresse can not be > calculated from that. The idea is to keep the address private, so probably > this is a no-go. Since now it's being used in other places than web pages (where I agree it's probably not a good idea unless you spam-protect the encoded address) I think it still has room in libravatar. I'll ask authors, and we'll see.
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > Thinking again about this, I believe that would be better to try to > > > incorporate this as another fallback option to libravatar.org server itself. > > > > > > That way libravatar plugin can support it easily, and everybody else could > > > be enjoying the hackish QR avatars in their pages (or other mailers). Don't > > > you think? > > > > libravatar is designed to associate an image with an addresse, not vice > > versa. The image is requested by MD5 has and the addresse can not be > > calculated from that. The idea is to keep the address private, so probably > > this is a no-go. > > Since now it's being used in other places than web pages (where I agree > it's probably not a good idea unless you spam-protect the encoded address) I > think it still has room in libravatar. I'll ask authors, and we'll see. D'oh! Forget it, you're right but I read your answer too fast. We'll need to reveal the address to the server otherwise you could only QR-encode the md5. Still "cool" from hackish perspective, but will lose the mail address info.
(In reply to comment #5) > (In reply to comment #4) > > (* Currently claws-mail does not print the avatar. If it does you could > > easily answer a mail printed to paper.) > > So not a real use case. Now that Claws can print avatars... Is this a bonus for my plugin? :D
Hi, I think that it would be better to have it inside libravatar plugin.
So the libravatar plugin itself should be linked to libqrencode.so?(In reply to comment #10) > I think that it would be better to have it inside libravatar plugin. So the libravatar plugin itself should be linked to libqrencode.so? And displaying the QR-Code is fallback if no avatar can be retrieved from libravatar? The perfect solution for me would be: * Add the QR-Code Plugin as is. * (Move Face and X-Face code to a separate plugin. Does it make sens to remove dependency of compface from main Claws?) * Add a configuration option to select the priority of plugins. I Would like to have libravatar -> Face -> X-Face -> QR-Code in most cases. Alternativly allow to display more that one avatar. * (Allow avatar in size different than 48x48 pixel, so libravatar can be bigger and QR-Code is not blurry.) Whatever you decide... Let me know what exactly you prefer and I will change/update the code.
(In reply to comment #10) > Hi, > > I think that it would be better to have it inside libravatar plugin. I have to disagree with that for several reasons: • Adds dependencies (QR library) not needed for libravatar operation. • QRs have nothing to do with libravatar: plugin name would be misleading. • Complicates the whole plugin logic, it's cleaner to have it separated. • The idea behind the avatar refactoring is precisely having separate plugins for separate avatar types, not a super-complicated avatar-hungry plugin for everything. • People interested in libravatar are probably not interested in QR (since their goals are pretty different). This can change if multi-avatar display is implemented, but even in that case having it as a separate plugin works equally well, so no problem anyway. • It's already implemented as a separate plugin, why make more changes to make future changes/maintenance more complicated? :)
(In reply to comment #11) > So the libravatar plugin itself should be linked to libqrencode.so?(In reply > to comment #10) > > I think that it would be better to have it inside libravatar plugin. > > So the libravatar plugin itself should be linked to libqrencode.so? And > displaying the QR-Code is fallback if no avatar can be retrieved from > libravatar? > > The perfect solution for me would be: > > * Add the QR-Code Plugin as is. Agreed. > * (Move Face and X-Face code to a separate plugin. Does it make sens to > remove dependency of compface from main Claws?) This is an old time core-feature, would break all configured Claws Mail out there for no benefit. > * Add a configuration option to select the priority of plugins. I Would like > to have libravatar -> Face -> X-Face -> QR-Code in most cases. You can already have that with the separate plugin way :) > Alternativly allow to display more that one avatar. This can be tricky: for example, there's no room for more than one avatar in header pane over message view mode. > * (Allow avatar in size different than 48x48 pixel, so libravatar can be > bigger and QR-Code is not blurry.) Current codes are already readable, anyway, if it's blurry it's because it's being zoomed in, isn't it? Maybe it's just the size of the generated QR what needs to be adjusted to be rendered with a exact number of pixels per QR-point ;) > Whatever you decide... Let me know what exactly you prefer and I will > change/update the code. Sure, and thanks for willing to implement the changes! :)
(In reply to comment #13) > (In reply to comment #11) > > * (Move Face and X-Face code to a separate plugin. Does it make sens to > > remove dependency of compface from main Claws?) > > This is an old time core-feature, would break all configured Claws Mail > out there for no benefit. Sounds reasonable. Agreed. > > * Add a configuration option to select the priority of plugins. I Would like > > to have libravatar -> Face -> X-Face -> QR-Code in most cases. > > You can already have that with the separate plugin way :) Hmm, really? If I load the libravatar plugin this is preferred, (X-)Face is shown if no libravatar can be retrieved. Loading my QR-Code plugin I always get the QR-Code, not only as a fallback. Can I configure that? Or can I prefer (X-)Face if available, then check for libravatar? > > * (Allow avatar in size different than 48x48 pixel, so libravatar can be > > bigger and QR-Code is not blurry.) > > Current codes are already readable, anyway, if it's blurry it's because it's > being zoomed in, isn't it? Yes, I always scale up (or down) to 48x48 pixel. > Maybe it's just the size of the generated QR what needs to be adjusted to be > rendered with a exact number of pixels per QR-point ;) Then the code gets even smaller... And we have to make sure it is not truncated for long mail addresses that result in a code larger than 48x48 pixel. This is not a must-have but a nice-to-have. So as long as avatar size is 48x48 pixel I would always scale it. Best readability on display is with a fixed scale of two or three. (e.g. a 21x21 Qr-Code would result in 42x42 or 63x63 pixel.)
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #11) [...] > > > * Add a configuration option to select the priority of plugins. I Would like > > > to have libravatar -> Face -> X-Face -> QR-Code in most cases. > > > > You can already have that with the separate plugin way :) > > Hmm, really? > If I load the libravatar plugin this is preferred, (X-)Face is shown if no > libravatar can be retrieved. > Loading my QR-Code plugin I always get the QR-Code, not only as a fallback. > Can I configure that? > Or can I prefer (X-)Face if available, then check for libravatar? Mmm... ok, I think I talked too fast here :) Currently the priority is set also by the unique type identifier (#define QR_AVATAR_QR_AVATAR 4) so last one is always higher priority by definition. Implementing priorities among avatar plugins requires some plugin interface changes probably... will think about this, but not for this relase :) > > > * (Allow avatar in size different than 48x48 pixel, so libravatar can be > > > bigger and QR-Code is not blurry.) > > > > Current codes are already readable, anyway, if it's blurry it's because it's > > being zoomed in, isn't it? > > Yes, I always scale up (or down) to 48x48 pixel. > > > Maybe it's just the size of the generated QR what needs to be adjusted to be > > rendered with a exact number of pixels per QR-point ;) > > Then the code gets even smaller... And we have to make sure it is not > truncated for long mail addresses that result in a code larger than 48x48 > pixel. > > This is not a must-have but a nice-to-have. So as long as avatar size is > 48x48 pixel I would always scale it. > Best readability on display is with a fixed scale of two or three. (e.g. a > 21x21 Qr-Code would result in 42x42 or 63x63 pixel.) OK, didn't know size of QR changed with the size of the info. Sorry for the noise ;)
Created attachment 1410 [details] add plugin to display QR-Code for avatar Updated for git master.