GNOME Bugzilla – Bug 764559
Allow explicit html and plaintext signatures
Last modified: 2021-05-19 11:44:38 UTC
Sometimes the html signature doesn't map correctly to the expected plaintext signature. Or simply, the signatures should contain different things in both modes. It should be possible to provide an explicitly a pair of html and plaintext signatures, and have the composer signature switch accordingly when the email mode is changed. FWIW, this is possible with Microsoft Outlook, although it requires manually editing the signature files on the filesystem http://superuser.com/questions/427244/outlook-signatures-for-plain-text-and-html
Thanks for a bug report. I'm not sure whether this automatic switch between signatures would be the right thing. I suppose you have currently created two signatures, one in plain text and one in HTML, and you switch between then when composing the message. I'm afraid of a confusion for the users, though, on the other hand, it all is done on user's wish, thus might not be as that unexpected. Would it work, if there's added an option to Edit->Preferences->Composer Preferences->Signatures tab, for each signature, something like "alternative-for", where one will be in plain text (or script?) and another one for HTML, then the list of signatures would be as a tree, showing something like: Personal signature Company signature Plain Text version HTML version Another signature where the first and the last are without alternatives, only the "Company signature" contains an alternative for the Plain Text and the HTML mode? With that the composer itself would have also change the signature content when the mode changes. The main problem would be to have the UI done in a way which will make sense to users, aka to have an intuitive UI for this.
The tree view for signatures with both types is perfect. I'm not sure how to convey this in the creation UI, though. An option could be that if you have two signatures of different types with the same name, they are grouped. However, a) That'd be hard to discover b) Currently it is possible to have seeveral signatures with the same name. How to migrate it? What you mention about "alternative-for" field looks more as a different way of defining signatures. Currently there are four buttons at the right: * Add [signature] * Add Script * Edit * Remove I think the best UI we be to rename the first one to Create, then add an Add HTML version / Add plaintext version button when a signature is selected. As for scripts, whether they are currently treated as html or not depends on e_source_mail_signature_get_mime_type(extension) returning "text/html", which was loaded through g_file_info_get_content_type( g_file_info_get_content_type( g_file_query_info(…) ) ), which doesn't seem a too suited technique for a script. Having radio buttons on the add-script dialog for choosing if the script returns Plain text / Html / Auto and storing that preference along the script would be better. Then, the script could be passed an environment variable with the kind of MIME that is expected at this point, and automatically adjust its output.
Sorry to annoy people, but, is this planned to happen sometime?
(In reply to Stavros from comment #3) > Sorry to annoy people, but, is this planned to happen sometime? You are not annoying anyone, that's okay to ask. The bug is still opened, thus the feature is not rejected, thus it can happen, but there is no time line. People can help by providing patches, but it's understood that it's not a call for regular users, it's rather for developers.
(In reply to Milan Crha from comment #4) > (In reply to Stavros from comment #3) > > Sorry to annoy people, but, is this planned to happen sometime? > > You are not annoying anyone, that's okay to ask. The bug is still opened, > thus the feature is not rejected, thus it can happen, but there is no time > line. People can help by providing patches, but it's understood that it's > not a call for regular users, it's rather for developers. Well, I would like to implement it (since I am a developer technically). However, I have no idea on what the learning curve would be for me - in addition to all the prerequisites for environment preparation etc - in comparison to the "actual" complexity of the bug/feature
Right, Evolution is no small project. With respect of building Evolution, there is a guide, which is meant to help with that part, here: https://wiki.gnome.org/Apps/Evolution/Building
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.