Slashdot Mirror
Pidgin Controversy Triggers Fork
paleshadows writes "Pidgin, the premier multi-protocol
instant messaging client, has been forked. This is the result of a heated, emotional, and
very interesting debate over a controversial new feature: As of
version 2.4, the ability to manually resize the text input area has
been removed; instead, it automatically resizes depending on how much
is typed. It turns out that this feature, along with the uncompromising
unwillingness of the developers to provide an option to turn it off,
annoys the bejesus of very many users.
One
comment made by a Professor that teaches "Collaboration in an Open
Source World" argued that 'It's easy to see why open source developers could develop dogmas. [...]
The most dangerous dogma is the one exhibited
here: the God feature. "One technological solution can meet
every possible user-desired variation of a feature." [...]
You [the developers] are ignoring the fan base with a dedication to your convictions
that is alarmingly evident to even the most unobservant of followers,
and as such, you are demonstrating that you no longer deserve to be in
the position of servicing the needs of your user base.'" Does anyone besides me find this utterly ridiculous?
here
This wouldn't be the first time the pidgeon folk have decided to change the interface and refused to let people keep things the way they liked. Forks have been threatened before over their decision to hide protocol icons as well. I'm glad they separated the gui from the rest of the program - both this and the protocol icon decision really bug me.
For every problem, there is at least one solution that is simple, neat, and wrong.
A writing professor once called this "murdering your darlings," in the context of writing fiction.
You develop a scene with blood, sweat and tears, and then realize it's baggage and there's a better way, and shorter/more compact is always better.
It hurts but it beats the alternative, which is reduced quality of writing.
technical writing / development
For anyone interested, the fork is called "Funpidgin" and can be found here.
The summary makes light of it, but the Funpidgin page explains that their intention is to respond more directly to the requests of the user community. In addition to the feature mentioned in the summary, Funpidgin has implemented some others, and will presumably continue adding user-requested features (while still integrating upgrades from the pidgin codebase, presumably).
Forks are both good and bad; this one is no exception. On the one hand it "wastes effort" and can duplicate work. On the other hand, it can give the user community (which isn't homogeneous) the product(s) they want. It can encourage useful competition. Often the end result will be better than if no fork had occurred. Another example is the Compiz/Beryl fork, which created some duplication for awhile, but ultimately turned out for the best since the merged Compiz Fusion includes the best features from both (a stable core and all the whiz-bang features users wanted, in the form of plugins).
If both the Pidgin and Funpidgin developers work to provide something that their respective users find worthwhile, then what's the problem?
Considering my general hatred of the Pidgin UI, no, I don't find this ridiculous.
Let's start with Pidgin's UI Sucks, which details some of the weird UI decisions made back around version 2.1. Fortunately they've fixed almost all the issues listed in that post.
More Pidgin Bashing is just a bug, so let's skip ahead to Pidgin's Crappy Formatting Icons which they have not fixed.
If I ever had the time to, I'd like to write a new UI for libpurple, Pidgin's backend. I have some ideas - but not enough time to actually learn how to use libpurple.
Maybe I can help with this fork, called... uh. Hm. The summary doesn't appear to mention it.
Ah, here we go: funpidgin.
You are in a maze of twisty little relative jumps, all alike.
Ya know, I can't blame the community for this fork. The gaim/pidgin developers have had a bad history of 'God complex'. Hell, just recently they refused to make any changes to the way Pidgin handles SASL authentication to XMPP servers due to a change in the 2.4 codebase that completely breaks SSL encryption to the OpenFire XMPP server, whereas the 2.3 codebase AND every other XMPP client seems to not have any issues. Their response was something along the lines of "yeah, well we're doing it right..every other client is doing it wrong". I find that hard to believe. This ultimately leaves me with 2 options: either don't upgrade past version 2.3 of Pidgin, or use another client. And yes, not being able to resize the input text box drives me absolutely crazy. I look forward to a forked version addressing this and the XMPP SASL authentication issues.
here
rather:
No slashdot thread is complete without at least one (1) Microsoft bash.
Corollary: As it adds to the completeness of the thread, it will be modded informative.
"The cup is in turn designed for holding hot or cold liquids, and has an open rim and closed base." --US Patent #5425497
I suggest everyone read this developers take on the issue. I think you will find it quite a bit more understanding than the original post makes it out to be.
There is a plugin available that does just that, but the Pidgin developers don't want to include it as a default plugin. Partly because they don't want to clutter the plugin list, and party because they wish to force users to get used to their auto-resize input area.
"You're reading this because our trac can't keep up with all the people clicking through slashdot. The ticket really isn't very interesting, it's mostly name-calling. You can read it later, when the flood of people fetching it is something trac can handle.
... yes, there are people who are unhappy with our IM client, which is a work in progress. Yes, a lot of the comments on the ticket were completely unreasonable. No, there are not a large number of unhappy users on the ticket, but there are a large number of comments. We call this a "vocal minority". Yes, we have already implemented most of the "features" in the fork -- some of them before it ever forked. No, we aren't running back to the old method of resizing the input box, but yes, options are still on the table.
In the mean time, here's a simplified summary of the situation (not the ticket).
Yes, there is a fork
This statement is not intended to be a position, it is simply a summary of the situation as we understand it.
Happy browsing. "
He talks about standard responses to UI complaints as if they are grudgingly listened to by developers and the "patches welcome" reply is generally used as an OSS way to tell users to go-climb-a-tree. Read the whole article.
Alrighty then.
*ahem* Microsoft SUCK0RZ!!!1111ONE
There. Mission Accomplished!
Well, no, it's actually a little widget that you interact with via the mouse. I don't know what else it could legitimately be called.
DNA just wants to be free...
I can only assume you don't do much graphical UI development. "Widget" is a standard technical term used to refer to an element of a GUI. See for instance GUI Widget on Wikipedia.
The Safari text boxes are compound widgets (or metawidgets, if you like), which include a "resize handle" widget in their corner.
DNA just wants to be free...
Have you actually used it? Did you try the old version?
If not, why do you have an opinion on it at all? If so, what specifically is wrong with it.
Personally, I've been using it for a while now and it works fine - most messages are a single line and having the text box grow by a line when I exceed the length of a line is wonderfully convenient.
-- The act of censorship is always worse than whatever is being censored. Always.
On newsgoups and mailing lists, top posting is bad. In email however, either all clients need a way to jump to the most recent message, or the message needs to be at the top.
I hate having to scroll through 6 pages of an email at work just to read the boss's "ok, do it."