Ok, I know the title of this post is a bit lame, but you'll have that. Deal. :-P
The title is supposed to be an obvious reference to the maintainer of the Pidgin-SNPP protocol plugin for the Simple Network Paging Protocol has accepted a long-standing invitation to bring his plugin to the Purple Plugin Pack.
rizzo, the maintainer of pidgin-snpp, had mentioned that he needed to set up a Windows Pidgin build environment and work on his plugin. I reextended the offer to join the Plugin Pack by saying that the plugin would already have been released, and rizzo accepted. We're working on making the plugin compatible with Pidgin 2.x.y now.
Hopefully we'll release again around the time Pidgin does, new plugin and all. :)
Thursday, July 19, 2007
Tuesday, July 17, 2007
Projects, Progress, and Competition
In my last post, I mentioned that I was wanting to push a release of the Purple Plugin Pack. Hard to believe it's been over two weeks ago already. Friday night, just before midnight, I finally released Purple Plugin Pack version 2.0.0. We changed our versioning scheme in the process too. The biggest, and most important, thing to mention here is that our major version will always match libpurple's. The other numbers have their significance as well, but they're not all that important--users should always be using our most current release. This release was significant in a number of ways--we introduced a few new plugins, added new features to several plugins, and also fixed a number of bugs.
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:
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.
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.
Subscribe to:
Posts (Atom)