State of Pidgin: Discrete Installs

Gary Kramlich grim at
Tue Oct 3 01:58:25 EDT 2017

Greetings Programs!

If you have not yet seen the introduction email with a subject of "State of
Pidgin: Introduction", please go read it first.

Currently it is impossible to have Pidgin2 and Pidgin3 installed side by
side.  This is honestly just a silly oversight because we didn't think 3.0
would be in development for a decade.  We handled most if not all of this
already for libpurple, but just didn't do it for PIdgin.  I personally
would love to be able to run both Pidgin2 and Pidgin3 side by side for
development and other testing.

There are a lot of potential issues that this brings up and these will be
the main topics of discussion.

The user configuration directory (${HOME}/.purple/) would need to changed
to match the running version.  Right now we support both versions with the
same directory and files.  This is nice because our preference code will
hold on to and write values that aren't registered in the preferences
system (I think, been a long time since I've been in that code).  However,
this also means that there's just cruft everywhere.  I'd like to create a
${HOME}/.purple3 if it doesn't exist and bring in the settings from
${HOME}/.purple if they exist.  This would only copy accounts.xml,
pounces.xml, and prefs.xml and thus create a hard fork of the
configurations.  There may be others files I'm forgetting right now.  This
can be annoying as users will have to update their backup plans and changes
to one version won't affect the other, but personally that was a nice
convenience that leads to a bunch of hard to debug issues.  I can't come up
with the specifics right now, but I'm sure there's cases where a
preferences was removed in Pidgin 3 and then it gets defaulted back to on
in PIdgin 2.

There is also the issue of the executable name changing.  While this will
primarily affect people hacking on pidgin as most users will be starting it
from it's desktop file.  However, that means there will be two PIdgin items
in their menus, but I personally don't think that's a big deal.  We can
update the desktop files to include the version in the name and it should
be fine.

Plugins aren't a huge deal as they don't work across versions, but that
also means it's a giant pain to swap versions while we're trying to get
people to test out alpha and beta releases of 3.0.  Basically each time you
switch you have to reinstall your plugins, that sucks.  Especially when you
have them installed to the user config directory.

Finally, themes and pixmaps are installed to a non-versioned directory.
Adding the version to is easy, but people will have to reinstall themes.
Again, I personally believe this is a good thing.  It forces users into the
opportunity to clean up their old themes and make sure they have ones that
*WILL* work with PIdgin 3 installed.  The pixmaps is mostly a non-issue as
Pidgin internally figures it out and third party plugins should be using
their own paths for most things, and in the case of PRPL icons, should be
getting the directory from purple-3.pc.

At any rate, this work should not be done until the build system discussion
has reach consensus as the amount of work is cut in half if we decided to
drop autotools.

Please discuss,


Gary Kramlich <grim at>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Devel mailing list