Re: State of Pidgin: Discrete Installs

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

On 3 October 2017 at 18:58, Gary Kramlich <[email protected]> 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 <[email protected]>
>
> _______________________________________________
> Devel mailing list
> [email protected]
> https://pidgin.im/cgi-bin/mailman/listinfo/devel
>

_______________________________________________
Devel mailing list
[email protected]
https://pidgin.im/cgi-bin/mailman/listinfo/devel