Well, Google finally announced the list of accepted students for this year's Summer of Code. You can read about our accepted proposals here. Of course, we're all very excited about the projects we've chosen for this year. We have two students returning to us this year, both with projects that will be hugely important moving forward. Those students are Eric Polino and Sulabh Mahajan.
Eric has chosen to work on GObjectification, which will move libpurple from using our own object system to taking advantage of the GObject capabilities of GLib, one of our existing dependencies. As a result of this project, a massive amount of libpurple infrastructure will change, allowing us to leverage a tried and true typing system and giving plugins an incredible amount of increased flexibility by allowing them to subclass objects and providing interfaces they can implement. This will, of course, have huge rammifications for everyone using libpurple--us, plugin authors, Adium's authors, and even the Instantbird authors. We're confident the result will be worth the effort, though.
Sulabh has volunteered to take on the Privacy Rewrite. What makes this such a daunting task is that the protocols we support provide a very wide range of privacy options, some of which are unique. For example, ICQ supports an "invisible" list and a "visible" list in addition to a "block" list and probably a number of other things that I'm forgetting. Sulabh will have to look at what all our protocols support and provide a foundation in libpurple for all the protocol plugins to provide the privacy options their protocol allows for. Additionally, he'll have to smooth over the differences between protocols to make things consistent.
In addition to these projects, we've accepted two proposals for native Windows user interfaces. Each project will take a different approach to achieve the same goal--providing a user interface that fits better into a Windows desktop than Pidgin currently does. I've already seen a few complaints that we accepted two projects for this. Quite frankly, I don't understand the complaints. We chose two projects for two reasons--first, we want to have the highest possible chance to better serve our Windows users, and second, it's entirely possible that a single Windows UI project won't be able to do enough to satisfy all our users. Having two Windows UIs will allow each to focus on whichever set of users it is more appropriate for.
We've also accepted projects that will make XMPP transports based on libpurple, allow libpurple to use telepathy protocol support in addition to or instead of our own, and using webkit for our message displays. Each of these projects is going to be challenging in its own right. Of all the projects, the XMPP transports will certainly be the least user-visible, as the transports will run on an XMPP server. Conversely, the most visible will probably be the webkit message view, as this will completely replace what we currently use to display messages. By using webkit, it's possible that we'll eventually be able to support Adium Message Styles (no, I'm not promising this support will happen, but it will be possible). The Telepathy plugin will provide some interesting functionality by allowing us to use nothing but telepathy for protocol support if the user so chooses.
There are other deeper details in these projects, but I've already wasted too much time obsessing over this post and discussing the larger projects in detail. I'll leave further discussion of the technical merits and details of projects to the students and mentors. Needless to say, this post could have gone on just about forever. ;)
Overall, this Summer of Code looks like it will be one of our best. Good luck to all our students!
Monday, April 20, 2009
Thursday, March 26, 2009
It's that time again...
Well, once again we've come to the student application phase of Google's Summer of Code program. We're several days into the process, and we've seen a marked decrease in our intake of student applications compared to prior years. Why is anybody's guess, but I'm personally hoping it means that potential applicants are spending more time polishing their applications before submitting.
Based on the applications we've seen so far, I'd like to publicize a few notes for applicants:
Based on the applications we've seen so far, I'd like to publicize a few notes for applicants:
- Provide a detailed timeline for your project. "I expect to complete work in 10 weeks" doesn't cut it here. Tell us what milestones you expect to achieve and how far along. You could instead estimate how long a specific goal will take to implement. Yes, your estimate could ultimately prove wrong, but that's not necessarily the end of the world. We really want to see that you have a concept of time management and prioritization.
- Don't plagiarize. If we know you're plagiarizing, we'll invalidate your application. If you can't deliver an application without plagiarizing, you shouldn't be applying. We don't mind if you use some of the text on our ideas page to help with the abstract, but keep in mind that a serious application won't rely on simply copying and reformatting what we've already said.
- Don't be afraid to come up with a unique idea! The ideas page are not the only ideas we'll entertain. We love to see well thought-out, original ideas, especially ones that make us wonder why no one proposed it before.
- Make sure your proposal is for a specific project idea. A general "I want to work with Pidgin for the summer" is a sure ticket to the reject bin.
- You don't have to write an encyclopedia for the application, but you do have to give us something to work with. There's an old adage that "less is more." Sometimes that's true. Sometimes the opposite is true. The point here is that you should be verbose enough to explain your idea, but don't ramble. I know this can be difficult to judge. Just re-read the application, make sure it makes sense, and make sure it doesn't drag on needlessly.
- You have to apply using the SoC webapp, not our mailing lists. We have to have applications submitted via the SoC webapp in order to review them and have them in the running for our student slots. This is a Google thing, and it makes everyone's lives a lot easier.
- The application isn't final until submissions close. We will provide feedback on your application if it needs work. You can modify your application to address our feedback until applications close. Use this to your advantage!
- We don't yet know who will mentor any given project. We don't assign final mentors and backup mentors to projects until we have decided which projects we want to accept. Asking us about this is just wasting your time.
- We expect you to treat the project as a full-time job. That means at least 35 hours per week. We want to make sure everyone gets the most out of Google's money, and this is one way to do that. Since you'll technically be a contract worker, we expect the contracted work (your project) to take priority.
- We expect you to remain actively involved with us after the Summer of Code finishes. Quite frankly, if you're going to collect the checks and run, you're missing the entire point. The Summer of Code is intended to attract new contributors and get them involved in open source software, turning them into long-term contributors. Participating in the Summer of Code and then disappearing isn't serving that intention, and leaving us with code we have to maintain ourselves is quite rude. If that's your intention, please don't apply. Let the potential for acceptance go to someone who will stay with us.
Thursday, February 26, 2009
Saved Statuses for Fun and Profit
From my limited experience with Pidgin users among my family and coworkers, I've discovered that a number of users don't know about Pidgin's saved status features and instead use only the transient statuses created directly in the status selector by typing a message. Some users don't even realize that they can select a previously used transient status from the middle section of the status selector's menu. As an attempt to spread deeper insight into Pidgin, I submit for your reading this saved status tutorial.
Overview of Saved Statuses
In Pidgin, a saved status gives you a considerable amount of flexibility. For example, if you use six accounts, three of which are personal and three of which are for work, you can use a saved status to have your work accounts away while your personal accounts are available and vice-versa. Or, if the text box you get from using the status selector irritates you, you can use saved statuses to get rid of it forever.
Creating a Simple Saved Status
Let's start with two basic saved statuses--one Available status and one Away status.
Click the status selector at the bottom of the buddy list window. You should see something like this:
Select the "New status..." entry. You should see something similar to this:
The fields here should be pretty obvious and self-explanatory. The title will be what you see in the status selector menu. Generally, I use a descriptive title, such as "Away - Sleeping" or "Available - no message," that will quickly identify the message's contents to me without needing to read the message. For this example, I'll use "Away - example."
For Status, obviously you want to choose one of the basic statuses listed--Available, Away, Invisible, Extended Away, Offline, Do Not Disturb, or Invisible. If you use only one account, your choices could be significantly different. For this example, we'll accept the default of Away.
in the Message box, type your status message. For my example Away status, I'll use the message "Away for the sake of being away."
Click Save. Alternatively, if you want to use this status now, click "Save & Use." You could also click "Use," but then the status would not be saved.
Now, repeat the process for an Available status. In this example, I'll have a title of "Available - no message", a status of Available, and a blank message.
Now, if you select "Saved statuses..." from the buddy list window, you should see something like this, but probably with a lot fewer statuses listed:
Creating a Complex Saved Status
A complex saved status is where the real power of saved statuses becomes obvious. Let's modify the existing away example we created. Select it in the saved status list and click "Modify..." Now click the expander just to the side of "Use a different status for some accounts" and observe the list of accounts that appears.
Put a checkbox in one of your accounts. For this example, I'll use my pidgin.im XMPP account. Now you see a much simpler new dialog:
For simplicity's sake in this example, I will choose "Extended away" as the status and use "test" as my message. After clicking OK, I return to the modify status dialog, to see something similar to this:
Now you can click "Save" or "Save & Use." This gives you essentially the simplest form of complex status--one in which only one account differs in status from the other accounts. Using this status will cause all but that one account to appear as away, and cause that one specific account to appear as extended away (note the clock vs. the circular sticky note).
Using a Saved Status
To use a saved status, you can select it in the status selector's menu if it's listed. If it's not listed, simply click "Saved statuses..." in the status selector to bring up the Saved Statuses dialog, then select the status you want and click "Use." The status should now be remembered in the "popular statuses" (middle) area of the status selector menu. Of course, with disuse or use of a large number of statuses, a given saved status can fall out of the saved statuses list, in which case you'll need to repeat the process of finding it again. If you use the statuses a lot, though, this won't be a problem.
Practical Applications
Saved statuses aren't for everyone, of course. They do provide a number of possible complex status combinations limited only by the number of accounts you have in Pidgin. They also let you get rid of the ugly text box for status messages for as long as you use saved statuses. They also offer a relatively quick setup time that allows you to create your status once and use it as many times as you want without ever having to think about how to configure the status again.
Enjoy playing with your newfound saved statuses!
Overview of Saved Statuses
In Pidgin, a saved status gives you a considerable amount of flexibility. For example, if you use six accounts, three of which are personal and three of which are for work, you can use a saved status to have your work accounts away while your personal accounts are available and vice-versa. Or, if the text box you get from using the status selector irritates you, you can use saved statuses to get rid of it forever.
Creating a Simple Saved Status
Let's start with two basic saved statuses--one Available status and one Away status.
Click the status selector at the bottom of the buddy list window. You should see something like this:
Select the "New status..." entry. You should see something similar to this:
The fields here should be pretty obvious and self-explanatory. The title will be what you see in the status selector menu. Generally, I use a descriptive title, such as "Away - Sleeping" or "Available - no message," that will quickly identify the message's contents to me without needing to read the message. For this example, I'll use "Away - example."
For Status, obviously you want to choose one of the basic statuses listed--Available, Away, Invisible, Extended Away, Offline, Do Not Disturb, or Invisible. If you use only one account, your choices could be significantly different. For this example, we'll accept the default of Away.
in the Message box, type your status message. For my example Away status, I'll use the message "Away for the sake of being away."
Click Save. Alternatively, if you want to use this status now, click "Save & Use." You could also click "Use," but then the status would not be saved.
Now, repeat the process for an Available status. In this example, I'll have a title of "Available - no message", a status of Available, and a blank message.
Now, if you select "Saved statuses..." from the buddy list window, you should see something like this, but probably with a lot fewer statuses listed:
Creating a Complex Saved Status
A complex saved status is where the real power of saved statuses becomes obvious. Let's modify the existing away example we created. Select it in the saved status list and click "Modify..." Now click the expander just to the side of "Use a different status for some accounts" and observe the list of accounts that appears.
Put a checkbox in one of your accounts. For this example, I'll use my pidgin.im XMPP account. Now you see a much simpler new dialog:
For simplicity's sake in this example, I will choose "Extended away" as the status and use "test" as my message. After clicking OK, I return to the modify status dialog, to see something similar to this:
Now you can click "Save" or "Save & Use." This gives you essentially the simplest form of complex status--one in which only one account differs in status from the other accounts. Using this status will cause all but that one account to appear as away, and cause that one specific account to appear as extended away (note the clock vs. the circular sticky note).
Using a Saved Status
To use a saved status, you can select it in the status selector's menu if it's listed. If it's not listed, simply click "Saved statuses..." in the status selector to bring up the Saved Statuses dialog, then select the status you want and click "Use." The status should now be remembered in the "popular statuses" (middle) area of the status selector menu. Of course, with disuse or use of a large number of statuses, a given saved status can fall out of the saved statuses list, in which case you'll need to repeat the process of finding it again. If you use the statuses a lot, though, this won't be a problem.
Practical Applications
Saved statuses aren't for everyone, of course. They do provide a number of possible complex status combinations limited only by the number of accounts you have in Pidgin. They also let you get rid of the ugly text box for status messages for as long as you use saved statuses. They also offer a relatively quick setup time that allows you to create your status once and use it as many times as you want without ever having to think about how to configure the status again.
Enjoy playing with your newfound saved statuses!
You Can't Please Anyone
Occasionally we make changes to Pidgin which displease some subset of our users. For an example, I'll give a brief history lesson.
We released a series of six betas leading up to our name change to Pidgin. In our first beta, 2.0.0beta1, we introduced the concept of the status selector. At this time it was a rather crude creation; it simply mashed a few widgets together to accomplish the basic tasak. When we introduced this status UI, we also introduced the concept of two ways to handle status messages. The first, and most obvious, way to handle status messages was to present a text box when selecting a basic status from the status selector in which to enter the status message. The other method was a bit more complex but significantly more powerful--this was the saved statuses feature accessible from the "Saved statuses..." entry in the status selector's menu.
When we first inroduced this UI, the behavior of the text box was to retain the status message whenever the status changed from, for example, available to away or from away to available. A number of people, myself included, were not happy with this. Eventually we changed the behavior to clear the message on status change. This displeased another group of users. Now here we are, two years later. We changed back to retaining the status message on status changes pursuant to a discussion on the development mailing list. Again, we've displeased a group of users.
The problem with this particular change is that both behaviors are valid, and fans of each behavior think their preferred behavior is the only correct behavior. Of course, now that we acknowledge that both behaviors are valid, many users' first reaction would be to say "Make it a preference!" Of course, that's a whole new argument in itself, but this is such a minor feature that it's not important enough to warrant a preference.
Note that the people who don't like the retention of the status message are inconvenienced by a single keystroke if the intended result is to clear the message, and not inconvenienced at all if the intention is to use a new message. This inconvenience, or lack thereof, is because we chose to implement the retention such that the retained message is highlighted. This means that simply hitting backspace will clear the message and typing an entirely new message will replace the message text with what you've typed.
Simply put, this change is just further proof that when you're involved in a project of any significance, you're damned if you do and damned if you don't, no matter what you do or don't.
I'm sure this post will inspire some criticism. For the time being, though, I think it's best if we ride this wave of criticism out for a bit and see if this is simply resistance to change or a genuine "problem."
We released a series of six betas leading up to our name change to Pidgin. In our first beta, 2.0.0beta1, we introduced the concept of the status selector. At this time it was a rather crude creation; it simply mashed a few widgets together to accomplish the basic tasak. When we introduced this status UI, we also introduced the concept of two ways to handle status messages. The first, and most obvious, way to handle status messages was to present a text box when selecting a basic status from the status selector in which to enter the status message. The other method was a bit more complex but significantly more powerful--this was the saved statuses feature accessible from the "Saved statuses..." entry in the status selector's menu.
When we first inroduced this UI, the behavior of the text box was to retain the status message whenever the status changed from, for example, available to away or from away to available. A number of people, myself included, were not happy with this. Eventually we changed the behavior to clear the message on status change. This displeased another group of users. Now here we are, two years later. We changed back to retaining the status message on status changes pursuant to a discussion on the development mailing list. Again, we've displeased a group of users.
The problem with this particular change is that both behaviors are valid, and fans of each behavior think their preferred behavior is the only correct behavior. Of course, now that we acknowledge that both behaviors are valid, many users' first reaction would be to say "Make it a preference!" Of course, that's a whole new argument in itself, but this is such a minor feature that it's not important enough to warrant a preference.
Note that the people who don't like the retention of the status message are inconvenienced by a single keystroke if the intended result is to clear the message, and not inconvenienced at all if the intention is to use a new message. This inconvenience, or lack thereof, is because we chose to implement the retention such that the retained message is highlighted. This means that simply hitting backspace will clear the message and typing an entirely new message will replace the message text with what you've typed.
Simply put, this change is just further proof that when you're involved in a project of any significance, you're damned if you do and damned if you don't, no matter what you do or don't.
I'm sure this post will inspire some criticism. For the time being, though, I think it's best if we ride this wave of criticism out for a bit and see if this is simply resistance to change or a genuine "problem."
Monday, January 12, 2009
MSN Issues
Since last evening, we've had an influx of users into #pidgin, trac, and the support mailing list because they're not able to connect to MSN. Initially, we thought this was a server-side issue, because the error message we receive from the server makes it look that way. However, we've come to find that it is actually a minor protocol change in which the server now expects us to send a piece of data we don't send. We are working on a solution. There is no need to send further mail to the support list, open new tickets, or pour into #pidgin.
Again, we know what the problem is and are working to fix it.
Again, we know what the problem is and are working to fix it.
Friday, January 9, 2009
And the survey says...
Well, we got quite a lot of user feedback in the survey that Casey ran on our site. I've read through a lot of it and thought I'd share some replies to specific comments. Keep in mind that we received many thousands of comments, so your exact comment may not be addressed here. With so many comments, it's very time-consuming to go through them all, so I just picked a few that stood out to me. At any rate, here we go:
Complaints
"Could be clearer how to set up pidgin with ssh." - This request isn't quite clear, but I'm going to assume that the person wants to know how to use Pidgin either with an ssh tunnel or with ssh acting as a proxy. In the former case, ssh tunnels are documented quite extensively; you would configure your tunnel, then configure the Pidgin account to connect to localhost on the port you're forwarding. Using ssh as a SOCKS5 proxy is also well documented; you would set up the ssh proxy according to the documentation and then configure Pidgin's proxy settings to use the proxy on localhost. We haven't documented this ourselves because a lot of good generic documentation already exists, and it's not exactly a common use case that we see.
"I would like to see auto-reconnect be more resilient. I tend to have to manually reconnect after actual network outages. Also, it'd be nice if the encryption plugin knew when to get out of the way." - This is actually two comments, but I'll address them both. The auto-reconnect feature uses an exponential backoff that starts at just a few seconds between attempts and backs off to a maximum retry time of 34 minutes. If your Pidgin is compiled with NetworkManager support, NetworkManager may cause some delays due to not realizing the network is back. On Windows, there are some interactions with the Network Location Awareness features in Windows XP and Windows Vista that can cause delays in the reconnection as well. As for encryption, we didn't write the encryption plugins; that's a complaint/suggestion best taken up with whoever wrote the plugin you're using.
"Fix the chat input box please, or I'll switch to Carrier/Fun Pidgin." - Isn't Carrier dead? Anyway, if you feel the need to switch clients, that's your prerrogative. We've debated this at length on numerous occasions and we've decided to stick with the autoresizing input area, at least for now.
"Have the buddy list show up when i open pidgin, and have a popup when a person says something in a conversation." - There are two plugins already that provide popup notifications. One is called Guifications, the other is pidgin-libnotify. Windows users need to use Guifications. Users of other operating systems can use either. As far as the buddy list visibility goes, if you want to see the buddy list when you open Pidgin, either set "Show system tray icon" to "Never" in preferences, or have the buddy list open when you close Pidgin. The ability to start with the buddy list hidden was a feature request we chose to implement, and it would cause too many complaints for us to remove it.
"Better memory usage on windows or an up to date GTK included." - We do actively try to reduce Pidgin's memory usage where we can see room for improvement; patches are welcome for conditions we don't see. Our Windows person bundles new GTK+ runtimes as it's confirmed that new WinGTK+ releases don't introduce problems for us.
"crashes, crashes, crashes" - We do our best to fix the crashes that get reported. Perhaps you should read "Tips for Bug Reports" and then open a ticket.
"Docking pidgin in windows vista rearranges my icons on the desktop, but this is a problem with all programs that dock so not really important." - You've correctly realized on your own that Pidgin is not at fault here. This is a bug in Windows' desktop management, which we can't do anything about. I remember seeing this bug as far back as Windows 98, so it's not exactly new either. Maybe Microsoft could be convinced to fix this 11-year-old undesirable behavior?
"None. Keep it simple. I love that." - Thanks! We love simple. Clean, too!
"File transfer speed in MSN protocol" - We know a lot of our users are dissatisfied with the state of MSN file transfer support in libpurple. We're sorry you're not happy with it, but it's just not a priority for us. If someone comes along and implements a good (or even semi-reasonable) patch to do this, we'd be happy to work with that person to include better transfer support.
"Startup time. It takes about 10 seconds for me to get Pidgin 'usable'." - 10 seconds is not an unreasonable amount of time. Remember that Pidgin has to connect to all your accounts (MSN can be particularly slow here!), load your buddy list from the server, apply your saved preferences, load your saved plugins (including the protocol plugins), etc. There's a lot of work that goes on in those 10 seconds that is difficult, if not impossible, to streamline any further. You may, however, be able to shave some startup time off by removing any plugins you don't use (you can see paths and filenames by going to the Plugins window, clicking on a plugin's name, and clicking the expander by "Plugin Details").
"Some XMPP contacts are added twice." - We've had this bug forever, and it irritates us too. There has been some recent work on this. It should be better in 2.5.3 and 2.5.4 than in previous releases.
"1) One thing that confuses me...when a pidgin window aside from the chat window has focus (Buddy List, Manage Accounts, etc), and you type, it opens up a little window with that text in it...I probably just need to RTFM and it's working as intended, but who knows... 2) When setting status to Away, you are allowed to enter a message. Prior to version 2.5.2, when setting status back to Available, this message would be cleared automatically. From version 2.5.2 and after, it is now highlighted for manual deletion, which I find annoying. 3) Animated smileys would be awesome (but I assume that is more so on Hylke). I do love the current smileys though!" - Three points, so three answers: 1. This is a feature provided by GTK+ sometimes called "typeahead search." If you type text that matches a buddy's name or alias, that buddy will automatically be highlighted. 2. We discussed this a couple of times. Both use cases are valid, but it's our opinion that it's less annoying for people who want new messages to have to type a single backspace than it is for users who want to keep the same status message across multiple statuses to have to retype their whole message. Sorry. 3. Yes, animated emoticons would be something Hylke would need to create for us if he felt so inclined, but I think we'd all be better served if animated emoticons were a separate theme from the default.
"GTK" - I'm going to go out on a limb and say the person who wrote this complaint is a Windows user. We use GTK+ because Windows was not our first platform, and GTK+ was the best toolkit for the purpose when Pidgin was started in 1998. We would love to see someone write a native Windows interface for libpurple, as we know it would serve most Windows users better than our GTK+ interface ever could.
"It is not very easy to install Pidgin on Linux distributions, especially because of dependencies." - This is true of source-based installation of Pidgin for those who don't compile many applications themselves or those new to the world of compiling applications. Pidgin is provided in a pre-packaged, dependency-tracked format by all the major Linux distributions, as well as through the BSD ports system, Fink on Mac OS X, and Macports on Mac OS X. All of these distributors provide an extremely simple way to install Pidgin.
"Using special characters in statuses crashes Pidgin. With MusicTracker, this can happen a lot... and crash my client. Pidgin ought to replace these characters with question marks or something. Also, file transfer is very slow and erratic, especially with non-Pidgin users." - I've covered the file transfer above, to an extent. Special characters themselves don't crash Pidgin. MusicTracker could probably prevent some crashes by making sure that all strings it passes into libpurple are UTF-8. We have recently made some changes that should help in this regard, but plugins should still make sure they hand us only valid UTF-8 strings.
"Pidgin steals keyboard focus when it raises a conversation window, which is very bad. I want windows to raise when I receive new messages, but without stealing keyboard focus, especially from another conversation window I'm actively typing in...." - I have trimmed a longer user submission here to a specific issue to reply to for clarity and brevity. Pidgin doesn't ask for focus. Some window managers, however, treat a raise request as a focus request. These window managers should be fixed. Trying other window managers and seeing their behavior would confirm this.
"I'd like to see some new looks available by themes (sounds included would be nice) so long as they don't change the position and location of various options. I know skins and themes are mentioned already in the survey but I've wanted them for a while and it's the only thing I can think of that I really want to see." - Some theming support, including sound themes, was worked on during the Google Summer of Code for 2008. We expect to release this work in Pidgin 2.6.0, but no promises.
"Wrong encoding for incoming messages from 'QIP' users (icq protocol) writing with diacritic marks in czech/slovak (encoding central european, both iso 8859-2 and win 1250)." - I really wish everyone would just use UTF-8 already. All these problems would magically go away.
"x-status support for ICQ protocol" - This is something else we expect to release in Pidgin 2.6.0.
"doesn't always connect to a network" - More details are necessary to help in this case.
"A two pane plugin-preferences dialog would be nice. You select the plugin on the left pane and the preference are displayed in the right pane." - It seems that no matter what we do for plugin configuration, no one's ever happy with it. If someone can come up with a plugin configuration dialog that everyone can live with, I'd gladly fight (if needed) to get it in a release.
"Please fix the auto-away option - it's been broken since at least version 2.1 or 2.2. For example, when status is set to 'Invisible', it changes to 'Away' after been idle for a while (this shouldn't happen when offline) - and then, when initiating a conversation with someone, it changes back to the original offline status ('Invisible' in this case)! Peer-to-peer MSN file transfers would also be nice, as that function is almost unusable in its current state." - Again, I have already covered MSN file transfers, but I'm responding to this for the auto-away complaint. I'll admit that the behavior you describe is undesirable, but it is working as designed. It might make sense to exempt an original status of "Invisible" from auto-away, but this is a slippery slope in some respects--we make this change for Invisible, and people will want all sorts of unique exceptions.
"Too many dependencies, make it lighter!" - Yes, we have a lot of dependencies, but very few of them are requirements. If you're building Pidgin yourself, you can disable all but the absolute minimum required dependencies by making use of the "--disable-????" family of arguments to the configure script ("./configure --help" will show you the options). We are very cautious about adding new dependencies unnecessarily.
"MSN protocol seems buggy, IRC isn't very customizable" - The MSN protocol plugin has had some major cleanup work done on it recently. In Pidgin 2.5.4, MSN support should be better than it was in 2.5.2 without the crashes we had in 2.5.3. The IRC protocol is somewhat unique in that it doesn't really fit well into Pidgin's IM-centric model. Pidgin really isn't designed to be a fully-featured IRC client; however, recent releases of Pidgin have functionality which allow plugins to interact with the raw IRC protocol data; someone so inclined could write plugins to extend IRC functionality.
"Chat timestamps on same line as name (not have a hole line devoted to timestamps." - Make your conversation window bigger or turn off some plugins to find the culprit, as there are a few that might be capable of doing that.
"I still miss protocol icons. Green "balls" suck hard." - Sorry, but this is something we're always going to disagree on.
"MSN extra forming like this: [c=61]NICK[/c][c=55]" - We currently have no intention of supporting this "feature" of MSN Plus. I would certainly be open to a patch that just stripped that garbage out, though.
Feature Requests
"An 'official' portable version." - We already provide one. Configuring a portable installation is explained in the FAQ.
"Close all the bugs. That's a major feature." - Oh, how I wish that were true.
"Skype support" - It's our opinion that Skype integration into Pidgin is not possible in a legal manner.
"Being able to add your own emoticons in msn" - This was added in Pidgin 2.5.0. See the Tools menu, and look for "Smiley."
"link to open mail inbox, even when there are no new emails to read." - At least our Yahoo! plugin provides this feature (Accounts->Your Account->Open Inbox). MSN does too, via Accounts->Your Account->Open Hotmail Inbox.
"Video and Voice" - This is currently in the works. We hope to have this out for 3.0.0 (no, we don't know when that will be).
"Major Changes to the interface should be supported as plug-ins. Functionality should NEVER be removed from a product unless that same functionality is re-included via a plug-in or an interface option." - This is, of course, your opinion. Our opinion is that if we were to do this, we'd have an unmaintainable mess of options and plugins. It would be impractical to implement and impossible to manage.
"I'd love to be able to set different notification styles for different groups/users; something like setting different ring tones on cell phones. Also along these lines, I'd love to be able to show different groups different status messages; for instance, if I'm at work and appear offline to everyone but my work buddies group." - Notification styles on a per-group or per-buddy basis is possible by using the Guifications plugin and installing and loading multiple themes. Then you can right-click a group or buddy and you'll find an option to change the Guifications theme for that group/buddy. The status messages per-group could be interesting if all the protocols supported it. However, to the best of my knowledge, no protocol (except possibly XMPP) supports such a capability.
"A Native Windows Interface or QT4 interface (also ports over to windows / Linux / MacOS quite easily from what I understand)" - We have no intention of developing such interfaces ourselves, but we would love if someone made a libpurple interface that fit natively into a Windows desktop environment. We certainly have no objections to someone creating a libpurple interface with Qt, either. None of our current development team has any interest in starting these projects, but I'm sure we're certainly willing to help (to the best of our abilities) with any issues we can.
"Expanded SIP support to replace Windows Messenger 5.1 (not Live Messenger!) since I use it all-day at work." - None of us use Microsoft's corporate instant messaging software, so it's difficult at best for us to make sure that such a protocol plugin is maintained. We also really don't want to pick up any additional protocol support, given our history of protocol maintainers disappearing. There is a team of developers working on the SIPe plugin with the explicit purpose of working with Microsoft's products. Perhaps you should investigate this plugin.
"Better password security. Please, encrypt the passwords inside your config files." - We have an entire wiki page devoted to this topic. Encrypting passwords in accounts.xml is pointless, as it would be trivial to use our own code in an attack. Further, password security is one of the topics of our most recent participation in the Google Summer of Code. We're hoping to have the work that was done on it released soon.
"more support for 3th party protocols like xfire etz meaning box release with these protocols etz" - Um, no. I already discussed the reasons we don't accept additional protocol support.
"Protocols as PlugIns (maybe selectable witch should be installed), AutoUpdate (not only tell about new Versions, also [if user agrees] download, close the client and open setup)" - Protocols have been plugins for many years now. We don't really see a point in making it possible to choose which protocols to install with the Windows install program. Automatic updates would only be useful on Windows, and could actually be done with a plugin if someone were so inclined to write one. We don't have any interest in making it happen though. Sorry.
"It'd be nice to see a version for Windows Mobile... maybe this is already out there and I need to Google... ?" - Pidgin requires GTK+ and Glib (among other libraries), neither of which are available for Windows Mobile yet. Pidgin and libpurple are also a bit heavy in terms of memory and processor time consumption for most devices that run Windows Mobile. You'd be muchbetter served by a client designed specifically to work within the limitations of the Windows Mobile platform.
"Skype support (I've tried the plugin, but it requires Skype client to be running and has no video support, so it's worthless)" - I've covered Skype support already, but I'm going to again point out that we feel this plugin is a violation of our license terms and should not be used by anyone.
"Facebook chat support would be an awesome thing. I'm using the plugin now, but it's got some quirks." - There was a discussion on the mailing list about Facebook support. We came to the conclusion that we don't want to deal with it. If and when Facebook ever rolls out their XMPP interface, we'll be able to support Facebook Chat effortlessly.
"Organize contact list by user by protocol. This way I have a single entry for the user and expand them for multiple ways to contact. It would clean up my contact list significantly." - We have supported combining buddies into contacts for years. Perhaps you should take a look at this FAQ entry?
"Integrated music player support for changing the status based on what I'm listening to...." - I trimmed this down too to get to the important point here. We don't want this in Pidgin. People wanting stuff like this is exactly why we have a plugin system.
"Add a spell check feature!" - We've had one for years. Install an appropriate dictionary for the language you're running Pidgin in.
"1. Support for buzzing/nudging 2. Mass inviting to chats 3. ability to receive MSN voice clips" - 1. We've had this support for years. Use the /nudge command on MSN and /buzz on Yahoo. 2. As soon as someone comes up with a sane UI for it, we'd be happy to accept the patch implementing it. 3. I personally wouldn't mind if this never landed in libpurple, but again this is something that would have to be implemented by someone who wants it.
"Being able to update Pidgin without having to reinstall the whole thing." - That's precisely what an update is--the whole application is replaced with a new version. What about this is unacceptable?
"Multiple user support. Set up a master password for each user to access their accounts." - We've discussed this on numerous occasions. We are not interested in implementing something that the operating system already handles perfectly with its native user account support.
"A plugin for general IMAP mail check. frameless contact list window like adium offers on OSX." - Pidgin is an IM client, not a mail client. That said, anyone who wants this feature is welcome to write a plugin to implement it. Frameless buddy list windows are much easier said than done. Remember that Adium supports precisely one platform, Mac OS X, and as such can do whatever they want to fit better into their environment. Given that we support more platforms than Adium, it makes it particularly difficult because we'd have to have hacks in the code for every platform we support, as well as multiple variations of each plugin. There's not enough benefit to warrant the increase in complexity and the inclusion of such ugly hacks.
"Database logger. There was a SoC project out but it never got completed. Probably due of developers not accepting the student's patches? Support for mIRC srcipts." - If you're referring to the "remotelogger" SoC project, there are some adjustments necessary, and ideally we'd be able to kill off some of the API that it supersedes, thus requiring a 3.0.0. It is, however, in our monotone repository. As far as mIRC scripts, again, this could be done by a plugin. We have no intention of having an internal scripting engine just for mIRC scripts.
"* Cook breakfast" - If Pidgin could cook my breakfast for me, I'd save a LOT of money by not needing to go somewhere for breakfast when I'm too lazy to cook for myself.
"Encryption for chatlogs, auto updating." - This can be provided better by the operating system than by anything we could possibly implement. NTFS filesystems on Windows support encryption, and there are many encryption options for Linux and UNIX environments. Storing your .purple folder in an encrypted area (by symbolic link/junction point or by wrapping Pidgin with a script to point to a non-default configuration directory) would thus give you encryption on your logs. I've already covered automatic updates.
"My opinions refers to Pidgin 2.5.2. Spanish support please and other languages." - We have an active Spanish translator. We have a total of 73 translations, over 2/3 of which are very actively maintained.
"A plugin manager that you could install plugins with, without having to manually place the dills inside of the folder would be nice. Something simialr to mozillas addon managers." - I actually have a plan for something like this, but I haven't been motivated to implement anything for it yet.
"UPDATE OPTION! Once I was running like 2.3.1, when 2.5.2 was out, and I had no idea, pidgin does not have any update monitor to let me know when updates are out, the actual process is simple and i love it." - Take a look at the Release Notification plugin that's included with Pidgin by default.
"More accessible extensibility. Having to write plugins in C and compile them is out of reach for many folks who would write decent plugins." - Perl and TCL plugins are already possible. On Linux/UNIX systems, it's possible to interact with libpurple over D-Bus as well.
General Feedback
"Please switch from Monotone to a wider-known DVCS like Git, Bazaar or Mercurial." - We chose our version control system very carefully several years ago. We went with what we felt was the best choice at the time, and currently, the effort involved in a switch incurs a much higher cost than it's worth.
Why the name change? (I paraphrased this question from several statements) - We entered into an agreement with AOL to avoid being sued for infringement on the "AIM" trademark. The agreement required a name change. This was discussed at length two years ago when we made the change. For the record, we can no longer use our former name, even in technical discussions. This too was part of the agreement.
"I've been always been happy with this product and think it is a fine example of Open Source software and Free Software ideals. Thank You." - And thank you for the kind words. There were a lot of people echoing this sentiment in the general feedback section. In fact, there were far more of this type of comment than I expected.
"Try not to be jerks when people are providing feedbak or suggestions trough mailing list." - It's always interesting to see this come up, because most of the time when we get these complaints, I find that our reactions are quite justified. I'd also like to point out that if you don't like us, you don't have to interact with us. I'm sorry, but we don't exist just to babysit all our users. We have over three million users, and we just can't do it for all of them, or even for a fraction of them.
"The development process should be more transparent, we the users have no idea what's coming next (and when), and if we want to find out, we have to browse dozens of pages of bug reports or some weird wiki page. I'm thinking about the whole 'MSNP15/Personal Message' thing, especially." - We don't know what's coming next or when it will show up either. The development process is transparent; come to our IRC channel, our XMPP chat, and the development mailing list. We have a lot of very public discussion on what we should and shouldn't do and what direction development should go in.
"Don't get me wrong, I appreciate all the effort made by Pidgin. But it seems to me the strong feelings of a few are getting in the way of a real, quality IM client. I understand the desire to remain lean and modular, but that only works up to a point. Of course voice and video chat make more sense as being plugins, but must there really be a plugin just to enable "hiding the buddy list when it's created" ? Pidgin is too complex for the average user. Firefox has struck a moderately good (I'll never say perfect) balance of what basic features are required for any browser and which ones require extensions. I think Pidgin can do the same for IM clients. I'm always looking forward to new releases. Thank you for your work." - Complexity is relative, and in the case of a web browser, it is significantly clearer what belongs in the application itself and what requires extensions/plugins. In an IM client, it's not so clear. This is why we have a plugins system--things we think don't belong in Pidgin itself can be developed as plugins. The strong opinions I and others express are a check and balance to make sure we don't as a project go to extremes, and also serve to keep us focused on important things like fixing bugs instead of pointless political stuff and catering to every person's whim. The thing a lot of our users forget quite easily is that we work on Pidgin for ourselves, so if we don't like an idea, we're going to rally against it and block its inclusion.
There are many more comments I'd have liked to address here, but there are just too many of them and I don't have the time to draft individual responses to all of them. I hope these responses show that we do listen to user feedback. We always listen, but we don't always act. There is a difference there that a lot of people don't understand.
The sheer number of responses we received, including the comments expressing what a good job we've done, have shown me that we were correct when we asserted that we had a huge portion of our userbase that is either indifferent to many of the changes we make or mostly satisfied with us in general and don't feel the need to send feedback.
In short, thanks for the feedback!
Complaints
"Could be clearer how to set up pidgin with ssh." - This request isn't quite clear, but I'm going to assume that the person wants to know how to use Pidgin either with an ssh tunnel or with ssh acting as a proxy. In the former case, ssh tunnels are documented quite extensively; you would configure your tunnel, then configure the Pidgin account to connect to localhost on the port you're forwarding. Using ssh as a SOCKS5 proxy is also well documented; you would set up the ssh proxy according to the documentation and then configure Pidgin's proxy settings to use the proxy on localhost. We haven't documented this ourselves because a lot of good generic documentation already exists, and it's not exactly a common use case that we see.
"I would like to see auto-reconnect be more resilient. I tend to have to manually reconnect after actual network outages. Also, it'd be nice if the encryption plugin knew when to get out of the way." - This is actually two comments, but I'll address them both. The auto-reconnect feature uses an exponential backoff that starts at just a few seconds between attempts and backs off to a maximum retry time of 34 minutes. If your Pidgin is compiled with NetworkManager support, NetworkManager may cause some delays due to not realizing the network is back. On Windows, there are some interactions with the Network Location Awareness features in Windows XP and Windows Vista that can cause delays in the reconnection as well. As for encryption, we didn't write the encryption plugins; that's a complaint/suggestion best taken up with whoever wrote the plugin you're using.
"Fix the chat input box please, or I'll switch to Carrier/Fun Pidgin." - Isn't Carrier dead? Anyway, if you feel the need to switch clients, that's your prerrogative. We've debated this at length on numerous occasions and we've decided to stick with the autoresizing input area, at least for now.
"Have the buddy list show up when i open pidgin, and have a popup when a person says something in a conversation." - There are two plugins already that provide popup notifications. One is called Guifications, the other is pidgin-libnotify. Windows users need to use Guifications. Users of other operating systems can use either. As far as the buddy list visibility goes, if you want to see the buddy list when you open Pidgin, either set "Show system tray icon" to "Never" in preferences, or have the buddy list open when you close Pidgin. The ability to start with the buddy list hidden was a feature request we chose to implement, and it would cause too many complaints for us to remove it.
"Better memory usage on windows or an up to date GTK included." - We do actively try to reduce Pidgin's memory usage where we can see room for improvement; patches are welcome for conditions we don't see. Our Windows person bundles new GTK+ runtimes as it's confirmed that new WinGTK+ releases don't introduce problems for us.
"crashes, crashes, crashes" - We do our best to fix the crashes that get reported. Perhaps you should read "Tips for Bug Reports" and then open a ticket.
"Docking pidgin in windows vista rearranges my icons on the desktop, but this is a problem with all programs that dock so not really important." - You've correctly realized on your own that Pidgin is not at fault here. This is a bug in Windows' desktop management, which we can't do anything about. I remember seeing this bug as far back as Windows 98, so it's not exactly new either. Maybe Microsoft could be convinced to fix this 11-year-old undesirable behavior?
"None. Keep it simple. I love that." - Thanks! We love simple. Clean, too!
"File transfer speed in MSN protocol" - We know a lot of our users are dissatisfied with the state of MSN file transfer support in libpurple. We're sorry you're not happy with it, but it's just not a priority for us. If someone comes along and implements a good (or even semi-reasonable) patch to do this, we'd be happy to work with that person to include better transfer support.
"Startup time. It takes about 10 seconds for me to get Pidgin 'usable'." - 10 seconds is not an unreasonable amount of time. Remember that Pidgin has to connect to all your accounts (MSN can be particularly slow here!), load your buddy list from the server, apply your saved preferences, load your saved plugins (including the protocol plugins), etc. There's a lot of work that goes on in those 10 seconds that is difficult, if not impossible, to streamline any further. You may, however, be able to shave some startup time off by removing any plugins you don't use (you can see paths and filenames by going to the Plugins window, clicking on a plugin's name, and clicking the expander by "Plugin Details").
"Some XMPP contacts are added twice." - We've had this bug forever, and it irritates us too. There has been some recent work on this. It should be better in 2.5.3 and 2.5.4 than in previous releases.
"1) One thing that confuses me...when a pidgin window aside from the chat window has focus (Buddy List, Manage Accounts, etc), and you type, it opens up a little window with that text in it...I probably just need to RTFM and it's working as intended, but who knows... 2) When setting status to Away, you are allowed to enter a message. Prior to version 2.5.2, when setting status back to Available, this message would be cleared automatically. From version 2.5.2 and after, it is now highlighted for manual deletion, which I find annoying. 3) Animated smileys would be awesome (but I assume that is more so on Hylke). I do love the current smileys though!" - Three points, so three answers: 1. This is a feature provided by GTK+ sometimes called "typeahead search." If you type text that matches a buddy's name or alias, that buddy will automatically be highlighted. 2. We discussed this a couple of times. Both use cases are valid, but it's our opinion that it's less annoying for people who want new messages to have to type a single backspace than it is for users who want to keep the same status message across multiple statuses to have to retype their whole message. Sorry. 3. Yes, animated emoticons would be something Hylke would need to create for us if he felt so inclined, but I think we'd all be better served if animated emoticons were a separate theme from the default.
"GTK" - I'm going to go out on a limb and say the person who wrote this complaint is a Windows user. We use GTK+ because Windows was not our first platform, and GTK+ was the best toolkit for the purpose when Pidgin was started in 1998. We would love to see someone write a native Windows interface for libpurple, as we know it would serve most Windows users better than our GTK+ interface ever could.
"It is not very easy to install Pidgin on Linux distributions, especially because of dependencies." - This is true of source-based installation of Pidgin for those who don't compile many applications themselves or those new to the world of compiling applications. Pidgin is provided in a pre-packaged, dependency-tracked format by all the major Linux distributions, as well as through the BSD ports system, Fink on Mac OS X, and Macports on Mac OS X. All of these distributors provide an extremely simple way to install Pidgin.
"Using special characters in statuses crashes Pidgin. With MusicTracker, this can happen a lot... and crash my client. Pidgin ought to replace these characters with question marks or something. Also, file transfer is very slow and erratic, especially with non-Pidgin users." - I've covered the file transfer above, to an extent. Special characters themselves don't crash Pidgin. MusicTracker could probably prevent some crashes by making sure that all strings it passes into libpurple are UTF-8. We have recently made some changes that should help in this regard, but plugins should still make sure they hand us only valid UTF-8 strings.
"Pidgin steals keyboard focus when it raises a conversation window, which is very bad. I want windows to raise when I receive new messages, but without stealing keyboard focus, especially from another conversation window I'm actively typing in...." - I have trimmed a longer user submission here to a specific issue to reply to for clarity and brevity. Pidgin doesn't ask for focus. Some window managers, however, treat a raise request as a focus request. These window managers should be fixed. Trying other window managers and seeing their behavior would confirm this.
"I'd like to see some new looks available by themes (sounds included would be nice) so long as they don't change the position and location of various options. I know skins and themes are mentioned already in the survey but I've wanted them for a while and it's the only thing I can think of that I really want to see." - Some theming support, including sound themes, was worked on during the Google Summer of Code for 2008. We expect to release this work in Pidgin 2.6.0, but no promises.
"Wrong encoding for incoming messages from 'QIP' users (icq protocol) writing with diacritic marks in czech/slovak (encoding central european, both iso 8859-2 and win 1250)." - I really wish everyone would just use UTF-8 already. All these problems would magically go away.
"x-status support for ICQ protocol" - This is something else we expect to release in Pidgin 2.6.0.
"doesn't always connect to a network" - More details are necessary to help in this case.
"A two pane plugin-preferences dialog would be nice. You select the plugin on the left pane and the preference are displayed in the right pane." - It seems that no matter what we do for plugin configuration, no one's ever happy with it. If someone can come up with a plugin configuration dialog that everyone can live with, I'd gladly fight (if needed) to get it in a release.
"Please fix the auto-away option - it's been broken since at least version 2.1 or 2.2. For example, when status is set to 'Invisible', it changes to 'Away' after been idle for a while (this shouldn't happen when offline) - and then, when initiating a conversation with someone, it changes back to the original offline status ('Invisible' in this case)! Peer-to-peer MSN file transfers would also be nice, as that function is almost unusable in its current state." - Again, I have already covered MSN file transfers, but I'm responding to this for the auto-away complaint. I'll admit that the behavior you describe is undesirable, but it is working as designed. It might make sense to exempt an original status of "Invisible" from auto-away, but this is a slippery slope in some respects--we make this change for Invisible, and people will want all sorts of unique exceptions.
"Too many dependencies, make it lighter!" - Yes, we have a lot of dependencies, but very few of them are requirements. If you're building Pidgin yourself, you can disable all but the absolute minimum required dependencies by making use of the "--disable-????" family of arguments to the configure script ("./configure --help" will show you the options). We are very cautious about adding new dependencies unnecessarily.
"MSN protocol seems buggy, IRC isn't very customizable" - The MSN protocol plugin has had some major cleanup work done on it recently. In Pidgin 2.5.4, MSN support should be better than it was in 2.5.2 without the crashes we had in 2.5.3. The IRC protocol is somewhat unique in that it doesn't really fit well into Pidgin's IM-centric model. Pidgin really isn't designed to be a fully-featured IRC client; however, recent releases of Pidgin have functionality which allow plugins to interact with the raw IRC protocol data; someone so inclined could write plugins to extend IRC functionality.
"Chat timestamps on same line as name (not have a hole line devoted to timestamps." - Make your conversation window bigger or turn off some plugins to find the culprit, as there are a few that might be capable of doing that.
"I still miss protocol icons. Green "balls" suck hard." - Sorry, but this is something we're always going to disagree on.
"MSN extra forming like this: [c=61]NICK[/c][c=55]" - We currently have no intention of supporting this "feature" of MSN Plus. I would certainly be open to a patch that just stripped that garbage out, though.
Feature Requests
"An 'official' portable version." - We already provide one. Configuring a portable installation is explained in the FAQ.
"Close all the bugs. That's a major feature." - Oh, how I wish that were true.
"Skype support" - It's our opinion that Skype integration into Pidgin is not possible in a legal manner.
"Being able to add your own emoticons in msn" - This was added in Pidgin 2.5.0. See the Tools menu, and look for "Smiley."
"link to open mail inbox, even when there are no new emails to read." - At least our Yahoo! plugin provides this feature (Accounts->Your Account->Open Inbox). MSN does too, via Accounts->Your Account->Open Hotmail Inbox.
"Video and Voice" - This is currently in the works. We hope to have this out for 3.0.0 (no, we don't know when that will be).
"Major Changes to the interface should be supported as plug-ins. Functionality should NEVER be removed from a product unless that same functionality is re-included via a plug-in or an interface option." - This is, of course, your opinion. Our opinion is that if we were to do this, we'd have an unmaintainable mess of options and plugins. It would be impractical to implement and impossible to manage.
"I'd love to be able to set different notification styles for different groups/users; something like setting different ring tones on cell phones. Also along these lines, I'd love to be able to show different groups different status messages; for instance, if I'm at work and appear offline to everyone but my work buddies group." - Notification styles on a per-group or per-buddy basis is possible by using the Guifications plugin and installing and loading multiple themes. Then you can right-click a group or buddy and you'll find an option to change the Guifications theme for that group/buddy. The status messages per-group could be interesting if all the protocols supported it. However, to the best of my knowledge, no protocol (except possibly XMPP) supports such a capability.
"A Native Windows Interface or QT4 interface (also ports over to windows / Linux / MacOS quite easily from what I understand)" - We have no intention of developing such interfaces ourselves, but we would love if someone made a libpurple interface that fit natively into a Windows desktop environment. We certainly have no objections to someone creating a libpurple interface with Qt, either. None of our current development team has any interest in starting these projects, but I'm sure we're certainly willing to help (to the best of our abilities) with any issues we can.
"Expanded SIP support to replace Windows Messenger 5.1 (not Live Messenger!) since I use it all-day at work." - None of us use Microsoft's corporate instant messaging software, so it's difficult at best for us to make sure that such a protocol plugin is maintained. We also really don't want to pick up any additional protocol support, given our history of protocol maintainers disappearing. There is a team of developers working on the SIPe plugin with the explicit purpose of working with Microsoft's products. Perhaps you should investigate this plugin.
"Better password security. Please, encrypt the passwords inside your config files." - We have an entire wiki page devoted to this topic. Encrypting passwords in accounts.xml is pointless, as it would be trivial to use our own code in an attack. Further, password security is one of the topics of our most recent participation in the Google Summer of Code. We're hoping to have the work that was done on it released soon.
"more support for 3th party protocols like xfire etz meaning box release with these protocols etz" - Um, no. I already discussed the reasons we don't accept additional protocol support.
"Protocols as PlugIns (maybe selectable witch should be installed), AutoUpdate (not only tell about new Versions, also [if user agrees] download, close the client and open setup)" - Protocols have been plugins for many years now. We don't really see a point in making it possible to choose which protocols to install with the Windows install program. Automatic updates would only be useful on Windows, and could actually be done with a plugin if someone were so inclined to write one. We don't have any interest in making it happen though. Sorry.
"It'd be nice to see a version for Windows Mobile... maybe this is already out there and I need to Google... ?" - Pidgin requires GTK+ and Glib (among other libraries), neither of which are available for Windows Mobile yet. Pidgin and libpurple are also a bit heavy in terms of memory and processor time consumption for most devices that run Windows Mobile. You'd be muchbetter served by a client designed specifically to work within the limitations of the Windows Mobile platform.
"Skype support (I've tried the plugin, but it requires Skype client to be running and has no video support, so it's worthless)" - I've covered Skype support already, but I'm going to again point out that we feel this plugin is a violation of our license terms and should not be used by anyone.
"Facebook chat support would be an awesome thing. I'm using the plugin now, but it's got some quirks." - There was a discussion on the mailing list about Facebook support. We came to the conclusion that we don't want to deal with it. If and when Facebook ever rolls out their XMPP interface, we'll be able to support Facebook Chat effortlessly.
"Organize contact list by user by protocol. This way I have a single entry for the user and expand them for multiple ways to contact. It would clean up my contact list significantly." - We have supported combining buddies into contacts for years. Perhaps you should take a look at this FAQ entry?
"Integrated music player support for changing the status based on what I'm listening to...." - I trimmed this down too to get to the important point here. We don't want this in Pidgin. People wanting stuff like this is exactly why we have a plugin system.
"Add a spell check feature!" - We've had one for years. Install an appropriate dictionary for the language you're running Pidgin in.
"1. Support for buzzing/nudging 2. Mass inviting to chats 3. ability to receive MSN voice clips" - 1. We've had this support for years. Use the /nudge command on MSN and /buzz on Yahoo. 2. As soon as someone comes up with a sane UI for it, we'd be happy to accept the patch implementing it. 3. I personally wouldn't mind if this never landed in libpurple, but again this is something that would have to be implemented by someone who wants it.
"Being able to update Pidgin without having to reinstall the whole thing." - That's precisely what an update is--the whole application is replaced with a new version. What about this is unacceptable?
"Multiple user support. Set up a master password for each user to access their accounts." - We've discussed this on numerous occasions. We are not interested in implementing something that the operating system already handles perfectly with its native user account support.
"A plugin for general IMAP mail check. frameless contact list window like adium offers on OSX." - Pidgin is an IM client, not a mail client. That said, anyone who wants this feature is welcome to write a plugin to implement it. Frameless buddy list windows are much easier said than done. Remember that Adium supports precisely one platform, Mac OS X, and as such can do whatever they want to fit better into their environment. Given that we support more platforms than Adium, it makes it particularly difficult because we'd have to have hacks in the code for every platform we support, as well as multiple variations of each plugin. There's not enough benefit to warrant the increase in complexity and the inclusion of such ugly hacks.
"Database logger. There was a SoC project out but it never got completed. Probably due of developers not accepting the student's patches? Support for mIRC srcipts." - If you're referring to the "remotelogger" SoC project, there are some adjustments necessary, and ideally we'd be able to kill off some of the API that it supersedes, thus requiring a 3.0.0. It is, however, in our monotone repository. As far as mIRC scripts, again, this could be done by a plugin. We have no intention of having an internal scripting engine just for mIRC scripts.
"* Cook breakfast" - If Pidgin could cook my breakfast for me, I'd save a LOT of money by not needing to go somewhere for breakfast when I'm too lazy to cook for myself.
"Encryption for chatlogs, auto updating." - This can be provided better by the operating system than by anything we could possibly implement. NTFS filesystems on Windows support encryption, and there are many encryption options for Linux and UNIX environments. Storing your .purple folder in an encrypted area (by symbolic link/junction point or by wrapping Pidgin with a script to point to a non-default configuration directory) would thus give you encryption on your logs. I've already covered automatic updates.
"My opinions refers to Pidgin 2.5.2. Spanish support please and other languages." - We have an active Spanish translator. We have a total of 73 translations, over 2/3 of which are very actively maintained.
"A plugin manager that you could install plugins with, without having to manually place the dills inside of the folder would be nice. Something simialr to mozillas addon managers." - I actually have a plan for something like this, but I haven't been motivated to implement anything for it yet.
"UPDATE OPTION! Once I was running like 2.3.1, when 2.5.2 was out, and I had no idea, pidgin does not have any update monitor to let me know when updates are out, the actual process is simple and i love it." - Take a look at the Release Notification plugin that's included with Pidgin by default.
"More accessible extensibility. Having to write plugins in C and compile them is out of reach for many folks who would write decent plugins." - Perl and TCL plugins are already possible. On Linux/UNIX systems, it's possible to interact with libpurple over D-Bus as well.
General Feedback
"Please switch from Monotone to a wider-known DVCS like Git, Bazaar or Mercurial." - We chose our version control system very carefully several years ago. We went with what we felt was the best choice at the time, and currently, the effort involved in a switch incurs a much higher cost than it's worth.
Why the name change? (I paraphrased this question from several statements) - We entered into an agreement with AOL to avoid being sued for infringement on the "AIM" trademark. The agreement required a name change. This was discussed at length two years ago when we made the change. For the record, we can no longer use our former name, even in technical discussions. This too was part of the agreement.
"I've been always been happy with this product and think it is a fine example of Open Source software and Free Software ideals. Thank You." - And thank you for the kind words. There were a lot of people echoing this sentiment in the general feedback section. In fact, there were far more of this type of comment than I expected.
"Try not to be jerks when people are providing feedbak or suggestions trough mailing list." - It's always interesting to see this come up, because most of the time when we get these complaints, I find that our reactions are quite justified. I'd also like to point out that if you don't like us, you don't have to interact with us. I'm sorry, but we don't exist just to babysit all our users. We have over three million users, and we just can't do it for all of them, or even for a fraction of them.
"The development process should be more transparent, we the users have no idea what's coming next (and when), and if we want to find out, we have to browse dozens of pages of bug reports or some weird wiki page. I'm thinking about the whole 'MSNP15/Personal Message' thing, especially." - We don't know what's coming next or when it will show up either. The development process is transparent; come to our IRC channel, our XMPP chat, and the development mailing list. We have a lot of very public discussion on what we should and shouldn't do and what direction development should go in.
"Don't get me wrong, I appreciate all the effort made by Pidgin. But it seems to me the strong feelings of a few are getting in the way of a real, quality IM client. I understand the desire to remain lean and modular, but that only works up to a point. Of course voice and video chat make more sense as being plugins, but must there really be a plugin just to enable "hiding the buddy list when it's created" ? Pidgin is too complex for the average user. Firefox has struck a moderately good (I'll never say perfect) balance of what basic features are required for any browser and which ones require extensions. I think Pidgin can do the same for IM clients. I'm always looking forward to new releases. Thank you for your work." - Complexity is relative, and in the case of a web browser, it is significantly clearer what belongs in the application itself and what requires extensions/plugins. In an IM client, it's not so clear. This is why we have a plugins system--things we think don't belong in Pidgin itself can be developed as plugins. The strong opinions I and others express are a check and balance to make sure we don't as a project go to extremes, and also serve to keep us focused on important things like fixing bugs instead of pointless political stuff and catering to every person's whim. The thing a lot of our users forget quite easily is that we work on Pidgin for ourselves, so if we don't like an idea, we're going to rally against it and block its inclusion.
There are many more comments I'd have liked to address here, but there are just too many of them and I don't have the time to draft individual responses to all of them. I hope these responses show that we do listen to user feedback. We always listen, but we don't always act. There is a difference there that a lot of people don't understand.
The sheer number of responses we received, including the comments expressing what a good job we've done, have shown me that we were correct when we asserted that we had a huge portion of our userbase that is either indifferent to many of the changes we make or mostly satisfied with us in general and don't feel the need to send feedback.
In short, thanks for the feedback!
Wednesday, December 31, 2008
I love Windows. I really, really do. (Yeah, right)
Well, it's been eight days since we released Pidgin 2.5.3. In that 8 days, we've had more duplicate tickets than we care to count over the all-too-common hang on exit on Windows systems. In the faint hope that people actually read my ramblings, I'm posting this here to give a brief synopsis of the problem and to discourage further duplicate tickets.
On Windows sytems, Pidgin uses threads for a few things, namely DNS lookups and Network Location Awareness (NLA) stuff. For the Linux-inclined, NLA is somewhat similar to NetworkManager. When we released Pidgin 2.5.3, we started getting a bunch of reports about hangs on exit (including a number of people who don't know the difference between a hang and a crash, but that's another post in itself). All the debug logs pointed to wpurple_cleanup(), a function we call on close to tie up some loose ends, or "clean up." One of the areas this function cleans up is NLA-related stuff.
This code hasn't changed meaningfully in quite some time, but magically it became a problem for users of 2.5.3. It doesn't really make any sense to me why this would suddenly stop working in the current release, but the previous release seems to be almost entirely problem-free in this regard. Confusion aside, however, we have a proposed fix that will be reviewed and possibly tweaked.
So in summary, we know what the problem is and we are working to fix it. Please, please, please don't open anymore duplicate tickets about it!
On Windows sytems, Pidgin uses threads for a few things, namely DNS lookups and Network Location Awareness (NLA) stuff. For the Linux-inclined, NLA is somewhat similar to NetworkManager. When we released Pidgin 2.5.3, we started getting a bunch of reports about hangs on exit (including a number of people who don't know the difference between a hang and a crash, but that's another post in itself). All the debug logs pointed to wpurple_cleanup(), a function we call on close to tie up some loose ends, or "clean up." One of the areas this function cleans up is NLA-related stuff.
This code hasn't changed meaningfully in quite some time, but magically it became a problem for users of 2.5.3. It doesn't really make any sense to me why this would suddenly stop working in the current release, but the previous release seems to be almost entirely problem-free in this regard. Confusion aside, however, we have a proposed fix that will be reviewed and possibly tweaked.
So in summary, we know what the problem is and we are working to fix it. Please, please, please don't open anymore duplicate tickets about it!
Subscribe to:
Comments (Atom)