Re: State of Pidgin: Discrete Installs

On Tue, Oct 3, 2017 at 2:07 AM, Eion Robb <[email protected]> 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 <[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
>>
>
>


-- 
Thanks,

--
Gary Kramlich <[email protected]>

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