More Windows, more features

With a great help from LRN, who sent initial set of patches for fixing autotools-based build for win32 and assisted in the work, I have finally managed to make 3.0.0 cross compilation possible and easy. It also involved fixing minor win32 problems and enabling features that were not accessible for this platform before.

The most important change is making linux-to-windows cross-compilation almost as easy as normal build. The whole effort (not counting installation of mingw* packages) is reduced to setting two environmental variables (PKG_CONFIG and PKG_CONFIG_PATH) and adding a single switch to the configure script: ./configure --host=i686-w64-mingw32 && make. That’s all! For now, there is no option to cross-build the installer yet.

Finch working on Windows On the other hand, the most end-user-attractive change is a Finch win32 build. It required both libgnt and Finch fixes, which made those two quite usable on this system.

Moreover, I finally implemented all remaining features required for using OTR plugin with Finch. There is still one missing – you cannot browse key list yet, but it’s not crucial for a daily use. This change is not related to Windows and there may be minor problems when running the new OTR plugin on win32, but I will face all of them by the chance of integrating it with Pidgin tree.

An example of less significant, but still useful Windows related change is GTK3/gstreamer-1.0 compatibility, which was an easy to achieve with the fixed autotools build. I also removed the Bonjour SDK dependency from the win32 build, as there were license issues with it – for now, you can build Bonjour prpl without it.

The last feature may be found useless by some of you, while some might like it – that’s why it’s optional. You can enable Filesystem Hierarchy Standard directory structure with a single configure switch: --with-win32-dirs=fhs. For now, it’s the easiest way to prepare a working Windows build, since there is no cross-built installer yet.

Few steps towards a stable release

Pidgin 3 is not API/ABI compatible with Pidgin 2, and is only partially configuration-compatible. While the first incompatibility is necessary to move forward, the second might be really frustrating for users. Because of ABI incompatibility, libpurple2 plugins won’t work with libpurple3 – their authors will eventually convert them for the new version. Configuration incompatibility may lead to loosing your data – preferences, contacts etc.

Pidgin 3 was almost backward-compatible, which allowed to switch to it flawlessly. On the other hand, Pidgin 2 was not forward-compatible. For example, it dropped all encrypted passwords, that were set with Pidgin 3. Now, it won’t be able to read those (since keyring support is not implemented for 2.x.y branch), but at least it leaves them in place. I also fixed more forward-incompatibilities: handling for GTalk and Facebook XMPP accounts created with 3.0.0 version and internationalization issues related to default group (“Buddies”) naming. All of these will be released in 2.x.y branch, so you will be able to switch from 3.0.0 to 2.10.10 and back without loosing your data.

There were also minor, but annoying issues fixed. Nick colors for chat participants in XMPP MUC or irc should not suffer from a low-contrast issue. I have finally made spell checking usable, by implementing a language selection sub menu for WebKitGTK. It still has some flaws, that I will work on some day: the biggest one is that the selected language is global, not per-conversation.

To make development branch more stable, I decided to focus on Coverity bug reports. Since we are allowed to maintain just one branch at once, I decided to fix all 2.x.y reports before switching to 3.0.0. For now, I fixed almost all of them (and merged fixes to the 3.0.0 branch), so it should be a bit more stable. I also updated all win32 dependencies, which should also improve stability.

Don’t get me wrong, there is still a long way to the stable Pidgin 3.0.0. But it’s already usable right now.

Show me your desktop

An example usage of Screen Capture plugin I have switched from Konnekt (a local Polish instant messenger) to Pidgin around the year 2007. It provided a feature absent in Pidgin, that I missed very much: an easy way to send screenshots. There were a plugin for Pidgin 2.x.y, but I didn’t liked it and it wasn’t working with Pidgin 3.

Ultimately, I decided to invest two days of my life and create my own plugin. It just works, covering all attributes I liked in other instant messengers with such feature. It’s simple, stable and fits into the Pidgin UI well.

I plan to extend its functionality with another plugin. For now, it’s only possible to send screenshots over protocols with inline images support. Thus, you can not use it with XMPP or IRC. The second plugin will allow for uploading images to imgur (or similar services) for protocols that doesn’t support images.

15 thoughts on “More Windows, more features

  1. Thumbs up for your great work! I’m not using pidgin anymore, but the progress visible on the mailinglist lets me hope for a great 3.0 release.

    I also removed the Bonjour SDK dependency from the win32 build, as there were license issues with it – for now, you can build Bonjour prpl without it.

    You can build pidgin + bonjour prpl without the SDK? Will it run & work then? afaik there is no windows implementation of bonjour other than Apple’s.

    Pidgin 3 is not API/ABI compatible with Pidgin 2, and is only partially configuration-compatible

    Pidgin 3 was almost backward-compatible, which allowed to switch to it flawlessly

    So in the final 3.0 releases the old 2.x configuration will be silently used and/or converted to v3 format?

    • Thank you for your appreciation!

      I can *build* without the SDK, because it’s dynamically linked and the necessary headers are now in-tree. You’re right about Apple’s Bonjour implementation – just like for 2.x.y, you have to install “Bonjour Print Services for Windows” (see FAQ).

      Just like you described, old 2.x.y configuration is silently used. The format is almost the same, so there is not much conversion needed. And not only in the final release – it seems to work fine right now.

    • While it may be desirable for browsers, it’s totally a no-go for instant messenger. Just imagine having two conversations, with buddies who use different language. You would need to switch the language on every message being sent.

      My goal is not only to keep the same language within a conversation, but to make it saved with the buddy list. I want it to behave this way, because you usually talk with certain buddy with just one language.

  2. Does the console totally support Unicode that way? Finch is strictly UTF-8, so I wonder if it needs to write wide chars on Windows?

    • It supports Unicode partially. Input seems to be totally unicode, but output is converted to your locale. So, it works only for the subset of unicode, that is convertible for the console.

      I might be possible to do it better, but it would probably require more patches for ncurses too.

  3. Thank you for work on Pidgin. I was wondering if it would be possible to make the win32 binaries available for download?

  4. Hi, first of all thanks for the great work in pigdin!

    i use it since long time, in windows.

    second i want to know, when will be released the 3.0?

    • There are no plans for a stable 3.0.0 release. There might be some kind of alpha release this year, but don’t treat it as an official statement.

      The earliest win32 build will be the unofficial one published on this blog (it’s a matter of weeks).

    • I’m afraid 2.x.y will not receive such big features. We have a shortage of workforce at the moment, but I hope this year’s GSoC will bring Pidgin3 a bit closer to release.

  5. As this is the most current post on this blog in general and on Pidgin in particular, I’d just like to ask whether work on a 3.0.0 release is still continuing or not?!
    I am really looking forward to a new version of Pidgin for quite some time now. Your developments looked great. Would be nice to see and here new steps on the way to a 3.0.0 release.

Leave a Reply

Your email address will not be published. Required fields are marked *