Pidgin 2.15.0?

Pidgin
1

I know I said the last minor version of Pidgin 2 would be 2.14, but there’s been some recently developments that I think justify a 2.15.0. I wanted to share them with you all and get your thoughts on moving forward with this idea.

As some of you know, we’ve been working towards extracting all of the proprietary and unmaintained protocols from the pidgin 2 source tree. This project is on going but can be found at github.com/pidgin/retro-prpl.

In short, the idea here is to have these protocols easily discoverable for research purposes as most information on them has been lost over time as well to make them easier for users to find and use with clone networks like retro aim server and others. This also gives us one source of truth to support which helps both users and ourselves.

During this work, we’ve been doing some additional work on the pidgin-windev environment to help automate everything. That work is now in github.com/pidgin/pidgin2-windev. That name is subject to change, but the idea is to simplify the build process for everyone.

While working on the windev stuff, I FINALLY think I’ve found what I need to know to upgrade gtk from 2.16 to 2.24 in the Windows build. This will fix a number of on going issues and we should definitely move forward on this because of it.

That said this would be a pretty major change, so it warrants a minor version bump. Since we’ll be bumping the major, it stands to reason that we could also remove the plugins that we have already put into retro-prpl which obviously will simplify maintenance for us.

So TL;DR we’re going to try to upgrade GTK+ 2 in Pidgin 2, and in doing so we’re going to remove the gadu-gadu, novell, sametime, silc, silc10, and zephyr protocols as they have been pulled into retro-prpl which includes msn, mxit, myspace, napster, oscar (AIM, ICQ), qq, toc, and yahoo.

What do you think?

3 Likes
2

The downside of deleting prpls is it will break logs, IIRC. Obviously, this can be worked around by downloading the retro-prpl copy, but maybe we can work out something to avoid that?

3

Yeah, the logs breaking is actually one of the reasons why I decided to copy EVERY protocol from purple2/gaim. I’ve had more than a few people complain that the logs got broken when we deleted aim, msn, icq, etc.

That said, I’m not really sure how we can go about fixing it, but I haven’t looked at that code in forever. Although I remember it needed the protocol to get the id or name or something, but we have that in the account at least in accounts.xml and there’s no reason why we couldn’t just do a big hard coded if when we can’t find the protocol plugin.

4

One of the other things I forgot, was that with retro-prpl we should show protocol plugins in plugin list so we can easily see the version numbers. With out that, support is going to be much harder.

1 Like
5

Do you have any plans on improving the XMPP support in 2.15? If yes, it would be really great to see https://issues.imfreedom.org/issue/PIDGIN-15508 and https://issues.imfreedom.org/issue/PIDGIN-15653 as a minimum to ensure communication without message loss. Thanks!

1 Like
6

I don’t suppose there’d be a way to make a sort of stub protocol plugin that can’t actually connect to anything (and probably just displays the previous login info with an explanation instead of letting you change anything) but could stand in as an updated version of it?

7

It’s extremely difficult to to anything with message history in purple2/pidgin2 as we don’t have a way to lookup messages after they’ve been written to the conversation window. This is something that is being fixed in purple3/pidgin and is the only place it can be done because it requires massive API changes.

Aside from that, I guess I wasn’t clear in defining the scope of 2.15.0 here. But here’s the rough list. If there’s something small or related to these, then sure, but the minor version bump is because we’re removing protocols.

  • remove the gadu-gadu, novell, sametime, silc, silc10, and zephyr protocols
  • update the version of gtk+2 we’re using on windows
1 Like
8

The stub would cause just as many issues as having the real plugin so doesn’t buy us much.

The problem is right here where a protocol instance is required. But we can update this to use protocol_id from the account to map it to the correct directory if the protocol isn’t found.

This would be an easy fix and doesn’t break anything if the protocols are reinstalled via retro-prpl or other means.

9

I’ve done the work for making logs work in /r/4016 so I guess I decided we’re doing 2.15.0 now? :smile: