*** Bug 720662 has been marked as a duplicate of this bug. ***

Signatures in UNIX are something of a slippery slope, usability-wise:

A GUI editor is necessary for normal people - so you need a button "Edit Signature" in the Account prefs.

UNIX users however like to use .signature files, but while the .signature convention worked well in a world where you had one email address - loginname@loginhost, it doesn't scale to a world in which people commonly have several accounts and addresses, so you need to add some radio buttons to chose between the built-in sig, the external-file sig, and a filechooser button to choose which .signature file you actually want to use, and a lot of documentation. This is where Thunderbird is at.

UNIX enthusiasts instead prefer to use the output of some program as their signature, so you either need to replace the GTK standard file chooser button with a text entry and some weird semantics, or add a third radio button, a text entry, a program chooser button, and yet more documentation. Evolution used to here, but I see lately (in v3.x?) they have scaled it back.

So to keep everyone happy, you end up with around a dozen widgets/labels rather than a single button, which is rather terrible, and a chapter on Signatures in the docs, rather than a sentence.

To avoid this, a reasonable solution is to have a per-account signature file as mentioned a comment above: ~/.local/share/geary/$ACCOUNT/signature.html. This is created as an empty file (or with a reasonable default signature) when an account is created. Every time a new message is composed, it is opened, read and appended to the body of the message. The Account Prefs can have a single Edit Signature button, which invokes the GUI editor on the contents of that file. UNIX users will know to look in ~/.local/share/geary and can replace the file with a symlink to the .signature of their choice when they find it, and UNIX enthusiasts will enjoy the challenge of working out an appropriate POSIX-compliant solution.

The only edge case is text vs html - it would be fine to just put plain text in the signature.html since that is valid HTML, but that would break if peopled used reserved chars like < and &, which is pretty common in a plain text sig. Since the email composition already has a notion of "Rich Text" messages, that can be applied to the signature editor as well. So call the file "signature" instead (no .html or .text extension), note if it contains HTML or plain text in a per-account pref, and update the pref based on whether the user chooses Rich Text in the sig editor. UNIX users can update the pref using the editor or by editing the ini file.

I'd like this feature!

Even if Geary doesn't support GPG yet, I'd like to add my GPG key to the signature in Geary (then I'll decrypt the messages on my mobile, until #713403 is fixed).

Hi all, just to know, when is planned to implement this feature?
I saw a comment saying 0.5.x but 0.6 has been released but this fundamental feature isn't in.

How said on another comment even a geeky workaround (putting a .signature file in user's home) would be nice, waiting for a per-account solution.

Also canned responses could be a temporary workaround.
Kindly

On top of Mike's thoughtful analysis above, there's the issue of where to inject the signature -- top-posting vs. bottom-posting is flame-war-bait, and so I suppose that will need to be a user preference too.

To summarize the issues I see at this point:

* Be able to specify a signature per account
* HTML vs. text signature
* .signature file support
* Top-posting vs. bottom-posting
* Signature selection at composition time

There may be more.

The simplest workaround I see at this point is:

* Load the signature from the .signature file
* Text-only (converted into HTML for HTML email, naturally)
* Top-posting assumed

Which kind of matches what you're asking for, Elvis.

I can't promise anything at this time, but since this is so highly requested and has slipped so many times, I am at this point open to a patch that meets the simple workaround I listed above.  Joey's patch from way-back-when would be a good starting point for anyone out there who wants to take a crack at it.

I think that this first workaround would make me super-happy.
And other users too, I think.

Then, with more time, a complete and parametrized solution would make sense.
I'll follow this bug and wait for it's resolution ;)

I'm following this bug for some time as I need this feature as well.

Now I took Jim's advise and completed a first patch including support for ~/.signature and ~/.local/share/geary/$ACCOUNT/signature files that works with text and html mail.

Making the per-account files editable using the UI should not be too hard, but please review this patch first before I continue.

Created attachment 274187 [details] [review]
Adding support for ~/.signature signatures

Optionally see https://github.com/mpdeimos/geary/commit/4185119aa42af43af6ba0354b6590d5b11b3a8fe

Created attachment 274188 [details] [review]
Support for per account signatures

Optionally see https://github.com/mpdeimos/geary/commit/6eafd43c0e595ba6ef98089c239d1744cde2fc16

I'm in no way an expert in Vala though I do have years of experience on C# so I took some time off this weekend to implement my own version:

- Enable / Disable signature on a per account basis on the account dialog
- Add / Modify signature on the account preferences (so it is stored on the .ini file for GLIB)
- Adds the signature to the composer window (at the bottom, I personally don't like to have it on top), if signature for that particular account is enabled on its own settings

I did not implemented an HTML signature version as I don't really need that feature, besides it would require to add a more complex control to parse the html code on the account dialog, so for now its just a simple TextView / TextBuffer.

Please feel free to review the attached patch and use it if it fits your needs.

Thanks!

Created attachment 276395 [details] [review]
Adds support for text signatures on a per-account basis

Too soon submitted my patch I guess.

I'm adding another one with a fix so that multiline signature text is correctly parsed.

I realized that there is a class method being used to override KeyFile.get_string() from GLIB:

email_signature = get_string_value(key_file, GROUP, EMAIL_SIGNATURE_KEY);

That does this:

return key_file.get_value(group, key);

So it is using KeyFile.get_value() which is going to return an unescaped version of the string which we don't want.

So I added another method inside the class to use KeyFile.get_string instead so that the key setting from the INI is escaped in both account settings and the composer window.

I also changed from set_value to set_string in Geary.AccountInformation so that the setting is actually saved in the ini with escape characters like:

"signature=A multiline \nString"

Created attachment 276401 [details] [review]
Parse escape sequences for signature setting value

Wow -- talk about an embarrassment of riches!  I've been busy on California and haven't had a chance to take a hard look at patches until now.

First, I've created branches on git.gnome.org for both approaches: wip/712895-sig-martin and wip/712895-sig-gustavo.  Both have their advantages and downsides.  I feel they should be combined in some way to produce the final feature.

For those following at home, Martin's patch reads the signature file from a file.  It first looks for a file called "signature" in the Geary data directory and then for ".signature" in the user's home directory.  The file's contents are escaped into markup and prepended to the reply body, if any.  This meets the basic bullet points I listed above, although it does leave the problem of editing the signature file to the user.

Gustavo's patch is more user-friendly.  The user can activate signature support with a checkbox in the Accounts dialog.  When active, the user can add a plaintext-only signature to an edit box which is saved in the geary.ini file.  I have to admit, this is closer to our vision of how signatures would work in Geary.  We recognize that there's a lot of complications with this feature, as Mike Gratton explicated above (comment #2).

Gustavo, there are a few problems with your patch:

* If you rename your ~/.local/share/geary directory to something else (geary.backup for example) and then run Geary, it'll go into its "first-run" mode which is where the user creates their first email account.  This is slightly different than the dialog when you add an account from the Accounts dialog, but same idea.

Basically, we want to keep the "first-run" dialog is simple as possible, so we don't want the signature widgets visible there.  I'm okay with leaving it visible if they add a second account.  Our goal is for first-time users to get going as quickly as possible.

If you look throughout the code, you'll see some state that's used to determine which widgets are visible and hidden.  We need similar code for the signature widgets.

* "Signature:" next to "Use email signature" feels redundant.  Instead, since the signature is separate from the account details (email, password, etc.), I'd prefer if there was a "Composer" section in the dialog (kind of like "Storage" below it) with the checkbox and edit box.

* If I reply to an existing email, the signature is added but to the bottom of the new email, not the top.  You might check Martin's branch to see how he did it.  (I didn't look close enough at the code to see what was different there.)

Martin and Gustavo, please do read over Yorba's coding conventions, as that will help get these patches landed: https://wiki.gnome.org/Apps/Geary/CodingConventions

As I said earlier, combining both patches is interesting to me.  In particular, I'm now leaning toward Gustavo's approach but mixing in Martin's code:

* Fix the above issues (obviously)
* If "Use email signature" is checked, the edit box signature is used (even if blank; this allows for people with .signatures to override it for certain accounts)
* If unchecked but .signature file is found, use that.
* Don't use "signature" file in Geary data directory -- I would prefer people not need to muck around in there.

If we could get all of this put together, I think we'd have a winner.

Great!. Sounds like a win-win for all. I actually thought about having a separate group on the dialog but then I just added it on the general settings for the account. This should be no biggie as it implies just moving the widgets and fix it so that it is displayed after first run as you say.

I think the problem of the signature added to the bottom is in the order of assignment of the variable in a line that I added so I guess a simple if (as in Martin's patch) should do it.

I guess loading the .signature file would not be a problem even if the checkbox is not actually checked since people having those are usually power-users and if they see their signature added in composer they will know where it is coming from, as opposed to someone who is not accustomed to use unix/linux. Plus, I personally like the idea of having separate signatures for different accounts since you'd usually have some kind of contact info and I for one use a different contact phone on such area for my personal and work addresses, for instance.


I'll have a look at the coding guidelines. I did this thing over the weekend on a few hours and I have almost none experience with vala but I'll try to cope.

So let me know your thoughts and we may end up having a merged patch with Martin's code and mine that can land soon for all other users :)

Nice to see some movement here. Unfortunately (for you, not me),  I'm leaving for 2 weeks vacation this weekend; so I might not be able to spent lots of time on the patch. Gustavo, feel free to adopt as much as you like.

I also think the UI variant is the more intuitive one which should be preferred.

Gustavo, I would say look over Martin's patch/branch and use whatever code in there you can.  .signature support is, as you say, more of a power-user thing in my mind, but it's so prevalent in Unix I feel Martin's approach needs to be incorporated.

And don't get too hung up on the coding guidelines -- it's grown over the years, but the gist is, if your code looks like the code surrounding it, you're probably safe.

Good luck!

Yup, totally agree, my comment was more on justifying as why to add widgets to manually add signatures in a per-account basis in addition to what Martin suggests/did, you know, everyone wins.

I'll try to work on the branches this weekend and merge Martin's with mine and submit a new patch for you guys to review it.

Thanks!

PS: Is there a good starting point to properly learn VALA / Gnome Dev? I was tempted to buy the packt pub book "GNOME 3 Application Development Beginner's Guide!" but I read over p.g.o some bad reviews. Just for the record, I do have a lot of experience on C#/.Net and worked some projects with Mono / GTK#

Great!

As for Vala, I'd recommend looking at this page:

https://wiki.gnome.org/Projects/Vala/Documentation

In particular, you might find this helpful:

https://wiki.gnome.org/Projects/Vala/ValaForCSharpProgrammers

Thanks Gustavo!

@Jim (regarding the dev docs): If there is some time I'd really like to see a blog post, etc. of how you do development for VALA. For me the biggest showstopper always was not to have a real IDE. So I tinkered around choosing the right gedit/monodev/geany plugins, choosing the most suitable build system and so on. I know this is off-topic here, hence the idea for a short blog post.

Martin, you might want to take a look at anjuta which is the most full-featured gnome-IDE I think there is, it has build tools, a glade component, VCS, etc.

For those watching this bug, I should point out there's a bounty for signature support:

https://www.bountysource.com/issues/1352311-geary-should-allow-user-to-specify-a-signature-to-be-appended-to-each-sent-message

If you feel strongly about this feature, please consider contributing.  This encourages activity and rewards the work for those who complete it.  (Note that Yorba employees don't accept bounties for work on Yorba projects.)

I'm sorry I did not have much time to check back on this. I was wondering if you guys are open to a third approach, basically, use radiobuttons so that the user can either:

 * Disable signatures
 * Read signatures from ~/.signature
 * Use a custom signature

I modified the .glade file a little bit and am attaching a screenshot.

What this would do is to allow the user to choose from any of those options meaning that they will know where the signature is coming from (if any) as opposed to just having a checkbox. The thing that I see with the checkbox and the .signature file is that if it is checked but the textview has nothing in it then logic tells me that nothing is going to be appended as a signature so the "read the .signature file behind the scenes" while useful, may confuse the user: there is nowhere in the application where this is stated as happening.

The other (easier) approach is to just have a label beneath the textview with my current UI (the one with the checkbox and the textview) that tells the user that, if a .signature file is found in his/her home directory and nothing has been input in the textview than that will be used, still confusing to me, but at least the user knows where the appended text came from in composer.

I'd like to hear your opinions so that I can create the proper patch.

Thanks!

Created attachment 277168 [details]
Proposed design for the signature UI modification

(In reply to comment #23)
> I'm sorry I did not have much time to check back on this. I was wondering if
> you guys are open to a third approach, basically, use radiobuttons so that the
> user can either:
> 
>  * Disable signatures
>  * Read signatures from ~/.signature
>  * Use a custom signature

It's certainly a flexible approach, but as I mention above it's also going to be confusing for people who aren't UNIX hackers, and it's unnecessary anyway since people who are UNIX hackers will know how to symlink the per-account signature file to ~/.signature. As such, I'd suggest the prefs are best left at a one-liner, something like this:

    [X] Append a signature to new messages [ Edit Signature ]

Where  [ Edit Signature ] is a button that is sensitive only when the checkbox is ticked, and when clicked invokes an editor. For the first pass, this can just run GEdit on the account's signature file, but down the track it could be an editor that lets you choose Rich Text (i.e. HTML) or not signatures and edit the file accordingly.

(In reply to comment #25)
> (In reply to comment #23)
> > I'm sorry I did not have much time to check back on this. I was wondering if
> > you guys are open to a third approach, basically, use radiobuttons so that the
> > user can either:
> > 
> >  * Disable signatures
> >  * Read signatures from ~/.signature
> >  * Use a custom signature
> 
> It's certainly a flexible approach, but as I mention above it's also going to
> be confusing for people who aren't UNIX hackers, and it's unnecessary anyway
> since people who are UNIX hackers will know how to symlink the per-account
> signature file to ~/.signature. As such, I'd suggest the prefs are best left at
> a one-liner, something like this:
> 
>     [X] Append a signature to new messages [ Edit Signature ]
> 
> Where  [ Edit Signature ] is a button that is sensitive only when the checkbox
> is ticked, and when clicked invokes an editor. For the first pass, this can
> just run GEdit on the account's signature file, but down the track it could be
> an editor that lets you choose Rich Text (i.e. HTML) or not signatures and edit
> the file accordingly.

We already had a working patch, just had to merge the .signature feature from Martin. This patch adds a checkbox but instead of opening an editor there is a textview beside the checkbox that allows you to edit the signature.

The button approach, while can be good and enough, lefts out the "user-friendly" feature which is being able to just edit the signature inside the mail application in a per-account basis, and I believe that geary is targeted precisely towards that: to be simple.

Jim, any thoughts?

I'm all for simple!  I'm with Mike on this one, the .signature file is a UNIXism from the rn days of yore and whatever support Geary has for it should not come at the sacrifice of UI clutter or additional complexity.

I still think the approach I listed at the end of comment #14 is the way to go.  I would very, very much prefer an in-proc edit box rather than launching gedit.  I wouldn't be averse to the signature editor popping up in a different window or, better yet, treated as a pane in the Accounts dialog (which is a GtkStack).

As mentioned above, we're not worried about HTML signatures or anything else fancy.  I'm sure people will want all kinds of cruft later, but this is such a widely-requested feature, I'm willing to start small...but not too small.

Alright, then just to review:

 1. A new group of widgets called "Signature" will be added beneath the "Storage" option in login dialog
 2. This group will be shown only after first-run on the login dialog
 3. We keep the checkbox and the textview for user input
 4. If the checkbox is checked, and nothing is input from the user then we look for ~/.signature and use that
 5. If the checkbox is checked and has content, we use that signature for that particular account
 6. For case number 5, we'll store the signature in the account.ini file
 7. Signature is added at the top of a reply (before the quoted test but at the end of the new reply text)

I already merged with Martin's, just need to modify the show/hide after first run.

Do we all agree?

Thanks!

Ok, so I finished the thing. I'm attaching a patch that can be applied to the 712895-sig-gustavo branch.

Fixes added:

 * Show only the composer widget group when in EDIT mode
 * Add signature (if any) to the bottom of the message, even on replies, on composer window
 * If ~/.signature exists, use it if "use signature" option is checked and there is no text in signature widget
 * Changed "signature" to "composer" as the options group

Let me know if anything else is needed to merge. Thanks.

Created attachment 277411 [details] [review]
Fixes to show signature options on edit mode only, support for ~/.signature

Great work!  Pushed to master, commit c5228f

I had to do a little merge massaging to get the old patch and the new one into latest master, as almost all the major changes since I started that old branch were against, of course, the composer.

I also did a little tweaking, mostly to meet code guidelines, but I also changed the checkbox string.  I wanted something brief, but if you have a better suggestion, that can easily be changed later.

I also filed this ticket for a minor thing: bug #730965.  It wasn't enough to stop the feature from landing.

Finally, there's a $30 bounty for this issue that someone should collect.  I feel Gustavo did most of the heavy lifting here and should claim it.  However, Martin, if you feel you're entitled to some portion of it, please say so and we'll see what we can work out.

Whew!  This feature has been a long time coming.

Hey Jim,

Great to see it finally merged!, I, however, found an issue when you save a draft and then reopen it to finally send it, composer window appends the signature once again, so that should not be happening since you already had it when you first tried to compose a message. I'll make a fix this weekend for such issue. Should we open a ticket?

I have no problem with the string change. I reviewed the code as per the guidelines but I'll see the diff to check what you changed to consider for further patches.

As for the bounty I'd say add it up to another issue so it gets more attention :) 

Thanks.

This is great to have, thanks Gustavo!

Two bits of polish spring to mind having used it:

Geary should be appending a "-- \r\n" (that's a minus-minus-space-cr-lf) between the body text and signature. This is pretty standard behaviour for all well-behaved mailers, and indicates the boundary between the main body of the message and the signature, especially in text/plain parts. This convention allows for example MUAs to safely discard the signature when quoting a message for reply.

Also, the prefs window is now too high for my screen (1200x800), such that I need to drag the window up to get to the Save/Cancel buttons - maybe the prefs finally need to get tabbed?

Thanks Gustavo for getting things done! As for the bounty, I just wanted this feature, hence I've implemented a patch -- I'm not interested in the money.


I'm voting against the addition of "-- \r\n" as this is not the behavior I know from my other mail clients (Opera Mail and GMail on Android). Afaik it is also not part of the ".signature standard".

(In reply to comment #34)
> I'm voting against the addition of "-- \r\n" as this is not the behavior I know
> from my other mail clients (Opera Mail and GMail on Android). Afaik it is also
> not part of the ".signature standard".

It's a standard for text/plain messages at least, see RFC 3676 Section 4.3 - http://tools.ietf.org/html/rfc3676#section-4.3 and GMail seems to add them anyway: https://support.google.com/mail/answer/8395?hl=en. I'm pretty sure mutt and pine have always added them.

If you're not seeing the delimiter it's because the mailer is detecting and hiding them from from you, which exactly why it is important to add them. :)

I've ticketed the double-add at bug #731177.  In general, our practice is to create a new ticket for each issue, only re-opening a ticket if the problem is not solved (or possibly regressed, although even that's rare).

Mike, note on that page for Google support that they only insert the separator when bottom-replying, not top-replying.  Since Geary currently only supports top-replying, I don't think we can (or should) add it yet.  But I haven't researched this fully.

Guess what I did?  Add a ticket for bottom-posting support: bug #731181