State of Pidgin: Discrete Installs

Gary Kramlich grim at
Tue Oct 3 03:14:19 EDT 2017

On Tue, Oct 3, 2017 at 2:07 AM, Eion Robb <eion at> wrote:

> If the codebase is being split, wouldn't it change from ~/.purple to
> ~/.pidgin?

Good point :)

> On 3 October 2017 at 18:58, Gary Kramlich <grim at> wrote:
>> 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,
>> Thanks,
>> --
>> Gary Kramlich <grim at>
>> _______________________________________________
>> Devel mailing list
>> Devel at


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

More information about the Devel mailing list