Additions to the .purple directory structure

[John Bailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I apologize in advance for the length of this message.  When I began writing I
didn't realize just how big it would become.  Now back to the regularly
scheduled message.

A few days ago I had an idea for some changes to the .purple directory
structure.  I talked them over with Gary, and we came up with a basic idea that
probably needs a bit more defining.  While obviously not complete, I think this
idea is at a good stage for more input.

First, a little background.  We distribute a .zip file that contains our Plugin
Pack plugins prebuilt for Windows.  We instruct our users to install these .dll
files to their .purple\plugins directory, creating the plugins directory if it
does not exist.  With the next release of the Plugin Pack, this will still work,
but it will cause a complication because there appears not to be a way to store
protocol icons (or any other icons we would generally consider a "stock" icon)
in .purple.  While the plugin itself will work in .purple, the icon will work
only if placed in the Pidgin pixmaps directory.  Granted, this isn't much of an
issue yet because the only protocol plugin we're going to distribute that
actually works is rizzo's SNPP plugin, but it will become an issue in the future
if, for example, Gary or I ever decide to update the napster prpl (which he
rescued from the bit bucket) and thus start distributing it.

My simple idea sprang from this.  The idea was initially to have a
.purple/pixmaps directory.  The goal here is to have a standardized layout,
similar to what we do now in $prefix/share/pixmaps/pidgin, so that plugins
installed to .purple can have their associated image data installed in .purple
as well.  I brought this up in #pidgin (in less detail), and Etan seemed to agree.

- From there, some additional ideas started forming for me, which I will outline
here to foster discussion.

It makes sense to me that if we have a .purple/pixmaps directory, we should also
have a .purple/themes directory structure for themes, especially given that Sean
has stated a desire to merge Guifications 2.x into Pidgin and also a desire to
support Adium's message styles.  I figure we can have something like the following:

~
`-.purple
  |-plugins
  |-pixmaps
  | |-protocols
  | |-emblems
  | `-(any additional directories that make sense)
  `-themes
    |-messages
    |-status
    |-smileys
    |-notifications
    `-sounds

Smiley theme support is already present, of course, and Etan has done work to
make status icon themes possible in the GTK+ UI.  With a Guifications merge
pending, theme support there needs accounted for.  The desire for supporting
Adium's message styles also needs accounted for.  With four types of themes
already supported or desired in some way, sound themes just make sense.  Again,
Adium has beaten us to the punch here.

For each subdirectory of .purple/themes, I propose that each theme creates a
subdirectory named after itself and has all its files installed to that
directory.  The theme files would reference the sounds, icons, etc. by relative
path, where a bare filename means that the file is in the same directory as the
theme file.

With all this theme stuff going on here, I'm going to advocate a change to all
the themes.  Make all themes use an XML format.  For Guifications, the work is
already done here--our themes are XML.  The format just needs updated to reflect
the new status system.  Smiley themes will be an issue, but we can have code to
migrate the smiley themes from the old format to the XML format.  Message styles
might be problematic here; I don't know enough about Adium's stuff to say.
Sound themes are likely going to be a sticking point as well, because I'm sure
we'd like to be able to take advantage of Adium's existing themes there, too.

Hopefully we could get the Adium guys involved here and hammer out a reasonable
XML schema for each of these areas.  The main point here though is that we would
all standardize on one common format, at which point all libpurple UIs could
take advantage of as few or as many of them as desired.  As we all know,
reinventing the wheel is a Bad Thing, and if we can restructure our code so that
other UIs can take advantage of our work, this is a win for the reduction of
reinvented wheels alone.

Of course, we would also need some new libpurple API to handle all this stuff.
I foresee a need for API that does at least the following:
  * add paths to the theme search list
  * get a list of all themes
  * get a hash table (just an example; insert other suitable method here) of the
items in the theme so that a smiley tree or status icon set can be built from
the data in the theme file

Now that I think about it more, I would also advocate expanding the status icon
theme to be a generic icon theme.  I would also advocate having a way for any
theme to specify that a particular item should be the UI's default.  For
example, in a notifaction theme we might want to specify that the icon shown in
the theme is the UI's default status icon instead of an icon specific to the theme.

For distributing themes, I would suggest a standardized list of formats, such as
.zip, .tar.gz, and .tar.bz2 wherever we can make these options viable, and have
the contents of the file match the .purple directory structure.  For example,
/themes in the archive would represent .purple/themes on the filesystem in my
vision.  Then we could have a function with a prototype like so:

gboolean purple_theme_install_from_archive(gchar *filename)

This function would do the necessary magic to properly install the theme to
.purple.  I envision the same thing happening for plugins (including the
contents of the archive exactly mirroring the directory structure of .purple),
at least for Windows systems, and I bet a few Linux distributions like Slackware
could make use of it as well.

I realize everything I've proposed here will result in sweeping changes and will
 essentially require a 3.0.0 if we do it.  In the long term, however, I think
this would be a net gain for us, especially if we get buy-in from the Adium
folks and can agree on standard, sensible formats.

Again, I apologize for the nearly encyclopedic length of this message.

John
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGuWsgBWJH/emdNtsRAmiHAKCak57XgdX0oS0i3mPcsJY9W1eYGgCfaXiG
b86AAWVWXLcgK4GcvauOraI=
=MO57
-----END PGP SIGNATURE-----