In other areas I'm involved with, progress continues, even if it is slower than anyone would like. Gary's work on Guifications 3 has had some progress, and Pidgin has had some progress toward a 2.1.0 release. I wouldn't call this progress significant yet, but hopefully things work out with both projects.
For Pidgin, I'm hoping the infopane Sean is implementing improves significantly before the release of 2.1.0. If it doesn't we're never going to hear the end of it, and a ton of people are going to demand plugins to fix the many deficiencies currently present. The issues are numerous:
- Infopane-as-single-tab introduces dancing UI. This is very bad. If I have one conversation open, the infopane takes the place of the tab that used to always be displayed. When a second tab opens, the notebook magically appears, shrinking the history area and throwing off the history pane's scrolling. Keeping a second tab open at all times to avoid this dancing UI is stupid at best and a pathetic hack at worst.
- There is still no tooltip for the infopane. The whole point of the infopane was to provide blistnode-like functionality in the conversation window. We don't have any of this functionality except a status icon and buddy icon yet. No tooltips, no context menus, nothing.
- It appears the infopane will be fixed at the top of the window. I disagree with this design decision, but a preference for this does seem overkill. I'm hoping a plugin will be able to change the widget order so that I can have a plugin to move the infopane below the history pane like Sadrul had in his screenshots of changes he had made.
- Window size history is constantly being screwed with. It seems to me that I was once able to have my chat and IM windows (since I had them separated via the tab placement options) have their own sizes be remembered correctly. Currently I find myself having to resize every window when one gets created, because the most-recently-resized window seems to win out with remembering size.
- Not strictly related, but the argument about the status icon on the tabs is somewhat flawed. The close button on each tab wastes just as much space on the tab as the status icon yet provides no useful information to the user. I still know several users who dislike the close buttons on the tabs, even after nearly three years living without them (the prefslash days of 0.78 or so killed the ability to turn this stuff off, as I recall). I strongly advocate a boolean preference labeled "Use simple tabs", which defaults to false. When set to true, both status icons and close buttons would not be shown on the tabs.
Speaking of Pidgin, Luke Schierer made a blog post the other day mentioning forking. In it he specifically stated that I was correct in closing a ticket on the Pidgin Trac that was soliciting a fork. I would like to take this opportunity to thank Luke for his support on my actions. Thanks, Luke. I may have been condescending and/or rude to the user who opened the ticket, but I feel justified in my response, especially given that the user actually agreed with me on all but one of the points I made.
When I started this post (roughly 0110 US EDT), I had initially intended to complain about the complaints I see on the Pidgin Trac. However, I've proven that I'm not much better than the users complaining in the tickets. Instead, I'll comment on something that I wish a few more users understood.
Occasionally a user in a ticket will have a complaint that, while valid, the user tries to justify by comparing to so-called competing IM clients. I would like to note that Pidgin is not in competition with any other IM client. There is more than adequate room in the IM client space for the myriad of IM clients that exist. This is simply proof of a point that Luke Schierer made, which is that no single IM client's user interface can satisfy everyone. Yes, Pidgin lacks features other clients have, such as default keybindings for smileys (a triviality to begin with that can be resolved within the realm of reasonability with .gtkrc-2.0), voice and video conversations, or more configuration options than ten copies of the Linux kernel combined. If the user interface doesn't meet your needs or wants, you probably should be using another interface. Ideally we'd love to see many different clients using libpurple as the backend code, enabling libpurple to serve a much wider audience in a better way by providing the facilities for others to reinvent the UI without having to reinvent the entirety of the backend.
On another Pidgin-related note, we've recently had a number of complaints about the lack of documentation on plugin development. Apparently the insanely large body of existing documentation--the doxygen docs and all the existing plugins--is not sufficient to satisfy some would-be plugin developers. In an attempt to address this, I've started to write a basic how-to series on the Pidgin Trac's wiki. I started by taking Gary Kramlich's existing start to a C Plugin HowTo and migrating it to the wiki, and I am now adding additional "chapters" to it. I'm not necessarily following any fixed format, but I'm trying not to half-ass this thing. My hope is that when I'm finished, I'll have a solid set of documents and accompanying plugins that will silence this set of complaints.
I think I'm done ranting for now. I might have more later.
