I was reminiscing about Bonjour as a drop-dead easy to message people on the same LAN without any setup, and according to my acquaintance they tested it and it still works fine on Pidgin today: https://pidgin.im/help/protocols/bonjour/
I hope Bonjour is ported to Pidgin 3 :) Then I can text my partner across the room when the internet is down.
No, writing a large application in a language I would be learning is a horrible idea. Aside from that, C gives us the best integration to allow other languages to consume the library including plugins in pidgin and purple themselves.
Yes. The big change is a move from Gtk2 to Gtk4 (they skipped gtk3). Essentially Pidgin is being worked on by 1 or 2 people which is why it’s been so slow.
This is spot on, but I’d add that we’re also trying to make modern chat actually work in pidgin3. In pidgin 2 is impossible to address a message after it’s been displayed which means no redations, edits, reactions, moderation, etc.
Thank you for your work. I enjoyed Pidgin a lot as a child back in the good old days and it was an integral part of my Linux experience in those days. I will try to revisit it again. Good luck.
Speaking of which, does anyone know a good libpurple frontend (or at least something that does IRC, XMPP, and has a plugin for the new Google Talk) with QWidget-based (or at least the uncanny valley that is Kirigami) widgets?
I’m very much not a fan of all the GNOME-isms that have been leaking into things I can’t find a replacement for, like Inkscape. (eg. the buggy drop-shadows on menus that the Breeze theme is apparently powerless to remove.)
No existing Purple or Pidgin plugins will work with it and they will need to be ported to it as basically all of the API has changed.
:-S I’ve been hoping against hope that someone will make https://github.com/EionRobb/purple-teams work with free Teams so I can run it in bitlbee or weechat or something, but I’m guessing that’s even less likely now..
I mean, it can always be ported. A huge part of what’s changed between purple2 and purple3 (the library under pidgin) is to make modern protocols like teams integrate better.
I was around back then, and I assure you XMPP was no gem. :D Imagine an XML document that never ends. It had minor success when google absorbed it and then killed it (as they do to all projects), but the protocol was too heavy to get much traction outside of that. These days you would use something much simpler, like linefeed-terminated JSON or cap’n proto. [edit: I see these are already popular comments]
But I don’t want to yuck anyone’s yum, and I think if there’s a community that’s still maintaining and updating XMPP and having a good time, more power to them. It was the 2nd-weirdest chat protocol I’ve ever had to implement, and that probably makes it like a good classic car.
Imagine if IBM had been more successful with its early push for XMPP for the IoT niche and how many permanently vulnerable XML parsers would be hiding in smart deviced homes across the globe.
I maintained jabberd for the dorms at university when it was trending. Oh the joys of a 5kloc .xml config file and no failing line output on parser error. The plaintext storage of user credentials for the bridges was also not the best of choices. With less moral fibre in the diet one could’ve caused quite the mess with those.
With less moral fibre in the diet one could’ve caused quite the mess with those
On the plus side, at one point I realised that was the only place that my MSN Messenger login credentials were stored, which proved to be quite useful when I wanted to log in with the official client.
End users do not care nor know of the details of the protocol.
It didn’t succeeded because people favor systems where they provide their username and password and get their personal data at their fingertips. Contacts and message history. Message history lives in the clients. So if you would talk with a friend at home, then join at your work computer, context would be lost.
This is the same reason everyone moved to hosted email. And I would wager 99%+ of all email users use webmail. We should not underestimate the power of convenience. Richard Stalman does understand it but rejects it. He says that one should not let convenience deter you from your freedoms. But convenience is freedom too. What I am getting at is that even understanding convenience RMS essentially failed to win over it.
To build open systems that succeed we must not build them open at the expense of convenience. It won’t work. XMPP being just an example among many.
You’re already giving too much credit. IMHO it died because the clients either had major problems on mobile (Android ones sucked your battery dry, iOS.. not even sure and the desktop ones were all not-great). Too lazy to dig it up but I’ve written this story up many times. First I had 20 fellow nerds on jabber and then one by one they switched off their servers. Many migrated back to IRC even.
There was no extinction event (the google thing certainly didn’t help, but most people were too pessimistic about that from the start), it was just a mediocre experience for many years.And I’m talking about the people running their own servers here, not some rando casuals. (No ill will intended, mostly for hyperbole).
TBH back when I used XMPP, Pidgin seemed like the “flagship” desktop client, and it worked very well in my recollection. By the time I got a smartphone, XMPP was already pretty clearly in decline, and I had already fallen back to IRC because I didn’t have anyone left to talk to.
Edit: but now thinking back on it, I only ever used it for plaintext 1:1 conversations. I do have a few vague memories of running into some rough edges trying it for “MUC”; I was left with the distinct impression that multi-user chats were added on as an afterthought.
Pidgin was a popular choice, but it was never a good choice since it is by definition a lowest common denominator client among the various protocols it supports
yeah, maybe I was a little unfair to Pidgin, it kinda worked. So there was a usable client on Linux and Windows (and iirc Adium on mac). But mobile was the kicker. I got my first Android phone in 2009 and I felt more on the early adopter side there (it had the older bad screen. it was cool but not awesome) and the time I’m talking about is probably 2008ish to 2014ish.
I know, I’m not passing judgement, just trying to provide historical anecdata.
I’d really prefer if I’d have xmpp instead of whatsapp but still, Matrix seems to just fill the niche of onboarding non-technical people a lot better than anything I personally tried.
I haven’t made a serious evaluation of Pidgin in this decade and was definitely speaking in the historical context above. But circa “google xmpp was a thing” the purple ecosystem lacked for example ability to target a specific resource (not a thing generally wanted now, but was at the time), ad hoc commands and other sub things needed to interface with xmpp services beyond chat, any of the pep flavoured stuff like user tune and mood, etc. I used Psi at the time to get access to all these features.
I don’t say the above to say that Pidgin didn’t work for what it was. But I definitely had contacts who used it and I would gripe at them about how they were missing out on cool extras.
These days I have been given the impression by customers that Pidgin lack some modern fundamentals like support for server archive sync, but as I say I haven’t evaluated that personally.
Part of this was that the JSF did not build a reference client library. They initially had a reference server (jabberd), then decided to completely rewrite it (jabberd 2, which didn’t support transports and so for a while jabberd 2 users ended up also running a jabberd 1 instance to run each transport), then they moved to eJabberd as the reference implementation. This wasn’t perfect but at least there was one reference implementation of the server and JEP / XEPs that wanted to become standards track needed to be implemented in that server.
On the client side, it was very different. There really needed to be a permissively licensed client library that any client could use and that all new standards-track proposals needed to be implemented in (ideally, in addition to one other client with interoperability between the two). In the absence of this, new features were added in one random client and never got to interoperability. Few things advanced to standards track.
This led to a situation where there were twelve competing XEPs for important features and every client implemented one of them.
XMPP supports messages on multiple machines & history syncing with clients (which are a part of the Conversations compliance suite: https://compliance.conversations.im/tests/)
The only part that hasn’t been convenient is when OMEMO keys expire for other users when trying to join a client that hasn’t been opened in a while. …But this isn’t specific to XMPP, I had it with Matrix + Element (browser) this morning having messages not encrypted for my client. The difference was that XMPP I can get this message immediately instead of blocking the UI for 3 minutes on server syncing to then deliver me errors that messages aren’t encrypted.
Take a look at the date on those. 280 is the older one and is from 2010. I started using XMPP (Jabber, as it then was) in 2001. I started using ICQ in 1997, so there was less time between my first use of any IM protocol to switching to XMPP than there was between my starting to use XMPP and XMPP gaining a standard for message synchronisation (and the implementations came later). Google Talk launched in 2005, so this is five years later.
By 2010, XMPP was well into decline. I think I shut down my Jabber server in 2014, but no one had used it for a few years before that (it had about twenty users when I set it up, they all moved to other things and I stopped using it because I never saw any online contacts).
The extensible protocol got extended (for over a decade) to support features the parent post alluded to being missing. Whether or not older XMPP/Jabber met modern expectations a decade prior to these XEPs isn’t relevant to if it can meet user needs in 2024.
It is, because the user needs evolve over time. It took until 2010 to meet the needs of 2005 users (by then, logging in from multiple devices was common and lack of history was annoying). It’s now 2024 and user needs include:
End-to-end encryption that works with no configuration.
Metadata confidentiality.
Voice and video calling with end-to-end encryption.
And some of these are kind-of supported by the protocol, but not well supported by clients, the middle one can’t be added without a complete redesign.
I will always have a soft spot for XMPP. I was involved in the standardisation effort back before it was called XMPP, wrote two clients, and my involvement with XMPP got me the contract for my first book (stpeter had a contract with Pearson to write a book and didn’t have time so put me in contact with his editor to do it instead. His editor decided not to go ahead with the book, but asked me to write a different book instead). But it was clear by the time these extensions were added that the protocol was not the right design and that it could not be fixed by adding more things, it needed some fundamental changes from the ground up.
But it came to meet the needs like it could adapt again. As mentioned earlier, I have the same E2EE issue with Matrix–which also has metadata leaking issues. I use the voice/video calling with my partner since it is self-hosted & I can trust my own TLS connection even without E2EE, or Mumble when trying to voice chat with multiple folks, but I can’t say I need these as often as text. So is SimpleX the alternative albeit immature?
I am happy that thunderbird keeps developing and improves.
I feel like email is woefully underrated in its potential. It is a platform that has integration with Google, jira, miro, GitHub, git and many more. A good client could easily take advantage of that and extend the interface.
I could for example see thunderbird with a vcs plugin that allows you to preview and comment on email patches similar to GitHub etc.
I would love it if Thunderbird had deep enough understanding of GitHub to be able to do things like archive a thread of PR messages after the PR has merged. Or have some sort of “stale” metric for automated emails that automatically removes them from the inbox if I haven’t read them for two weeks.
A good client could easily take advantage of that and extend the interface.
100% this.
An underrated feature in T’bird $RECENT is the Matrix support. Matrix is a poor messaging system IMHO but it shows that part is getting some love. If T’bird could embrace libpurple and add a bunch of other modern messaging protocols, I would be delighted to dump a couple of messaging apps I have to keep around.
I use Ferdi for Slack/Whatsapp/Telegram/SMS/Skype/Discord/FB. I need to keep Signal around for one awkward person and one old channel.
In the past I had FB, Telegram, Skype, and Slack working well in Pidgin (alongside IRC and Rocket.chat, which I no longer really need).
Those are doable, realistic targets: there are working connectors for Pidgin. But I use macOS on the desktop and there’s no Pidgin for macOS. Adium hasn’t been updated in a decade and no longer works. Trillian, remarkably, does work but has almost no connectors in its Mac version.
I tried brew install pidgin a couple of months ago, the last time I was told about this. It does launch but it needed WINE. It’s a sort of port but it’s basically the Windows binary under translation, and I couldn’t work out where in the macOS filesystem I needed to place DLLs to get most protocols working.
I decided to give it a try right now, as something about this didn’t sound right after looking at the formula in Homebrew and not seeing anything WINE-ish. I’m on an M-series so it’s all Arm.
After installing Many dependencies, it all seemed to install OK. The default support included Gadu-Gadu, GTalk, GroupWise, IRC, SIMPLE, XMPP, Zephyr, so probably missing some important ones. I assume they go in /opt/homebrew/Cellar/pidgin/2.14.13/lib/purple-2/ since there’s a lot of things like libxmpp.os and related in there. Maybe it’d be OK now?
Damn this is my IRC client of choice. It has served me well for many years.
…and I suspect it will continue to do so, because as noted in the post, nobody can stop the code from living on. It’s not going to take too much effort to keep it functional.
I love this IRC client as well. I think part of why it’s so good is that it’s simple, yet it has all the features that are necessary. Also, the fact that it was barely maintained means that it just kept working without changing things all the time for no reason. These days, that’s an advantage because it means you don’t have to deal with perpetual breakage.
It’s not going to take too much effort to keep it functional.
It seems to be using GTK2. I guess if GTK2 is deprecated, that’ll be the end of it. Moving it to GTK3 or GTK4 would be quite a bit of effort, since the API was overhauled completely.
It seems to be using GTK2. I guess if GTK2 is deprecated, that’ll be the end of it.
When GTK3 was released, that signaled the beginning of the end for GTK for me. Step functions in API compatibility kill software ecosystems.
Python 3 nearly killed Python and for a long time many thought Python was dead in the long term. Perl 6 definitely killed Perl. Seems like Lua is slowly dying too now from newer incompatible updates.
I don’t think the release of GTK+ 3 is what killed Xchat or Hexchat but it may have contributed. It certainly makes picking up maintaining hexchat now seem more burdensome.
When GTK3 was released, that signaled the beginning of the end for GTK for me. Step functions in API compatibility kill software ecosystems.
Yes. I just don’t understand it. With every major release, they trash the entire ecosystem. First with GTK3, now again with GTK4. The amount of effort required to update a large software like LibreOffice to GTK4 is ridiculous. And it’s all busywork - once you’re done, not a single improvement was done to the software, you’re just using the new API. To the contrary, it is likely that a lot of new breakage was introduced.
Python 3 nearly killed Python and for a long time many thought Python was dead in the long term
Disagree on that. The 2 to 3 migration was a huge overreaction from the community, it really was not that bad. And it never came close to being the death of Python.
Python 2.7 was released 2010-07-03 (post Python 3). The final release of 2.7 was on 2020-04-20. Python 3 is still named “python3” on major distros. There were serious talks of forking 2.7 if it stopped being supported by Python.org and many major projects intentionally refused to adopt Python 3. Websites were made to track which major packages still were still on Python 2. I guess we just remember that decade differently.
No, all of this is correct. What I’m saying is that the community was needlessly difficult to deal with, on what was a completely reasonable major version.
No, the Python core teams screwed up. The community eventually invented “six” to allow forward compatibility from 2 to 3, and then the migration finally happened, but it should have been known beforehand that automatic code rewriting wouldn’t work and they would need a story for forward compatibility.
The really sad part is the from from __future__ import system had worked so well in Python up to that point! All they would have needed to do was to add more and some opt-in deprecation warnings and six would not have been necessary.
No, all of this is correct. What I’m saying is that the community was needlessly difficult to deal with, on what was a completely reasonable major version.
Agree to disagree but this major version required what one could essentially consider a rewrite of all Python code. I think responding with difficulty was fully warranted. That’s thousands and thousands of man-hours for a API change that didn’t give the vast majority of applications any perceivable improvement.
Python 3 is still named “python3” on major distros
That’s not necessarily a sign that python 3 adoption is slow. It could be that the policy is it’s a different, incompatible language; python2 has/had the “python” binary name and so python3 never should.
I think Perl already had its main losses way before Raku was vogue, and updates to Perl 5 only stopped for 2 years around that time (which IMO shouldn’t have much impact for a language so mature), With subsequent updates mostly being refining and replacing things.
I can’t even see the Perl 7 events on Google Trends, let alone Stack Overflow Insights. Which if there was a nail in the coffin, I think that would have been it.
Perl has been dead since at least around 2006. Maybe even earlier. The first implementation of Perl 6 (Pugs) was released on 2005-02-01. I’m old enough to also remember ParrotVM. Obviously there is still Perl 5 code running in production but the situation from the 90s has changed. It was once the case that a vast majority of new code was being written in Perl, that has now become only a tiny minority.
There are people that maintain GTK2 forks on GitHub. Yes, GTK2 requires X11, but as long as X11/Xwayland is around it should be ok. It’s actually easier to maintain GTK2 since it’s been abandoned and you don’t have to keep up with changes from upstream.
LuaJIT refuses to support Lua 5.4. I don’t know the details but based on the following link, it tells me the API changes weren’t handled well. https://github.com/LuaJIT/LuaJIT/issues/929
LuaJIT is remaining on the 5.1 API; I wouldn’t call that “newer incompatible updates” since 5.2 is very, very old.
It’s still pretty easy to write code that’s cross-compatible from 5.1-5.4; I do this for basically all the code I write. There’s a minor few annoyances here and there, but nothing anywhere close to the magnitude of Python 3 disruption.
Pidgin is really not a capable IRC client. Back in the olden days I used to use Pidgin for four or five different IM networks, but I still ran X-Chat/HexChat for IRC.
As the lead developer of Pidgin I see this comment all the time and it usually just ends up being “lack of status window” which we’re addressing in Pidgin 3. Is there anything else you care to mention?
Looks like there’s a new IRC protocol plugin since the last time I looked, which actually supports some of the post-2000 additions to the protocol, so I’ll retract my statement. The UI still isn’t exactly IRC-centric, and there are some other oddities (I saw a status message with someone’s IPv6 address in it get “:d” turned into a smiley!) but it appears better.
I mean the UI would never be IRC-centric, or any network centric, that’s kind of the whole point of the program to give you a chat interface that works for everything.
I mean, yeah fair enough; just as a general rule I can’t think of any application from the 1990s written in C or C++ that I’d recommend for handling untrusted external inputs, except for maaaybe openssh? (and even that might be a different story if an alternative existed)
Well you should also look at the CVE history of literally any browser.
But yeah, it’s true we had a number of CVE’s. That said, the vast majority of them were in protocol plugins and not our core library, libpurple, or the user interface Pidgin. But there’s a huge difference between the proper disclosure we follow and projects that don’t have a security process.
We’ve never hide the fact that we have security issues and have always followed responsible disclosure to try and protect users by having a fixed version out before announcing the issue.
You did not, but “fairly terrifying CVE track record” is a very strong statement.
That said, there was a prominent person in the security field that got a lot of people calling libpurple libcve which leads to comments like this all the time.
At any rate, Gaim from 1998 to 2006 had 52 CVEs[1] which is 6.5 CVEs per year. After the rename to Pidgin in 2006 until now we have 86 CVEs which is about 4.7 CVEs per year.
Obviously everyone’s opinion will vary, but that doesn’t seem too bad to me. Of course it’s not ideal, but all things considered, it could be a whole lot worse.
My client needs are pretty basic. I use znc between my end-client and the networks, which deals with the more advanced stuff. The main obstacle for using pidgin for IRC, for me, is needing to put a bit of work into the UI settings.
I thing major; I just haven’t got the feel to be as comfortable yet. Probably need a font size tweak, maybe a tab bar style tweak, small stuff like that.
Is SourceForge still a thing? I’m asking this honestly, because I remember a couple of years ago most projects there were abandonware with defunct/spammed lists. On top of that, the download page looked really like one of these sleazy download pages crammed with ads, which claim that the file you’re looking for is behind their button.
I used to be an avid user of Pidgin. I really miss the times when the Big Internet have been using open protocols and it was possible to federate with them. Hell, I miss the time when it was feasible to reverse engineer their protocols and make alternative clients.
It’s terrifying that by now, “historical” is a right tag to put on a post about Pidgin even if that post was written yesterday.
There’s been some rudimentary work towards this, but afaik nothing has come of that yet. From what I was told, it looks a lot like skypeweb, so it wouldn’t be too crazy to get the basics working.
UX model. How do you get a threaded chat app that isn’t very AIM like in Pidgin? Trying to do so within the confines of both libpurple and Pidgin would seem very clumsy to me.
Cultural shift. Pidgin isn’t as well maintained as it used to be, and so interest waned in Pidgin. This was brought on by things like the dream of federated messaging fading away; but perhaps it doesn’t really explain why the interest in getting things like say, Slack reverse engineered and keeping up with their treadmill has dissipated from back when the community was doing it to AIM/MSNP/etc. (Perhaps Linux users are satisfied with their Electron apps, and see no need to have it in Pidgin, as that’s how they’d previously have an app at all.)
Biggest reason being that I want to have all my chats in one place. It reduces the mental load of using another application. Also I hate the resource usage of electron apps.
(Perhaps Linux users are satisfied with their Electron apps, and see no need to have it in Pidgin, as that’s how they’d previously have an app at all.)
I think this pretty much sums it up. AOL, MS, etc. didn’t ship Linux clients at all, there weren’t even browser-based clients in most cases. The marginal gain to something like Pidgin was huge because you could go from literally nothing to something that more or less worked. What’s the marginal gain from reverse engineering Slack or Teams? You don’t have to use a browser-based app or a bloated Electron app, but that’s a whole lot less motivating.
(Perhaps Linux users are satisfied with their Electron apps, and see no need to have it in Pidgin, as that’s how they’d previously have an app at all.)
Yup. I’d prefer a nice, slick app - but I’ve stopped using Pidgin years ago. I never loved it, but it was good enough for ICQ/XMPP - but at some point I switched to Gajim. Also didn’t libpurple have a ton of bugs?
I think satisfied is the wrong term, but sometimes the “least bad” option is going in a different direction for different people. I also used Slack via IRC bridge for a long time and it was often a pain, to be honest. Not getting updates if people edited messages. No threading…
Yes the UI model is a problem, its something we’re working on… That said, there is already a slack plugin and it works well enough for many. That said I’m curious on where you’re getting your info..
I’ve written a tool to do this using Docker “build containers”. For the non-amd64 linux stuff you’d have to setup a cross compiler, but it is doable. You can find the tool at https://bitbucket.org/rw_grim/convey.
Thanks! This looks like it’s solving a very similar problem as the one I have. So this is a tool to specify the build environment for Pidgin across multiple platforms? And I assume you have some kind of continuous build/testing, like either pre-release or pre/post-commit?
Is there a dashboard for the continuous build? I’d be interested to see what it looks like.
It seems like newer open source projects use cloud services for this, but older ones roll have their own servers… I might want to use my own servers too.
Right now it’s just being triggered by bamboo. You can see it at https://bamboo.pidgin.im but it’s not setup to use all of this yet. I need to finish building some Docker images for some dependencies and stuff.
Aside from that I am working on (albeit slowly) a webapp that’s specially for this so you don’t need to use Jenkins/Bamboo/etc.
Luckily I’ve never hit RSI so I basically use whatever keyboard is available the the time. I’ve dabbled in mechanical keyboards but I honestly don’t notice any difference from typing on a rubber dome except for the noise.
I’m currently back in the lovely tiled arms of i3wm.
I really appreciate the tiled window layout approach, but i3 also plays nice with dialog windows, and it has an explicit floating mode for when you really need it. At work and at home I use a Dell Ultrasharp IPS with 2560x1440 resolution.
i3 as well. The thing I like about it, over other tiling window managers I’ve tried, is that layout is manual: you can decide on the fly how you want windows laid out, rearrange them, restack, etc instead of having a single hardcoded layout that everything goes in.
I also use this tool by fellow lobster @cmhamill to get wmii-like dynamic workspace tagging. Just using numbered workspaces, I frequently tend to run out.
(I migrated to i3 over wmii, which is similar but a bit more restricted, mostly for a more elegant internal model and support for a small handful of additional window manager hints. There is something (several somethings, really) to be said for the fact that wmii’s event loop is literally a shell script, but I wasn’t making any use of the capabilities. i3 supports massively more sophisticated layouts than wmii, but the interface makes my brain hurt, so in practice I don’t use them much.)
i3 for me too. I am interested to see how things evolve; I’m running Fedora which is shaping up to make a move to Wayland; others will almost certainly follow. As I understand it i3 doesn’t currently support Wayland, so it’ll be interesting to see if the maintainers make the port, or if Sway will become the replacement.
It’s going to be interesting to see what happens with tiling window managers and wayland, since from what I understand application sunder Wayland are going to be drawing their own window decorations, which conflicts pretty hard with tiling WMs.
It’s a lot more complicated than that. The Wayland- aware applications (some QT versions and some GTK versions) can be forced to ignore drawing decorations, and a lot of applications run from XWayland which is “all of the Xorg.server inside a .so and some conversion” that follow the old model. THEN you have unstable protocols that extend wayland, like the one used by KWin that says ‘no, decorations should be server-side’. A rant from the WLC developer (that provides most of the compositor implementation for Sway):
It hits the sweet spot between being customisable, yet having sensible defaults and having the ability to completely fade away into the background so that I don’t have to think about it at all on most days.
At work I’m on OSX, but at home I can’t get away from i3wm. So good. It’s so good I’m considering reinstalling Ubuntu over my MBP just to use i3wm as a daily driver.
i3wm too, running it on Arch Linux on my ThinkPad and desktop computer. I’ve seen some videos on customization but I feel like I’m just scratching the surface. I use a model M on my desktop so I’m thinking of reusing an old foot pedal I found to emulate the Windows meta key.
I really want to like i3, but the default keybindings interfere with emacs keybindings. Haven’t decided yet if I want to use evil mode in emacs or overhaul the i3 keybindings. Has anyone else found a nice solution to this?
I am a heavy Emacs user. In my i3 configuration, I configured windows key as the $mod key, so there are no conflicts between it and my emacs. (I know some people bind windows-key in their emacs. I am not one of those people.)
I gave it another try with super/windows-key as $mod, and so far I’m loving it, it really does “fade away into the background” as Todd says below. Spent some parts of the day tweaking, I really love the simplicity, so far no compatibility issues (Debian stretch with Gnome).
i3 as well for a couple of months now. Before that I had been running XFCE for a very long time, but I’ll probably stick with i3 for one reason, that workspaces don’t flip on all monitors when switching.
I was reminiscing about Bonjour as a drop-dead easy to message people on the same LAN without any setup, and according to my acquaintance they tested it and it still works fine on Pidgin today: https://pidgin.im/help/protocols/bonjour/
I hope Bonjour is ported to Pidgin 3 :) Then I can text my partner across the room when the internet is down.
We started, but it’s not quite working yet and will be awhile before we get there.
Yes Bonjour is on the list for Pidgin 3 :)
Since you’ve had to break compat with v2 and there’s so much to change, did you consider starting over with a different implementation language?
No, writing a large application in a language I would be learning is a horrible idea. Aside from that, C gives us the best integration to allow other languages to consume the library including plugins in pidgin and purple themselves.
sensible. Thanks for the response!
Is there an overarching idea behind this major update? The post has some information but I don’t see the bigger picture in it.
Yes. The big change is a move from Gtk2 to Gtk4 (they skipped gtk3). Essentially Pidgin is being worked on by 1 or 2 people which is why it’s been so slow.
This is spot on, but I’d add that we’re also trying to make modern chat actually work in pidgin3. In pidgin 2 is impossible to address a message after it’s been displayed which means no redations, edits, reactions, moderation, etc.
And of course a host of other things as well.
Thank you for your work. I enjoyed Pidgin a lot as a child back in the good old days and it was an integral part of my Linux experience in those days. I will try to revisit it again. Good luck.
Thanks
Speaking of which, does anyone know a good libpurple frontend (or at least something that does IRC, XMPP, and has a plugin for the new Google Talk) with QWidget-based (or at least the uncanny valley that is Kirigami) widgets?
I’m very much not a fan of all the GNOME-isms that have been leaking into things I can’t find a replacement for, like Inkscape. (eg. the buggy drop-shadows on menus that the Breeze theme is apparently powerless to remove.)
:-S I’ve been hoping against hope that someone will make https://github.com/EionRobb/purple-teams work with free Teams so I can run it in bitlbee or weechat or something, but I’m guessing that’s even less likely now..
I mean, it can always be ported. A huge part of what’s changed between purple2 and purple3 (the library under pidgin) is to make modern protocols like teams integrate better.
aha, that’s good to hear :-)
I was around back then, and I assure you XMPP was no gem. :D Imagine an XML document that never ends. It had minor success when google absorbed it and then killed it (as they do to all projects), but the protocol was too heavy to get much traction outside of that. These days you would use something much simpler, like linefeed-terminated JSON or cap’n proto. [edit: I see these are already popular comments]
But I don’t want to yuck anyone’s yum, and I think if there’s a community that’s still maintaining and updating XMPP and having a good time, more power to them. It was the 2nd-weirdest chat protocol I’ve ever had to implement, and that probably makes it like a good classic car.
Traumatised.
It’s actually worse than that. It’s two XML documents that never end, which have some ordering between stanzas in them.
Imagine if IBM had been more successful with its early push for XMPP for the IoT niche and how many permanently vulnerable XML parsers would be hiding in smart deviced homes across the globe.
I maintained jabberd for the dorms at university when it was trending. Oh the joys of a 5kloc .xml config file and no failing line output on parser error. The plaintext storage of user credentials for the bridges was also not the best of choices. With less moral fibre in the diet one could’ve caused quite the mess with those.
On the plus side, at one point I realised that was the only place that my MSN Messenger login credentials were stored, which proved to be quite useful when I wanted to log in with the official client.
End users do not care nor know of the details of the protocol. It didn’t succeeded because people favor systems where they provide their username and password and get their personal data at their fingertips. Contacts and message history. Message history lives in the clients. So if you would talk with a friend at home, then join at your work computer, context would be lost. This is the same reason everyone moved to hosted email. And I would wager 99%+ of all email users use webmail. We should not underestimate the power of convenience. Richard Stalman does understand it but rejects it. He says that one should not let convenience deter you from your freedoms. But convenience is freedom too. What I am getting at is that even understanding convenience RMS essentially failed to win over it.
To build open systems that succeed we must not build them open at the expense of convenience. It won’t work. XMPP being just an example among many.
You’re already giving too much credit. IMHO it died because the clients either had major problems on mobile (Android ones sucked your battery dry, iOS.. not even sure and the desktop ones were all not-great). Too lazy to dig it up but I’ve written this story up many times. First I had 20 fellow nerds on jabber and then one by one they switched off their servers. Many migrated back to IRC even.
There was no extinction event (the google thing certainly didn’t help, but most people were too pessimistic about that from the start), it was just a mediocre experience for many years.And I’m talking about the people running their own servers here, not some rando casuals. (No ill will intended, mostly for hyperbole).
TBH back when I used XMPP, Pidgin seemed like the “flagship” desktop client, and it worked very well in my recollection. By the time I got a smartphone, XMPP was already pretty clearly in decline, and I had already fallen back to IRC because I didn’t have anyone left to talk to.
Edit: but now thinking back on it, I only ever used it for plaintext 1:1 conversations. I do have a few vague memories of running into some rough edges trying it for “MUC”; I was left with the distinct impression that multi-user chats were added on as an afterthought.
Oh, don’t be so harsh, IRC isn’t that bad :)
Oh haha, yeah that was unclear, I meant I fell back to using IRC exclusively. I never stopped using IRC and hope to never have to in the future.
Pidgin was a popular choice, but it was never a good choice since it is by definition a lowest common denominator client among the various protocols it supports
yeah, maybe I was a little unfair to Pidgin, it kinda worked. So there was a usable client on Linux and Windows (and iirc Adium on mac). But mobile was the kicker. I got my first Android phone in 2009 and I felt more on the early adopter side there (it had the older bad screen. it was cool but not awesome) and the time I’m talking about is probably 2008ish to 2014ish.
Luckily that has changed since the ’10s. Conversations & its forks, like Cheogram which I use, are pretty much the lightest weight chat clients on Android in terms of battery, RAM, & bandwidth. See: https://decentim.grafana.net/public-dashboards/92602d3a4aa842ce97812d310077691d?orgId=1
I know, I’m not passing judgement, just trying to provide historical anecdata.
I’d really prefer if I’d have xmpp instead of whatsapp but still, Matrix seems to just fill the niche of onboarding non-technical people a lot better than anything I personally tried.
Can you elaborate on this? We are constantly trying to support as many features as we can from every protocol.
I haven’t made a serious evaluation of Pidgin in this decade and was definitely speaking in the historical context above. But circa “google xmpp was a thing” the purple ecosystem lacked for example ability to target a specific resource (not a thing generally wanted now, but was at the time), ad hoc commands and other sub things needed to interface with xmpp services beyond chat, any of the pep flavoured stuff like user tune and mood, etc. I used Psi at the time to get access to all these features.
I don’t say the above to say that Pidgin didn’t work for what it was. But I definitely had contacts who used it and I would gripe at them about how they were missing out on cool extras.
These days I have been given the impression by customers that Pidgin lack some modern fundamentals like support for server archive sync, but as I say I haven’t evaluated that personally.
Thanks for elaborating
Part of this was that the JSF did not build a reference client library. They initially had a reference server (jabberd), then decided to completely rewrite it (jabberd 2, which didn’t support transports and so for a while jabberd 2 users ended up also running a jabberd 1 instance to run each transport), then they moved to eJabberd as the reference implementation. This wasn’t perfect but at least there was one reference implementation of the server and JEP / XEPs that wanted to become standards track needed to be implemented in that server.
On the client side, it was very different. There really needed to be a permissively licensed client library that any client could use and that all new standards-track proposals needed to be implemented in (ideally, in addition to one other client with interoperability between the two). In the absence of this, new features were added in one random client and never got to interoperability. Few things advanced to standards track.
This led to a situation where there were twelve competing XEPs for important features and every client implemented one of them.
XMPP supports messages on multiple machines & history syncing with clients (which are a part of the Conversations compliance suite: https://compliance.conversations.im/tests/)
The only part that hasn’t been convenient is when OMEMO keys expire for other users when trying to join a client that hasn’t been opened in a while. …But this isn’t specific to XMPP, I had it with Matrix + Element (browser) this morning having messages not encrypted for my client. The difference was that XMPP I can get this message immediately instead of blocking the UI for 3 minutes on server syncing to then deliver me errors that messages aren’t encrypted.
Take a look at the date on those. 280 is the older one and is from 2010. I started using XMPP (Jabber, as it then was) in 2001. I started using ICQ in 1997, so there was less time between my first use of any IM protocol to switching to XMPP than there was between my starting to use XMPP and XMPP gaining a standard for message synchronisation (and the implementations came later). Google Talk launched in 2005, so this is five years later.
By 2010, XMPP was well into decline. I think I shut down my Jabber server in 2014, but no one had used it for a few years before that (it had about twenty users when I set it up, they all moved to other things and I stopped using it because I never saw any online contacts).
The extensible protocol got extended (for over a decade) to support features the parent post alluded to being missing. Whether or not older XMPP/Jabber met modern expectations a decade prior to these XEPs isn’t relevant to if it can meet user needs in 2024.
It is, because the user needs evolve over time. It took until 2010 to meet the needs of 2005 users (by then, logging in from multiple devices was common and lack of history was annoying). It’s now 2024 and user needs include:
And some of these are kind-of supported by the protocol, but not well supported by clients, the middle one can’t be added without a complete redesign.
I will always have a soft spot for XMPP. I was involved in the standardisation effort back before it was called XMPP, wrote two clients, and my involvement with XMPP got me the contract for my first book (stpeter had a contract with Pearson to write a book and didn’t have time so put me in contact with his editor to do it instead. His editor decided not to go ahead with the book, but asked me to write a different book instead). But it was clear by the time these extensions were added that the protocol was not the right design and that it could not be fixed by adding more things, it needed some fundamental changes from the ground up.
But it came to meet the needs like it could adapt again. As mentioned earlier, I have the same E2EE issue with Matrix–which also has metadata leaking issues. I use the voice/video calling with my partner since it is self-hosted & I can trust my own TLS connection even without E2EE, or Mumble when trying to voice chat with multiple folks, but I can’t say I need these as often as text. So is SimpleX the alternative albeit immature?
Who would? Has anyone?
I am happy that thunderbird keeps developing and improves.
I feel like email is woefully underrated in its potential. It is a platform that has integration with Google, jira, miro, GitHub, git and many more. A good client could easily take advantage of that and extend the interface.
I could for example see thunderbird with a vcs plugin that allows you to preview and comment on email patches similar to GitHub etc.
I would love it if Thunderbird had deep enough understanding of GitHub to be able to do things like archive a thread of PR messages after the PR has merged. Or have some sort of “stale” metric for automated emails that automatically removes them from the inbox if I haven’t read them for two weeks.
I believe Thunderdbird’s message filters (accessed through the “Tools” menu) is exactly what you want.
100% this.
An underrated feature in T’bird $RECENT is the Matrix support. Matrix is a poor messaging system IMHO but it shows that part is getting some love. If T’bird could embrace
libpurpleand add a bunch of other modern messaging protocols, I would be delighted to dump a couple of messaging apps I have to keep around.I use Ferdi for Slack/Whatsapp/Telegram/SMS/Skype/Discord/FB. I need to keep Signal around for one awkward person and one old channel.
In the past I had FB, Telegram, Skype, and Slack working well in Pidgin (alongside IRC and Rocket.chat, which I no longer really need).
Those are doable, realistic targets: there are working connectors for Pidgin. But I use macOS on the desktop and there’s no Pidgin for macOS. Adium hasn’t been updated in a decade and no longer works. Trillian, remarkably, does work but has almost no connectors in its Mac version.
For what it’s worth… Pidgin is in homebrew and works without an X server
I tried
brew install pidgina couple of months ago, the last time I was told about this. It does launch but it needed WINE. It’s a sort of port but it’s basically the Windows binary under translation, and I couldn’t work out where in the macOS filesystem I needed to place DLLs to get most protocols working.I decided to give it a try right now, as something about this didn’t sound right after looking at the formula in Homebrew and not seeing anything WINE-ish. I’m on an M-series so it’s all Arm.
After installing Many dependencies, it all seemed to install OK. The default support included Gadu-Gadu, GTalk, GroupWise, IRC, SIMPLE, XMPP, Zephyr, so probably missing some important ones. I assume they go in
/opt/homebrew/Cellar/pidgin/2.14.13/lib/purple-2/since there’s a lot of things likelibxmpp.osand related in there. Maybe it’d be OK now?Really? How very odd. I will try again. After the unsuccessful attempt, I removed it.
Damn this is my IRC client of choice. It has served me well for many years.
…and I suspect it will continue to do so, because as noted in the post, nobody can stop the code from living on. It’s not going to take too much effort to keep it functional.
I love this IRC client as well. I think part of why it’s so good is that it’s simple, yet it has all the features that are necessary. Also, the fact that it was barely maintained means that it just kept working without changing things all the time for no reason. These days, that’s an advantage because it means you don’t have to deal with perpetual breakage.
It seems to be using GTK2. I guess if GTK2 is deprecated, that’ll be the end of it. Moving it to GTK3 or GTK4 would be quite a bit of effort, since the API was overhauled completely.
(Source: https://github.com/hexchat/hexchat/blob/master/src/fe-gtk/meson.build#L31C1-L31C55)
I’d like to thank the authors for creating and maintaining this useful application for as long as they did.
When GTK3 was released, that signaled the beginning of the end for GTK for me. Step functions in API compatibility kill software ecosystems.
Python 3 nearly killed Python and for a long time many thought Python was dead in the long term. Perl 6 definitely killed Perl. Seems like Lua is slowly dying too now from newer incompatible updates.
I don’t think the release of GTK+ 3 is what killed Xchat or Hexchat but it may have contributed. It certainly makes picking up maintaining hexchat now seem more burdensome.
Yes. I just don’t understand it. With every major release, they trash the entire ecosystem. First with GTK3, now again with GTK4. The amount of effort required to update a large software like LibreOffice to GTK4 is ridiculous. And it’s all busywork - once you’re done, not a single improvement was done to the software, you’re just using the new API. To the contrary, it is likely that a lot of new breakage was introduced.
Disagree on that. The 2 to 3 migration was a huge overreaction from the community, it really was not that bad. And it never came close to being the death of Python.
Python 2.7 was released 2010-07-03 (post Python 3). The final release of 2.7 was on 2020-04-20. Python 3 is still named “python3” on major distros. There were serious talks of forking 2.7 if it stopped being supported by Python.org and many major projects intentionally refused to adopt Python 3. Websites were made to track which major packages still were still on Python 2. I guess we just remember that decade differently.
No, all of this is correct. What I’m saying is that the community was needlessly difficult to deal with, on what was a completely reasonable major version.
No, the Python core teams screwed up. The community eventually invented “six” to allow forward compatibility from 2 to 3, and then the migration finally happened, but it should have been known beforehand that automatic code rewriting wouldn’t work and they would need a story for forward compatibility.
The really sad part is the from
from __future__ importsystem had worked so well in Python up to that point! All they would have needed to do was to add more and some opt-in deprecation warnings and six would not have been necessary.Agree to disagree but this major version required what one could essentially consider a rewrite of all Python code. I think responding with difficulty was fully warranted. That’s thousands and thousands of man-hours for a API change that didn’t give the vast majority of applications any perceivable improvement.
That’s not necessarily a sign that python 3 adoption is slow. It could be that the policy is it’s a different, incompatible language; python2 has/had the “python” binary name and so python3 never should.
I think Perl already had its main losses way before Raku was vogue, and updates to Perl 5 only stopped for 2 years around that time (which IMO shouldn’t have much impact for a language so mature), With subsequent updates mostly being refining and replacing things.
I can’t even see the Perl 7 events on Google Trends, let alone Stack Overflow Insights. Which if there was a nail in the coffin, I think that would have been it.
Perl has been dead since at least around 2006. Maybe even earlier. The first implementation of Perl 6 (Pugs) was released on 2005-02-01. I’m old enough to also remember ParrotVM. Obviously there is still Perl 5 code running in production but the situation from the 90s has changed. It was once the case that a vast majority of new code was being written in Perl, that has now become only a tiny minority.
There are people that maintain GTK2 forks on GitHub. Yes, GTK2 requires X11, but as long as X11/Xwayland is around it should be ok. It’s actually easier to maintain GTK2 since it’s been abandoned and you don’t have to keep up with changes from upstream.
What changes are you thinking of? The main incompatibility I can think of is replacing
setfenvwith_ENV, and that happened over a decade ago.Maybe the divergence between 5.1 and later mattering because LuaJIT? That’s more Pall’s personal taste though.
LuaJIT refuses to support Lua 5.4. I don’t know the details but based on the following link, it tells me the API changes weren’t handled well. https://github.com/LuaJIT/LuaJIT/issues/929
LuaJIT is remaining on the 5.1 API; I wouldn’t call that “newer incompatible updates” since 5.2 is very, very old.
It’s still pretty easy to write code that’s cross-compatible from 5.1-5.4; I do this for basically all the code I write. There’s a minor few annoyances here and there, but nothing anywhere close to the magnitude of Python 3 disruption.
Mine too. If it went away I might move sideways to Pidgin (which I use for WhatsApp and discord), but hexchat just works for me.
Pidgin is really not a capable IRC client. Back in the olden days I used to use Pidgin for four or five different IM networks, but I still ran X-Chat/HexChat for IRC.
As the lead developer of Pidgin I see this comment all the time and it usually just ends up being “lack of status window” which we’re addressing in Pidgin 3. Is there anything else you care to mention?
Looks like there’s a new IRC protocol plugin since the last time I looked, which actually supports some of the post-2000 additions to the protocol, so I’ll retract my statement. The UI still isn’t exactly IRC-centric, and there are some other oddities (I saw a status message with someone’s IPv6 address in it get “:d” turned into a smiley!) but it appears better.
I mean the UI would never be IRC-centric, or any network centric, that’s kind of the whole point of the program to give you a chat interface that works for everything.
It’s also got a fairly terrifying CVE track record.
Just like any other 25 year old software project…
I mean, yeah fair enough; just as a general rule I can’t think of any application from the 1990s written in C or C++ that I’d recommend for handling untrusted external inputs, except for maaaybe openssh? (and even that might be a different story if an alternative existed)
Well you should also look at the CVE history of literally any browser.
But yeah, it’s true we had a number of CVE’s. That said, the vast majority of them were in protocol plugins and not our core library, libpurple, or the user interface Pidgin. But there’s a huge difference between the proper disclosure we follow and projects that don’t have a security process.
We’ve never hide the fact that we have security issues and have always followed responsible disclosure to try and protect users by having a fixed version out before announcing the issue.
You can also see a full listing of all security issues on our website https://pidgin.im/about/security/advisories/. Where as something like chrome you need to go looking for on your own https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-15031/opec-1/Google-Chrome.html.
Whoops here’s some better links :-D
Chrome: https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-15031/Google-Chrome.html Pidgin: https://www.cvedetails.com/vulnerability-list/vendor_id-6938/product_id-11666/Pidgin-Pidgin.html
If I ever said anything that gave the impression that I recommend trusting Chrome, I assure you it was not intentional!
You did not, but “fairly terrifying CVE track record” is a very strong statement.
That said, there was a prominent person in the security field that got a lot of people calling libpurple libcve which leads to comments like this all the time.
At any rate, Gaim from 1998 to 2006 had 52 CVEs[1] which is 6.5 CVEs per year. After the rename to Pidgin in 2006 until now we have 86 CVEs which is about 4.7 CVEs per year.
Obviously everyone’s opinion will vary, but that doesn’t seem too bad to me. Of course it’s not ideal, but all things considered, it could be a whole lot worse.
[1] https://www.cvedetails.com/version-list/648/1108/1/Rob-Flynn-Gaim.html
My client needs are pretty basic. I use znc between my end-client and the networks, which deals with the more advanced stuff. The main obstacle for using pidgin for IRC, for me, is needing to put a bit of work into the UI settings.
What kind of work are you thinking?
I thing major; I just haven’t got the feel to be as comfortable yet. Probably need a font size tweak, maybe a tab bar style tweak, small stuff like that.
Gotcha, well the UI is being completely overhauled for Pidgin 3 and we’re always looking for suggestions.
Ah cool! (My last reply should have read “nothing major” btw)
Yeah no worries. Just trying to get honest user feedback. It’s hard than you think :)
Is SourceForge still a thing? I’m asking this honestly, because I remember a couple of years ago most projects there were abandonware with defunct/spammed lists. On top of that, the download page looked really like one of these sleazy download pages crammed with ads, which claim that the file you’re looking for is behind their button.
Yes they’re still definitely a thing. They’ve been under new management since 2016 https://arstechnica.com/information-technology/2016/06/under-new-management-sourceforge-moves-to-put-badness-in-past/
I used to be an avid user of Pidgin. I really miss the times when the Big Internet have been using open protocols and it was possible to federate with them. Hell, I miss the time when it was feasible to reverse engineer their protocols and make alternative clients.
It’s terrifying that by now, “historical” is a right tag to put on a post about Pidgin even if that post was written yesterday.
We do have at least basic chat support for many of the modern protocols.. https://pidgin.im/plugins/?publisher=all&query=&type=Protocol
That list looks promising. I need to give it another try, thanks for pointing it out!
There’s been some rudimentary work towards this, but afaik nothing has come of that yet. From what I was told, it looks a lot like skypeweb, so it wouldn’t be too crazy to get the basics working.
It’s a little bit:
UX model. How do you get a threaded chat app that isn’t very AIM like in Pidgin? Trying to do so within the confines of both libpurple and Pidgin would seem very clumsy to me.
Cultural shift. Pidgin isn’t as well maintained as it used to be, and so interest waned in Pidgin. This was brought on by things like the dream of federated messaging fading away; but perhaps it doesn’t really explain why the interest in getting things like say, Slack reverse engineered and keeping up with their treadmill has dissipated from back when the community was doing it to AIM/MSNP/etc. (Perhaps Linux users are satisfied with their Electron apps, and see no need to have it in Pidgin, as that’s how they’d previously have an app at all.)
Biggest reason being that I want to have all my chats in one place. It reduces the mental load of using another application. Also I hate the resource usage of electron apps.
I think this pretty much sums it up. AOL, MS, etc. didn’t ship Linux clients at all, there weren’t even browser-based clients in most cases. The marginal gain to something like Pidgin was huge because you could go from literally nothing to something that more or less worked. What’s the marginal gain from reverse engineering Slack or Teams? You don’t have to use a browser-based app or a bloated Electron app, but that’s a whole lot less motivating.
Yup. I’d prefer a nice, slick app - but I’ve stopped using Pidgin years ago. I never loved it, but it was good enough for ICQ/XMPP - but at some point I switched to Gajim. Also didn’t libpurple have a ton of bugs?
I think satisfied is the wrong term, but sometimes the “least bad” option is going in a different direction for different people. I also used Slack via IRC bridge for a long time and it was often a pain, to be honest. Not getting updates if people edited messages. No threading…
Yes the UI model is a problem, its something we’re working on… That said, there is already a slack plugin and it works well enough for many. That said I’m curious on where you’re getting your info..
Cool idea.
Suggestion: Order of icons could match the name order: BB, GH, GL. (One of those: possibly nobody cares, yet it irked me immediately.)
Question: Why is BitBucket not turned on by default?
Funny, I came to the comments to ask the same thing about bitbucket being disabled by default..
Isn’t it interesting how we* don’t consider something open source until it gets published on a specific proprietary SaaS application?
* some (many?) of us
This is why I hate that people say github is the home of open source :( I think I’d honestly would rather put my stuff on savannah…
I’ve written a tool to do this using Docker “build containers”. For the non-amd64 linux stuff you’d have to setup a cross compiler, but it is doable. You can find the tool at https://bitbucket.org/rw_grim/convey.
Thanks! This looks like it’s solving a very similar problem as the one I have. So this is a tool to specify the build environment for Pidgin across multiple platforms? And I assume you have some kind of continuous build/testing, like either pre-release or pre/post-commit?
Is there a dashboard for the continuous build? I’d be interested to see what it looks like.
It seems like newer open source projects use cloud services for this, but older ones roll have their own servers… I might want to use my own servers too.
Right now it’s just being triggered by bamboo. You can see it at https://bamboo.pidgin.im but it’s not setup to use all of this yet. I need to finish building some Docker images for some dependencies and stuff.
Aside from that I am working on (albeit slowly) a webapp that’s specially for this so you don’t need to use Jenkins/Bamboo/etc.
Oh what’s the issue with Bamboo? (I’ve never used it.) Is it an issue of not being open source, or not having features you need? What about Jenkins?
The problem with all of them is having to maintain configurations for a ton of platforms outside of the repo which drives their changes.
Nearly 12 years old and there’s still new versions of this stuff coming out. I don’t understand why they don’t just throw this upstream or something.
Luckily I’ve never hit RSI so I basically use whatever keyboard is available the the time. I’ve dabbled in mechanical keyboards but I honestly don’t notice any difference from typing on a rubber dome except for the noise.
I’m currently back in the lovely tiled arms of i3wm.
I really appreciate the tiled window layout approach, but i3 also plays nice with dialog windows, and it has an explicit floating mode for when you really need it. At work and at home I use a Dell Ultrasharp IPS with 2560x1440 resolution.
i3 as well. The thing I like about it, over other tiling window managers I’ve tried, is that layout is manual: you can decide on the fly how you want windows laid out, rearrange them, restack, etc instead of having a single hardcoded layout that everything goes in.
I also use this tool by fellow lobster @cmhamill to get wmii-like dynamic workspace tagging. Just using numbered workspaces, I frequently tend to run out.
(I migrated to i3 over wmii, which is similar but a bit more restricted, mostly for a more elegant internal model and support for a small handful of additional window manager hints. There is something (several somethings, really) to be said for the fact that wmii’s event loop is literally a shell script, but I wasn’t making any use of the capabilities. i3 supports massively more sophisticated layouts than wmii, but the interface makes my brain hurt, so in practice I don’t use them much.)
i3 for me too. I am interested to see how things evolve; I’m running Fedora which is shaping up to make a move to Wayland; others will almost certainly follow. As I understand it i3 doesn’t currently support Wayland, so it’ll be interesting to see if the maintainers make the port, or if Sway will become the replacement.
Either way, I love i3.
It’s going to be interesting to see what happens with tiling window managers and wayland, since from what I understand application sunder Wayland are going to be drawing their own window decorations, which conflicts pretty hard with tiling WMs.
It’s a lot more complicated than that. The Wayland- aware applications (some QT versions and some GTK versions) can be forced to ignore drawing decorations, and a lot of applications run from XWayland which is “all of the Xorg.server inside a .so and some conversion” that follow the old model. THEN you have unstable protocols that extend wayland, like the one used by KWin that says ‘no, decorations should be server-side’. A rant from the WLC developer (that provides most of the compositor implementation for Sway):
https://github.com/Cloudef/orbment/issues/141#issuecomment-227720157
i3 for me as well.
It hits the sweet spot between being customisable, yet having sensible defaults and having the ability to completely fade away into the background so that I don’t have to think about it at all on most days.
At work I’m on OSX, but at home I can’t get away from i3wm. So good. It’s so good I’m considering reinstalling Ubuntu over my MBP just to use i3wm as a daily driver.
i3wm too, running it on Arch Linux on my ThinkPad and desktop computer. I’ve seen some videos on customization but I feel like I’m just scratching the surface. I use a model M on my desktop so I’m thinking of reusing an old foot pedal I found to emulate the Windows meta key.
I really want to like i3, but the default keybindings interfere with emacs keybindings. Haven’t decided yet if I want to use evil mode in emacs or overhaul the i3 keybindings. Has anyone else found a nice solution to this?
It lets you choose your own meta key as a part of setup, is that enough to prevent interference?
I am a heavy Emacs user. In my i3 configuration, I configured windows key as the $mod key, so there are no conflicts between it and my emacs. (I know some people bind windows-key in their emacs. I am not one of those people.)
I gave it another try with super/windows-key as $mod, and so far I’m loving it, it really does “fade away into the background” as Todd says below. Spent some parts of the day tweaking, I really love the simplicity, so far no compatibility issues (Debian stretch with Gnome).
i3 as well for a couple of months now. Before that I had been running XFCE for a very long time, but I’ll probably stick with i3 for one reason, that workspaces don’t flip on all monitors when switching.