GNOME Bugzilla – Bug 573878
[face] Plugin is unusable
Last modified: 2013-09-13 01:00:04 UTC
<andre> so how does the face plugin work? only option i see is to enable/disable it. no configuration, no choosing of an image file etc <jony_> andre, looks like you have to create the image and place it in ~/.evolution/faces manually .. thatz what the comment says .. yeah .. it should be easier to generate that from the configuration page .. <andre> jony_, ahahah. ok. that's not even alpha software to me <andre> should i also base64 encode it myself? #: ../plugins/face/org-gnome-face.eplug.xml.h:1 msgid "" "Attach Face header to outgoing messages. First time the user needs to " "configure a 48*48 png image. It is base64 encoded and stored in ~/.evolution/" "faces This will be used in messages that are sent further." CONFIGURE is VAGUE. "IT IS BASED64 ENCODED" - automatically?! If so I don't fscking care. If not, TELL ME HOW TO DO. It is stored AUTOMATICALLY in ~/.evolution ? If not, TELL ME to store it over there. You're missing a full stop after that sentence too.
Yeah, the face plugin is not exactly a shining example of usability.
I think this is grounds for moving it to experimental until we can come up with a decent UI for it. Its current state is just embarassingly bad.
Plugin is now experimental until the UI is fixed. http://git.gnome.org/cgit/evolution/commit/?id=294c52f4d2485bcc24ce50de9c6fe3ef07fa3e61
*** Bug 525500 has been marked as a duplicate of this bug. ***
Created attachment 140636 [details] [review] proposed evo patch for evolution; Feel free to suggest better sentences or anything you dislike on this change. Not the porting to ESettings is trivial, as it's enough to change two functions only. (though I'm not sure how about schemas in plugins and such other related things)
Typo: _("Uknown error");
(In reply to comment #6) > Typo: _("Uknown error"); oh, thanks, I'll fix it before commit (if approved) or before reupload (if other changes will be required).
The patch satisfies the feature request in bug #525500 but the file chooser dialog is still a disaster. Some suggestions for improving the plugin: - Don't push archaic X-Face requirements onto the user. Let the user choose any image. Evolution should try to make it conform, and then complain if it can't. - Use GtkFileFilter so that only images are listed in the file chooser. A preview pane (gtk_file_chooser_set_preview_widget) in the dialog might be nice too. - Use pixbuf scaling if necessary to shrink the image down to 48x48. Then test whether the resulting image is < 720 bytes (not sure if that's before or after Base-64 encoding). If it's too big, suggest the user choose a smaller image. Doing that may be enough to lift the plugin out of "experimental" status.
(In reply to comment #8) > The patch satisfies the feature request in bug #525500 but the file chooser > dialog is still a disaster. Some suggestions for improving the plugin: > > - Don't push archaic X-Face requirements onto the user. Let the user > choose any image. Evolution should try to make it conform, and then > complain if it can't. > > - Use GtkFileFilter so that only images are listed in the file chooser. > A preview pane (gtk_file_chooser_set_preview_widget) in the dialog > might be nice too. It is using the filter, for png files. And it used it even before. Do I miss anything? > - Use pixbuf scaling if necessary to shrink the image down to 48x48. > Then test whether the resulting image is < 720 bytes (not sure if > that's before or after Base-64 encoding). If it's too big, suggest > the user choose a smaller image. Smae as the first ball, from my point of view :)
Hmm, the only information I found about the X-Face is this: http://tools.ietf.org/html/draft-klyne-hdrreg-mail-00#section-2.2.21 Other sources repeat that. I have no idea where the 720 bytes number come from, maybe from the "real life", but otherwise it's a "magic number" for me. The scaling, yup, it's possible, but I'm wondering whether we should mimic the graphic editor work. You know, most of the time the picture will not be square, thus either crop it, or make it smaller and have a gap on some sides. That is better, from my point of view, to do such thing in an application used to image manipulation, not in an email application. (as better graphic filters are available in such applications, and can easily crop only the particular part of a "family photo" to be used in the email :)
I -think- the 720 bytes is some kind of mail header limit. Might be buried somewhere in RFC 2822. I'd say scale the shorter side to 48 pixels and center-crop the longer side, if that makes sense. I agree the user will probably have to use a real photo editor to prep the image, but we can at least make a token effort at it. Maybe even show the result in the file chooser preview, if it's not too expensive.
(In reply to comment #11) > I -think- the 720 bytes is some kind of mail header limit. Might be buried > somewhere in RFC 2822. http://tools.ietf.org/html/rfc2822#section-2.2.3 Can be, as the limit per line is about 998, the 720 not coded means up to 900 base64 encoded bytes, thus enough space before forced folding. In interestingly, the 48*48*3 = 6912 decompressed bytes of a full color. Let's see what I'll be able to do here.
Created attachment 140757 [details] [review] proposed evo patch ][ for evolution; added internal scaling. just note that I can have X-Face longer than 900 letters, though evo folds the header at 999, which seems to be incorrect, as of the above RFC. Also, for some images I got 5632 base64 encoded length, it's too long. Typo fixed too.
Created commit b3b783f in evo master (2.29.1+)