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 _______________________________________________ evolution-hackers mailing list firstname.lastname@example.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers