We are ecstatic to announce that we have released the first experimental version of Pidgin 3.0!!! This is a pre alpha release with an official version number of 2.90.0. We will continue releasing in this fashion until we are ready for 3.0.0 which will be the release we consider ready for end users.
The release can be found on SourceForge.
Update:
Well it wouldn’t be the first release in a long time without a nearly immediate update… It turns out that we missed some bugs that affected new users and basically made things much harder to get started and crashed in some cases. So to fix that we have now released 2.90.1 which can be found on SourceForge. You can read more about the changes here Pidgin 2.90.1 has been released!
Please see the README file in the source code for building instructions. We recommend you use a meson devenv instead of installing directly to your OS installation.
This release has been the culmination of many years of work and a lot of churn. The ideas of this version started in 2008 but it wasn’t actually branched until 2011 (from what we can tell and remember).
This is a milestone release. It is something we think other tinkers and developers may want to start playing with, but it is not meant for end users. Most things are not implemented, the user interface has not been polished at all, and there are so many bugs. As such we are asking that packagers please do not package this for your users yet as the potential support requests will be too much for us to handle at this time.
Looking forward, we hope to be doing quarterly experimental releases with Experimental 2 scheduled for 2025-03-31. That release will most likely have a version number of 2.91.0 but things could change in the meantime.
We are also working on getting this release put up on Flathub beta, but due to some infrastructure issues they are having this won’t happen until the end of this week. We will update this post when it becomes available with instructions on how to install it.
Update:
The Flatpak is now agailable on Flathub Beta! You can find instructions on how to install it over here!
What took so long?
Gary documented some of the reasons why this release had been taking so long in his blog post titled What’s taking so long with Pidgin 3? but we’ll try to explain a bit more of that here.
Gary took over the project in January of 2016 thinking he would have 3.0 finished by the end of 2016. Gary lobbied to take over the project in late 2015. He was pushing GObjectification which ended up being nearly completely implemented but stalled and he believed this caused the project to slow down. He believed he shared a large part of the blame for this and wanted to take over to get the project going again.
While lobbying to taking over, Gary even joked that he really only wanted to be the lead developer for like two years or so. But here we are nine years later and he’s still leading and finally getting a pre alpha release out the door.
Over those nine years, productivity has ebbed and flowed a lot. Contributors have come and gone and we appreciate all the work that they have done for the project.
Although we did lose one contributor due to some extenuating circumstances. They had moved to the USA on an H-1B visa and the company they were working for decided that they didn’t like the legal gray area that some of our protocol code created. This meant that the contributor could no longer contribute and they found something else to do with their free time. Because of this, we instituted a new policy where only Open Source/open specification protocols are allowed in our main code repository.
The biggest idea for Pidgin 3 was to use the GObject type system that is included in GLib which we were already using extensively. This would give us better and more tested types and signals than the home grown ones we had and it would also give us reference counting which is something we desperately needed. Internally we called this “GObjectification”.
One of the issues in this migration was signals. In Purple 2 and earlier signals were class based. What that means is you would only have to connect to a single signal to get notified. An example of this is finding out when a new message was written to any conversation. This is very different from GObject signals that are instance based which means you have to connect to every instance to receive that signal. So in our example that means you have to connect to the new message signal on every conversation.
We spent a fair amount of time on this problem. Gary even wrote a proof of concept using some low level GObject API and submitted it GLib to get it merged. However they didn’t like the idea and rejected the pull request for performance reasons.
This put us back to the drawing board until we came up with the idea of “manager objects”. Gary wrote in detail about this on his blog post From Sub-Systems to Managers, but the short version is that we now have manager objects that hold a collection of objects and propagate the signals of those objects which solves the problem with just a tiny bit of overhead.
Initially Pidgin 3 supported both GTK+ 2 and 3 but shortly after Gary took over, GTK+ 2 support was dropped. A few years later, it was then decided we should just bite the bullet and move to GTK 4 instead, as GTK+ 3 was no longer being actively developed which meant we were just creating tech debt. As part of the GTK 4 migration we also pulled in Adwaita even though we’re not an official GNOME application.
At one point we were using WebKit as our conversation history with the intent to be able to support Adium themes. The initial work to do this was done using the WebKit1 API which eventually was being deprecated and removed from Linux distributions. We spent some time looking at WebKit 2, but when we found out there was no Windows port of it we had to give up on it.
After that we started a new library for input, history, and additional widgets named Talkatu. Talkatu let us experiment with these widgets and slowly bring them into Pidgin 3. We built it with the intent of it being used in other chat clients, but combining that with libpurple made things very difficult. So difficult that we ended up abandoning Talkatu and used the lessons we learned from it in Pidgin 3 directly.
But by far the biggest issue has been that all of the API in Pidgin 2 and earlier were designed for chat protocols AIM, ICQ, MSN, and Y!M. The largest issue here being about message delivery and display. With older chat protocols you couldn’t edit messages, react to them, reply to them, delete, or create threads from them. So most chat protocols had no way to identify a specific message.
Because of this, when Pidgin 2 and earlier would just display a message after receiving it and then completely forget about it. That means, all of our API was just passing that message around as a bare string. So to even get started with the above mentioned features, everything relating to messages had to be updated and reworked. Which in a chat application, is basically everything.
We decided to rework everything instead of starting from scratch as it seemed like we would be able to do things iteratively and keep the project working the entire time. However, over time we realized that the protocols were basically a lost cause.
The protocols hadn’t seen much work in many years and had all started to bit rot. All of the socket programming was done using the BSD socket interface, even on Windows, which is a story for another time.
In the mean time GIO became a thing which included a socket abstraction and streams built on top of it which simplified all of the networking code. This caused a lot of churn in the protocols and when combined with the new interfaces that we were designing for protocols, we decided that it was best to just start from scratch for them. This is why we currently only support IRCv3, but others will come in the near future.
This is just a small taste of the things that we have been working on. I hope it has been insightful and helped you all start to understand the kind of problems we have been facing and tackling.
ChangeLog
Here is the official ChangeLog from the release:
General
- Internationalization is just now getting started. Everything is marked
for translation, but we haven’t gottten anything translated yet. - The entire code base has been modernized with the hope of being more
friendly to everyone but especially new contributors. - Build system has been migrated to meson.
- Many things that were implemented internally have now been offloaded to
new and existing external libraries. - We have a new guide for contributors at
Instant Messaging Freedom Contributors Guide. - We’re not ever rewriting any of this in Rust.
libpurple
- Removed AIM themed nomenclature from the API. Buddy is now Contact,
Contact is now Person, Instant Message is now Direct Message, and Chat
is now Channel. - GPlugin has been adopted to handle plugins. This means plugins will have
to be ported or rewritten. - Every API has been completely overhauled and is now almost entirely
GObject based, which means the API is now introspectable. - Most Windows-specific code has been removed as it is now redundant.
- Finally adopted the XDG base directory specification so the .purple
directory is now XDG_CONFIG_HOME/. - Added support for storing passwords with libsecret, KWallet, wincred
(Windows), and keychain access (macOS). - Removed internal support for storing passwords (plain text).
- Started using SQLite for storing complex data like conversation history.
- Preferences have been moved to GSettings.
- Documentation is now created via gi-docgen and available at
Purple – 3.0.
Pidgin
- Migrated to GTK 4 and Adwaita.
- There has not yet to be any serious attempt to polish the user interface.
- Accessibility has been held off as we work through exactly how the user
interface is going to end up. - Most of the user interface is now defined in GTK Builder XML.
- Combined the contact list and conversation windows into a single window.
- Many features are not yet implemented.
- Most Windows-specific code has been removed as it is now redundant.
- Documentation is now created via gi-docgen and available at
Pidgin – 3.0.
Finch
- Finch has been removed, for now.
- It may make a comeback when Pidgin gets more stable and we have more
time.
Protocols
- Protocols have been moved from the libpurple directory to a new toplevel
protocols directory. - All existing protocols have been removed and new implementations are in
the works.
Bonjour
- A from scratch implementation based on Xeme, our new XMPP library.
- This is just a stub for now, and is not yet functional.
Demo
- A new protocol plugin for helping demonstrate Pidgin 3 features.
- Also used for testing and creating screenshots.
IRCv3
- A new IRC protocol has been implemented using Ibis, our new IRCv3
library. - It’s quite functional but missing a few things yet.
- SASL is implemented via HASL, our new SASL library.
- Added support for the following specifications:
- account-tag
- capability negotiation
- message ids
- message tags
- sasl-3.1
- server-time
- standard replies
- typing client-only tag
XMPP
- A from scratch implementation based on Xeme, our new XMPP library.
- This is just a stub for now, is not yet functional.
- SASL is implemented via HASL, our new SASL library.