GNOME.org
 

[Evolution-hackers] Rethinking *signature* management

I've been working through composer code on my account-mgmt branch, and
had to take a short detour to deal with another source of XML blobs in
GConf: email signatures.  Wanted to take a moment to explain what I've
come up with.

It turns out, signatures also fit nicely under the ESource umbrella.
Therefore I'm killing off the ESignature and ESignatureList APIs in
Evolution, and rewriting all the signature widgets to use ESources.

The new design is very simple.  Each email signature will consist of two
files: a key file and a signature file.

The key file will live in the "sources" directory with all the other
account info.  Here's an example:

        File: ~/.local/share/evolution/sources/aaaa@localhost
        
        [Data Source]
        DisplayName=My Personal Signature
        
        [Mail Signature]
        MimeType=text/html  (or text/plain)

The signature file will live in the "signatures" directory, and have the
same base name as the key file.  The signature file will either be a
regular file containing the signature content (formatted as either plain
text or HTML), or it will be a symbolic link to an executable script
that can generate the signature content on-the-fly.

Some examples:

        File: ~/.local/share/evolution/signatures/aaaa@localhost
        
        (text/plain version)
        
        Matthew Barnes
        Red Hat, Inc.
        blah, blah, blah
        
        (text/html version)
        
        <HTML>
        <HEAD>
          <META HTTP-EQUIV="Context-Type" CONTENT="text/html; CHARSET=UTF-8">
          <META NAME="GENERATOR" CONTENT="GtkHTML/4.1.0">
        </HEAD>
        <BODY>
        <B>Matthew Barnes</B><BR>
        Red Hat, Inc.<BR>
        <I>blah, blah, blah</I>
        </BODY>
        </HTML>
        
        (symbolic link version)
        
        Link to: /usr/bin/fortune  (or some executable file)

Using the same basename for both the key file and signature file makes
the signature handling logic clean and easy, and using symbolic links to
executable scripts means we never have to store an absolute path in a
config file.  And that makes the config files more portable.

Another change I'm making to the way we handle signature scripts is
instead of assuming the script output is always HTML, I'm feeding the
script output to g_content_type_guess() and setting the MimeType key
based on its guess, which based on my testing so far has been pretty
accurate.  If need be, a user can always edit the key file and override
the MimeType key.

The ESource extension class for mail signatures is documented here: 
http://mbarnes.fedorapeople.org/account-mgmt/docs/libedataserver/ESourceMailSignature.html
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]