Today, on realizing that the news was about to become public knowledge anyway, I made the decision to rush our announcement of the name change from Gaim to Pidgin a day and a few hours early. I am incredibly excited to finally be able to make this announcement!!

I see the following questions from a debian developer:^[1]

• How can I make Gaim stop auto-hiding its conversation windows?

You have loaded a plugin to make it do this. The only one that I recall us distributing iconifies the windows when you are away, but others have been written to hide them at other times.

• How can I make Gaim stop auto-toping its dialogs and windows?

Each of the 2.0.0 beta releases of gaim has reduced the number of dialogs and windows that are created without direct user intervention. That being said, gaim still does not make any effort to place new windows at any given level. Users complaining of this problem are almost always Windows or Metacity users. Users of other window managers have a much lower incidence of annoyance by gaim’s window placement, even once you consider the difference in user base. This should tell you something.

• How can I make Gaim stop stealing the focus all the time?

When is it “stealing” your focus? While some versions of gaim have had bugs that cause it to do so, most of not all of these have been resolved. The one exception is related to the previous question. Some window managers give focus by default to newly created windows all the time. We feel that gaim should leave decisions about when gaim gets focus to the window manager. If you dislike your window manager’s decisions in this matter, it is not our fault.

Gaim is one of the very few programs that is graphical and yet responds to network events. One of the few other commonly used examples of such programs are email programs. Because some events are initiated by others, such as new conversations or new mail notifications, gaim is faced with a situation that some window manager developers never consider: how to handle this in the UI. Our decision has been to (slowly) reduce the incidence of dialogs being created without your direct intervention. For that reason the new mail notification and many of the error dialogs have been moved to the buddy list and to the conversation backlogs. For the same reason we introduced extended queueing options, allowing you to queue new conversations to the buddy list, so that they do not “pop up.” I suspect that many if not all of your issues with gaim either have already been solved if you upgrade to 2.0.0 beta6, or would go away if you did not use metacity (gnome’s default window manager), or both.

Today, as I was updating the software on my iBook, I noticed that metacity was installed. I do not use metacity at all, much less on my iBook running MacOS X, so my natural reaction was to remove it. I was rather surprised to find that doing so was not all that straightforward. This is one of the things that I find inadequate in darwinports, that when I am trying to remove software that things depend on, I have to remove each manually and in order. It cannot sort through the list of packages on the command line and sort them appropriately for me. But I am going down a tangent here.

Returning to the topic at hand, I found that I had to remove the gnome python desktop stuff. Since nothing appeared to depend on it, I assumed that it must be something I installed by mistake, and removed it.

Then I go to see if gramps is installable yet. A significant number of ports have been upgraded since I last tried, so this is a reasonable experiment. What is the first package it pulls as darwinports tries to install it? Metacity.

Again, I do not use metacity at all. Gramps runs just fine on my linux desktop. Metacity is clearly not a dependency of gramps. Why is it being pulled then?

The problem with many GNOME programs (of which gramps is one), is that the authors consider the case of using the software with something other than the default GNOME environment as an afterthought at best. Thus to require a window manager for a graphical program makes some sense. But I do not use that window manager, and any of a number of other ones work perfectly well with gramps. So why in the world must I have metacity? Only because the authors of GNOME are infested with a lets-take-over-the-world attitude.

Those of us developing gaim are not like that. We know full well that gaim is not and never will be the best client for everyone. That is why we are working on the core/ui split, so that others can write their own interface, one that better fits their needs, without duplicating all of the work that goes into making that interface run. Open source is, or at least should be, about choices. We ought not to forget that.

I have been filing bug reports against this for months now. Well, really only two bug reports so far, but that is because so little has changed in that time. If you think Gaim development is slow, you should see how closely the macports guys mimic the properties of cold molasses. This is very frustrating, and an ideal example of why linux continues to be my operating system of choice for my desktop. Now if only ssh forwarding across the vpn was a little faster…

Mr. Stefano Zacchiroli’s thoughts^[1] on Mutt and gaim’s evolution integration have motivated me to write a little on each.

I like mutt. I really do. Ever since Mr. Ethan Blanton introduced me to it, it has served me well. Recently though I started using Mail.app, the OSX mail client, for my personal mail. I made this change in part to be able to decrease my reliance on gmail and similar for the odd html formatted mail that I want to read, in part for the ease of setup, and in part because the thought of setting up a mail server to send mail from on my laptop is daunting. I do not trust darwinports to get things right and work consistently all that much, nor do I wish to compile and maintain postfix myself. This is after all why I use debian on my other machines: to be able to ignore the software that I do not want to actively track and know the details of myself.

But I find myself on OSX for my laptop. I want to use Quicken, and I want to be able to run the Rosetta language software, even though I do not in fact do so nearly enough to actually make noticeable progress. It also does not hurt that Civilization, about the only computer game I’ve remained significantly attracted to since graduating, runs on OSX. So I find myself leaving mutt some.

Having done so, I can see some other gains. I have address book integration, which is nice. So I can, in a theoretical sense, see that if integration between a real address book and an email address book is nice, it might be nice to add in the IM contact list into the mix. After all, most of the people on the buddy list for my personal accounts are also in my address book.

Which brings me to gevolution. I have disliked evolution every time I have touched it. It is big, consuming more memory than I like. It is fragile, crashing more than I am willing to put up with in a mail client. Mail.app’s handling of threading is poor, evolution’s handing is (or at least was) worse. Additionally, it pushes me more towards GNOME, and I really do not like the GNOME Desktop Environment.

I appear to not be particularly alone in this dislike of evolution. As a result, the gevolution plugin, originally written by Mr. Christian (ChipX86) Hammond, is rather neglected. Mr. Hammond left the project with gevolution in a rather unfinished state, which should not be taken as a detraction from him: most of gaim was then and is still in an unfinished state. That does not hide the reality though that gevolution, like the rest of gaim, needs a significant amount of Tender Loving Care, but unlike the rest of gaim, is not significantly likely to get any.

It is very nearly abandoned code. As such, it is becoming increasingly fragile, and its flaws are going largely unfixed. When I see this sort of code, my reaction is that we should drop it. Yes, some users like it, but it is causing problems that we do not intend to invest time fixing. If someone really likes it, they can of course check out an old version of gaim, rip that code out, and make it compile as a 3rd party plugin.

This temptation grows with every bug report I see that ends up being traced to the gevolution plugin. Bugs about not being able to add or remove buddies, or about slowness, or inexplicable crashes. What is the solution here? I am not sure.

As I get used to trac, I am slowly coming to like it. It is not so horrid as SF is. Hopefully we can work out the remaining issues!

We finally have a server to host the project!! Donated and hosted by dvlabs.com, this is a huge step forward for us as a project. I am slowly configuring it, getting apache2, subversion, planet, mysql, and such up and running. It is a slow process, but fortunately we are not pressed for time yet.

Today in the gaim forum^[1], a user proposed forking gaim because of the slowness and selfishness with which we proceed.^[2] If it happens it will not be the first such fork, but rather the third or forth such. The only unique thing about it will be that will be libgaim based.

I have always a little bit contemptuous of true forks, because they have consistently been started by users who clearly have no clue how much work we put into gaim. Precisely because they were unprepared for that level of effort, these forks have quickly failed.

A libgaim based “fork” would be a different matter entirely. It would not, in fact, be a true fork at all, and to call it one is to utterly mistake why we worked so hard to split gaim into a UI and a library, into “gaim” and “libgaim.”

We want there to exist other interfaces. You want an interface that integrates with GNOME to a significant degree? GREAT! Grab libgaim, and even grab our existing Gtk UI if you like any aspect of it, and write one. You want an interface built to fit in with KDE? Awesome, grab libgaim, break out your QT API reference, and get busy. OSX? I personally think Adiumx does a reasonable job, for all I have a few differences of opinion with them, but hey, if you do not want to help them with their libgaim based efforts, write a second (or third, considering Proteus) one. Dissatisfied with wingaim? I sincerely hope that someone will write a better UI for windows users than we provide.

The point here is that we have what is (in my opinion) one of the best back-end code bases available, with better (though far from perfect) protocol support than most other projects have been able to generate. Why should that effort be duplicated? It represents 2/3rds of the necessary code to run a successful IM client project. That is a ton of effort essentially being wasted when we duplicate it over and over again. Effort that we believe could be better used to make more things work for more users.

But while it is clear that supporting the varied protocols requires a huge chunk of very similar code, it is far from clear that it is possible for any one interface to fully please all users. I go so far as to argue, consistently, that it is in fact impossible for any given interface to be the best for everyone.

The only reasonable way to approach this then is to enable people to write interfaces that meet their needs while avoiding the duplication of effort that starting from scratch entails. This requires libgaim, or at least some equivalent. We here in gaim could never support the N interfaces that we foresee, or at least hope to see, eventually existing. But now we will not need to. The source is there for your use, grab it, and lets see what you can do with it, what sort of interface you design. I wish you the best of luck!

The so-called “desktop metaphor” of today’s workstation is instead an “airplane-seat” metaphor. Anyone who has shuffled a lap full of papers while seated between two portly passengers will recognize the difference–one can see only a very few things at once. The true desktop provides overview of, and random access to, a score of pages. Moreover, when fits of creativity run strong, more than one programmer or writer has been known to abandon the desktop for the more spacious floor.^[1]

This is so very true that it nearly boggles the mind. This is behind the push for larger screens. This is behind the proliferation of icons in the system tray. This is behind the desire for multi-headed displays (both those used as a contiguous desktop and those used disjointly). This is even behind my own use of virtual desktops. We simply cannot see enough on the desktop.

Not only can we not see enough, we cannot find things easily enough. That is why I, and those like me, sort windows onto virtual desktops. Those who use multi-headed displays disjointly fit into this category. We cannot find things on one desktop, so instead we split the work into n desktops, in hopes that on any given desktop we can see everything related to a task or subset of tasks. This is why people hate having overlaping windows, and thus want bigger screens, if the windows do not overlap, they do not have to “shuffle pages.”

The desire to not “shuffle pages” is in turn why the system tray gets used. We cannot fit everything we want to run on the desktop without overlap, so we “minimize” some of it. The area to minimize things into is limited, so we further collapse some of them into the system tray space. Never mind that this is an abuse of the system tray, it saves space, and space is at a premium.

It is amazing how much of modern UI design, of the requests I see developing Gaim, are explained by this one relatively simple analogy. We do not have desktops, we have airplane seats. And that means that space is always going to be at a premium.

I have not done much with Gaim this week, I have been rather busy with other projects. I did note that in the forum, there are predictions that Gaim as a project will fail because of the selfishness of its current developers. Apparently it will fail to the point that it will be necessary for some other developers (who are supposedly less selfish) to “pick it up.”

Sean Egan makes an interesting point here:

I still got a kick out of the way as soon we released a Windows port, we went from extraordinarily successful, 5-year-old, pinnacle of software development to be admired by all, to fledgling new project that had better do everything everyone wants if it ever wants to consider succeeding

Though I suspect that a fair few of these complaints and predictions are coming from GNOME users as well.