Opened 8 years ago

Closed 8 years ago

Last modified 5 years ago

#4986 closed enhancement (wontfix)

automatic chat input field resizing should be optional, regression from 2.3

Reported by: swbrown Owned by:
Milestone: Component: pidgin (gtk)
Version: 2.4.0 Keywords: chat input resize
Cc: jlechem

Description

With 2.4.0, the input field in the chat window is automatically sized to some degree rather than be arrangeable by the user. Problem is, it's very restrictive as the size doesn't scale up to what many were accustomed to using in 2.3 when editing large messages (code, for example), and there's no option to disable it. To me, this is a usability regression from 2.3, however, ticket #4962 considering this a bug was closed invalid, so I'm entering this as an enhancement. Please either provide an option to disable this feature or revert it.

Attachments (5)

auto-resize-regression.jpg (44.2 KB) - added by swbrown 8 years ago.
Example of extreme resize limiting in 2.4.
text box.PNG (16.4 KB) - added by mlsterben 8 years ago.
pidgin-inputtext.PNG (49.4 KB) - added by kepplah 8 years ago.
Text input box behavior
Screenshot_conversation-window_2.4.0.TIF (36.4 KB) - added by G-sus 8 years ago.
IMWindow.jpg (21.0 KB) - added by Niomar 8 years ago.
No area to type when first receive a new IM. Once I hit a key, it resizes to 2 lines.

Download all attachments as: .zip

Change History (325)

Changed 8 years ago by swbrown

Example of extreme resize limiting in 2.4.

comment:1 Changed 8 years ago by tmetro

Adding keywords: conversation, split

comment:2 Changed 8 years ago by mlsterben

My ticket was just closed because this was already made, but I completely agree. It looks smaller on my computer, and it's really a huge pain. The only reason I can see that this was implemented is because of a mistake. The small window is a huge step backwards.

comment:3 Changed 8 years ago by Gookey

I completely agree too. Having the program work some magic seems cool, but users should be given the option to activate the feature.

comment:4 Changed 8 years ago by roan

I would really appreciate this feature being reimplemented (or more likely: this bug to be fixed). Made me go back to 2.3.

comment:5 Changed 8 years ago by lu_zero

+1 (since apparently there isn't a way to just monitor this bug.)

comment:6 Changed 8 years ago by Tenchan

The automatic resizing is unacceptable. The upper limit of four lines is crippling for long messages and especially for people who are visually handicapped and need to use big fonts and/or a bigger input field.

comment:7 Changed 8 years ago by varchar255

cc

comment:8 Changed 8 years ago by Iyeru

I have to agree, I liked it when I could resize the text input. Now it reminds me of when trillian can't remember convo sizes.

comment:9 Changed 8 years ago by tkl

Like others, I went back to the 2.3 release rather than keep putting up with this "bug" of not being able resize the text area to a fixed size.

comment:10 Changed 8 years ago by dave314159

As much as this new feature annoys the hell out of me, I can see how it might be useful to people using small screens and/or low resolutions.

In this light, it could be seen to enhance accessibility IFF it is made optional.

It might even make sense to have the current implementation be enabled by default, and have the old functionality be an option.

comment:11 Changed 8 years ago by kdorff

+1. I was really amazed that the resizing of the bottom pane was gone and I would really like it see resize-ability come back to the Pidgin compose pane.

comment:12 Changed 8 years ago by jason0x21

I registered an account on here just to add my name to the growing list of people who want the old function back. Make it an option. Make the new way the default if you must, but bring the old function back, please.

comment:13 Changed 8 years ago by plmayer

cc

comment:14 Changed 8 years ago by kepplah

I'm not a fan of this new change but I will give it a chance to grow on me. Please allow us to at least set the minimum size to one line, or at least an option to disable auto-resizing. This current method of it being just a few pixels tall makes no point, and is confusing for usability reasons.

comment:15 Changed 8 years ago by posix40

yeah I just opened a duped ticket to raise awareness I've reverted back to 2.3.1. I found the input box very challenging to type in.

comment:16 in reply to: ↑ description Changed 8 years ago by Gookey

I've noticed that this ticket isn't actually assigned to anyone. Would doing that help raise awareness?

comment:17 Changed 8 years ago by hbons

IM is about sending relatively short messages quickly, Pidgin isn't a text editor, if you want to edit code use gedit or something. I see no reason why to have more than 3 lines, there's e-mail for that. I think the devs share the same opinion, and I don't think this is going to change.

comment:18 Changed 8 years ago by plmayer

I am sorry, but saying something like "I don't use it like that, so I don't care if you're having problems" is exactly the kind of attitude which makes users of your software take to their heels.

It is such a small change to add the ability to resize this box; it doesn't hurt anyone, and obviously many people would like to have it.

I understand if you're feeling pissed off if you just implemented a new feature and nobody seems to like it, but such is life.

comment:19 follow-up: Changed 8 years ago by hbons

I am sorry, but saying something like "I don't use it like that, so I don't care if you're having problems" is exactly the kind of attitude which makes users of your software take to their heels.

I'm not saying I don't care about this "problem". Only, Pidgin wasn't designed to be a text editor. If you're complaining about you can't code in Pidgin, I would tell you to to use something else, and so would anyone else. If you realy, really want to code in Pidgin, I suggest writing a plugin that has all the features a modern text editor has.

It is such a small change to add the ability to resize this box; it doesn't hurt anyone, and obviously many people would like to have it.

And it's "such a small change" to add code higlighting or a search/replace feature too. Pidgin must focus on it's goal: being a usable IM client.

I understand if you're feeling pissed off if you just implemented a new feature and nobody seems to like it, but such is life.

I don't think the devs are pissed off about this, now they won't have their input boxes in random sizes.

comment:20 follow-up: Changed 8 years ago by plmayer

Pidgin must focus on it's goal: being a usable IM client.

I completely agree. But you see, "usable" means different things for different people. I, for example, would like to type longer messages to my friends than fits the box. So now I have to scroll, which is not impossible but also not very user friendly.

So, in effect, you're defining here what an "IM" message is and what a "EMAIL" message is. Whats the count of characters where we draw this line? Does everybody draw this line at the same count? I'm simply being pro-choice here - let everybody select what he or she wants, which is luckily(!) rather easy here.

comment:21 in reply to: ↑ 19 Changed 8 years ago by lu_zero

Replying to hbons:

I am sorry, but saying something like "I don't use it like that, so I don't care if you're having problems" is exactly the kind of attitude which makes users of your software take to their heels.

I'm not saying I don't care about this "problem". Only, Pidgin wasn't designed to be a text editor. If you're complaining about you can't code in Pidgin, I would tell you to to use something else, and so would anyone else. If you realy, really want to code in Pidgin, I suggest writing a plugin that has all the features a modern text editor has.

Putting it in another perspective, a bug tracker isn't designed to be a forum...

I don't think the devs are pissed off about this, now they won't have their input boxes in random sizes.

There is an usability regression as pointed by the screenshot, no other sane client has such castration, thus the goal "being a usable IM client" is missed.

comment:22 in reply to: ↑ 20 ; follow-up: Changed 8 years ago by hbons

Replying to plmayer:

Pidgin must focus on it's goal: being a usable IM client.

I completely agree. But you see, "usable" means different things for different people. I, for example, would like to type longer messages to my friends than fits the box. So now I have to scroll, which is not impossible but also not very user friendly.

True, but most people keep the lines short, that is a characteristic of IM. I too am not to fond of the scrollbar appearing so fast, but i like the 2 lines by default. The input area should expand whenever you hit <shift>+<enter> and have a scrollbar at over 15 lines or so, after that restore to its original size.

So, in effect, you're defining here what an "IM" message is and what a "EMAIL" message is. Whats the count of characters where we draw this line? Does everybody draw this line at the same count? I'm simply being pro-choice here - let everybody select what he or she wants, which is luckily(!) rather easy here.

There is no clear line of the count of characters. But in practice, IM messages are usually one line. Pidgin even has 2 lines! ;)

The point is, we should find a better solution that works both ways, instead of "making it an option".

comment:23 in reply to: ↑ 22 Changed 8 years ago by Iyeru

Replying to hbons:

There is no clear line of the count of characters. But in practice, IM messages are usually one line. Pidgin even has 2 lines! ;)

The point is, we should find a better solution that works both ways, instead of "making it an option".

I role play via IMs a lot, so I use SHIFT+Enter a lot, and I tend to do over 4 lines of messaging a LOT.

comment:24 Changed 8 years ago by segfault

I'm going back to 2.3.1 because I feel claustrophobic trying to type into that tiny little box.

It bothered me enough that I registered on here to complain.

I think Pidgin is wonderful and I appreciate the developers' hard work, but I feel this "feature" was a mistake. Please let us resize our own input boxes again. I like mine huge, and no, I do not use Pidgin for writing code or emails. Surely there are other things the usability folks can improve.

Thanks

Changed 8 years ago by mlsterben

comment:25 Changed 8 years ago by Oktoplus

This new "feature" ist definitly a drawback. Bring back the option to resize the input field, please!

comment:26 Changed 8 years ago by seanegan

Surely nobody is arguing that the left side of auto-resize-regression.jpg is somehow *better* usability than the right. :)

I think there are actually three things to complain about, and I'd like to sort out which are the actual problems:

  • The maximum size of four lines is too small It seems like this is major complaint? People want to type or copy/paste longer messages and be able to review the entire thing before sending? I think this is a reasonable complaint, and I think we can increase that maximum. (Four lines came about because we just took the code from the status selector which has had this exact behavior since its introduction and, incedently, nobody has ever complained about it :)) How about something dynamic like 'half or three quarters' the height of the window?
  • The default size of two lines is too small I'm not sure anyone thinks this, except maybe the "I feel claustrophobic" comment? I think most people complaining about this are actually seeing a bug where the size starts as zero instead of two lines.
  • The movement of the typing area is distracting or visually jarring This is the complaint I expected to see most (mostly because all the other developers flip out if anything moves a litlte bit :)), but I don't really see that here.

So, would fixing the bug that results in zero-sized input areas for some people plus increasing the maximum from 4 to something greater, perhaps a function of the window height, satisfy this ticket?

comment:27 follow-up: Changed 8 years ago by plmayer

Seanegan,

thanks for your input. I am however still of the opinion that whatever height the input window gets "automatically", it will be the wrong size for some people.

The whole message window is resizeable not only because it is a window, but because requirements of people differ. So do they for the input window. Some people like to send short comments, others may post a fragment of code, while still others want to send excepts of abstracts or papers, or whatever... it doesn't matter. So, same as I can resize the window for Pidgin itself, for Pidgin message windows, or for any other element on my screen (except, mostly, dialogs), I expect to be able to resize this input area to fit my particular needs.

Note that I am not at all against an auto-resize feature or a new default size. But why, exactly, is it such a bad thing to just add the ability for the user to change the relative height of the input area in comparison to the rest of the window by dragging, as it was before? Is there some specific reason for the exclusion of that feature?

Thanks.

comment:28 Changed 8 years ago by Oktoplus

For me, it would not. In fact exactly the three points you listed bother me. It was perfect the way it used to be, so why change it? I totally second plmayer's comment. I can see that for some people the new automatic size is handy, for me it's not. So just leave us an option to disable it.

Thanks!

comment:29 follow-up: Changed 8 years ago by kdorff

No, actually I think people ARE disagreeing with the new feature. The default of two lines is small. When I mouse into the compose box to start typing, two lines it is a small target, especially on high resolution screens. For you, the tiny target is probably great, for me I want to make it an inch or so (whatever size is comfortable for "me"). Every IM client I have tried (MSN Live, Yahoo, Trillian, Pidgin 2.3.1) has the compose window as sizable; the reason is probably because person A wants it tiny and person B wants it big. Maybe person B wants it big so he can review what he is going to send when he types more than "LOL", maybe he wants it big so it is an easy target for mouse into. Maybe he wants it big because he has a big textbox fetish. Why take that away when it is now standard functionality in every other IM client (including Pidgin 2.3.1).

comment:30 in reply to: ↑ 27 ; follow-up: Changed 8 years ago by seanegan

Replying to plmayer:

Seanegan,

thanks for your input. I am however still of the opinion that whatever height the input window gets "automatically", it will be the wrong size for some people.

That's funny. My exact problem was that having to manually change the input area size means that it will almost always be the wrong size, most of the time. Pidgin, right now, knows exactly how much room the input area requires and gives it exactly that much. Why do you think it should give more or less room that it requires (assuming the 4-line maximum is changed)?

The whole message window is resizeable not only because it is a window, but because requirements of people differ. So do they for the input window. Some people like to send short comments, others may post a fragment of code, while still others want to send excepts of abstracts or papers, or whatever... it doesn't matter. So, same as I can resize the window for Pidgin itself, for Pidgin message windows, or for any other element on my screen (except, mostly, dialogs), I expect to be able to resize this input area to fit my particular needs.

Again, this sounds like the complaint is about the 4-line maximum. With that removed, there shouldn't be any difference between you resizing the input area to fit, or Pidign doing so? Rather, if you happen to go one line more than you expected, Pidgin will take care of it, and once your message is sent, you'll have the maximum amount of room to read your incoming messages. Why should you micro-manage the input area to account for the length of every message you send, when Pidgin can do it much better, for you?

comment:31 follow-up: Changed 8 years ago by plmayer

Pidgin, right now, knows exactly how much room the input area requires

From your comments, I assume you are one of the developers, so if the above comment is not ironic this the point where I stop arguing.

I, as the user, know how much space I want for typing into, whatever the reason. How can a software know what kind of message I want to send? It is impossible to guess my mood and wishes.

I can't believe I am having this dicussion at all. To all others in this forum, I wish you good luck.

comment:32 Changed 8 years ago by tmetro

Replying to seanegan:

  • The movement of the typing area is distracting or visually jarring

While I found an auto-resizing input box bothersome (initially it wasn't even apparent that it resized), I've been living with it, and it seems to work fairly well, except for the issue quoted above. (I haven't experienced the bug where the input size is near zero lines.) Text jumping around in the received message pane is indeed quite distracting, as it is indistinguishable from newly received messages. So with each change it grabs your eye and requires reviewing the content to see if what you're typing has become irrelevant by what someone else is saying.

I'm not sure what the solution would be. If you don't scroll the received text, you end up covering up the most recent messages. You could swap the position of the input and received text boxes, such that the expanding input box would encroach upon the older received messages, but that'd be even more jarring for most users.

I agree with seanegan that it is worth the effort to fix the issues he highlighted with this feature, rather than abandoning it entirely, as there are advantages to it, but I also think there should be a setting to revert to the old behavior for those still dislike the new behavior.

comment:33 in reply to: ↑ 30 Changed 8 years ago by jason0x21

Replying to seanegan:

Again, this sounds like the complaint is about the 4-line maximum. With that removed, there shouldn't be any difference between you resizing the input area to fit, or Pidign doing so?

The complaint is, and has always been, about the ability of the user to control something being taken away. This is a feature that many people feel strongly about (the Trac server is apparently sweating under the load). Why is it so hard to say "Wow, we didn't know so many people liked this, we're putting it right back next release"? Why force folks to use the tool in a way they clearly don't want to?

Why should you micro-manage the input area to account for the length of every message you send, when Pidgin can do it much better, for you?

Why is it so dang important to take that ability away from me? What does Pidgin gain by removing this functionality? Make the new way the default, but please bring the old way back as an option.

comment:34 Changed 8 years ago by wheerdam

I just also encountered this new "feature". It makes typing long messages / pasting in code snippets almost unbearable. Request for making this feature optional?

comment:35 Changed 8 years ago by Oktoplus

Seanegan, obviously Pidgin doesn't know which size I prefer for the input area. It's decision differs from my expectation. Fact. I like my input area to default to more than two lines, I guess four lines would suit me. So, it just would be nice, if I could set values for minimum and maximum size myself. Or even better, just give me the option to revert to the old behaviour. The movement of the typing area is indeed distracting, but I think this actually is a feature I might learn to like.

comment:36 in reply to: ↑ 29 ; follow-ups: Changed 8 years ago by seanegan

Replying to kdorff:

No, actually I think people ARE disagreeing with the new feature. The default of two lines is small. When I mouse into the compose box to start typing, two lines it is a small target, especially on high resolution screens. For you, the tiny target is probably great, for me I want to make it an inch or so (whatever size is comfortable for "me").

Ok, this is actually a good point that I've heard before, so I'm gonna bold it (I'm bolding these things so I can easily scan what seem to be the core issues).

People don't realize the entire window is a click target for giving the input area focus

Clicking on the message area and typing has pretty much forever given focus to the input area and typed in there. It's a good point that this is not necessarily easily discoverable, but perhaps it's more discoverable now.

Similar example: when we got rid of the 'Send' button, it turned out that the Enter keybinding is also not obviously discoverable. But typing your message and hitting Enter is way more efficient than typing your message, switching over to the mouse, and hitting a Send button. By removing the Send button, we removed the more obvious feature, but forced people to use the better one. Similarly (but obviously not exactly the same), by making the input area small by default, it's perhaps more discoverable that the entire window is a click target, which makes for a better experience? Maybe?

Every IM client I have tried (MSN Live, Yahoo, Trillian, Pidgin 2.3.1) has the compose window as sizable; the reason is probably because person A wants it tiny and person B wants it big.

Hehe, that's funny. Every IM client I've tried in the past 5 years or so (iChat, Adium X, Google Talk, Gmail) do it this way.

Maybe person B wants it big so he can review what he is going to send when he types more than "LOL", maybe he wants it big so it is an easy target for mouse into. Maybe he wants it big because he has a big textbox fetish. Why take that away when it is now standard functionality in every other IM client (including Pidgin 2.3.1).

Obviously you can still review messages so long as Pidgin has increased the size of the text box appropriately enough. Increasing the 4-line-maximum seems to be the major take-away from this. You do, however make another point:

Some people are white-space fetishists :)

comment:37 Changed 8 years ago by EvilJohn

I agree this feature should be changed to be optional for the user.

comment:38 in reply to: ↑ 31 Changed 8 years ago by seanegan

Replying to plmayer:

Pidgin, right now, knows exactly how much room the input area requires

From your comments, I assume you are one of the developers, so if the above comment is not ironic this the point where I stop arguing.

Of course it knows exactly how much room you need, because you're actually typing into it. You typically don't know before you start your message if it will take up 4 or 5 lines, but Pidgin 2.4.0 will realize when you need that fifth line and make the adjustment at the exact keystroke.

If you disagree that Pidgin knows exactly how much space you need (which you seemingly do), you must think that for some reason it requires empty, blank lines of whitespace. Why?

comment:39 follow-up: Changed 8 years ago by Oktoplus

Replying to seanegan:

People don't realize the entire window is a click target for giving the input area focus

Thanks for this information, I didn't know this. Might be because clicking on the message area puts the cursor there, so you have no clue the input focus is actually in the input area.

comment:40 in reply to: ↑ 39 Changed 8 years ago by seanegan

Replying to Oktoplus:

Replying to seanegan:

People don't realize the entire window is a click target for giving the input area focus

Thanks for this information, I didn't know this. Might be because clicking on the message area puts the cursor there, so you have no clue the input focus is actually in the input area.

The focus doesn't go to the input area until you start typing, so you can still do stuff like mousing around, copying and pasting in the message area, but once you start typing a message, it does to the input area.

comment:41 Changed 8 years ago by kdorff

Replying to seanegan:

.. you must think that for some reason it requires empty, blank lines of whitespace. Why?

Conversely, you suggest we shouldn't WANT empty blank lines of whitespace. I appreciate that I can just click on the window and start type (that is great and I did NOT know that, thanks for letting me know). Some of us white-space fetishists like it there. It makes us feel warm and fuzzy and the proportion may feel more balanced when we can set it. I like my meat up front of the plat and my veggies in the back, but you may mush them all together. Some people freak out when their food touches. I really loved the ability to set the size of the thing to what felt right for me. In 2.4 the window looks wrong and the "growing" seems odd to me.

comment:42 follow-ups: Changed 8 years ago by deryni

To be fair the entire window isn't a click target for the input area, the entire window is a typing target for the input area, that is a large distinction. If clicking caused the focus cursor to move to the input area it would be largely more discoverable. (I haven't read anything beyond Sean's last post yet.)

I would like everyone in this thread who posted in favor of reverting the change or adding an option to comment on whether being able to specify a minimum number of lines and allowing the area to expand to one half (or two thirds) of the history area would be an acceptable solution.

comment:43 in reply to: ↑ 36 Changed 8 years ago by Oktoplus

Replying to seanegan:

Similar example: when we got rid of the 'Send' button, it turned out that the Enter keybinding is also not obviously discoverable. But typing your message and hitting Enter is way more efficient than typing your message, switching over to the mouse, and hitting a Send button. By removing the Send button, we removed the more obvious feature, but forced people to use the better one.

Well, regarding that one... What about me being lazy and just dragging a link from Firefox with my mouse? Then I need to get my hand off the mouse and press Enter. An option for a send button would be nice, too ;) You see: Different users, different needs.

comment:44 in reply to: ↑ 42 Changed 8 years ago by segfault

Replying to deryni:

I would like everyone in this thread who posted in favor of reverting the change or adding an option to comment on whether being able to specify a minimum number of lines and allowing the area to expand to one half (or two thirds) of the history area would be an acceptable solution.

So I'd have to play around with numbers until I find the right size? Compared to just dragging out the text box to the desired size, that sounds way too complicated.

comment:45 Changed 8 years ago by deryni

segfault: You need to play around to figure it out? You don't know how many lines you want it to be? I'm talking numbers in lines not pixels.

comment:46 Changed 8 years ago by deryni

Oktoplus: The right-click menu has Send as the top item for a reason.

comment:47 in reply to: ↑ 42 Changed 8 years ago by jason0x21

Replying to deryni:

I would like everyone in this thread who posted in favor of reverting the change or adding an option to comment on whether being able to specify a minimum number of lines and allowing the area to expand to one half (or two thirds) of the history area would be an acceptable solution.

Not really, I like being able to arbitrarily resize it on a whim. I fail to see anything wrong with that desire (and I'm not alone there), and am still confused as to what is gained by removing the feature.

comment:48 Changed 8 years ago by deryni

Oktoplus: The right-click menu has Send as the top item exactly because people who didn't like the removal of the Send button showed up and calmly and coherently explained to us that the button was incredibly useful when copying and pasting text with the mouse, at which point we discussed with them ways to satisfy them without adding the button back. It is exactly discourse of that sort that we are looking for now.

comment:49 follow-up: Changed 8 years ago by deryni

jason0x21: The gain from our removing the manual resize ability was the fact that the automatic resizing could work with significantly less problems, problems that people were complaining about. There is nothing wrong with the desire to want to do that, but desire based on nothing is a poor reason to complicate and support extra code, especially if the current mechanism can be made to suit. Why do you arbitrarily resize the input area? Are there times you need to do that specifically? Or do you just like to do it because you can?

comment:50 in reply to: ↑ 49 Changed 8 years ago by jason0x21

Replying to deryni:

jason0x21: The gain from our removing the manual resize ability was the fact that the automatic resizing could work with significantly less problems, problems that people were complaining about. There is nothing wrong with the desire to want to do that, but desire based on nothing is a poor reason to complicate and support extra code, especially if the current mechanism can be made to suit. Why do you arbitrarily resize the input area? Are there times you need to do that specifically? Or do you just like to do it because you can?

So removing manual resizing makes automatic resizing work better? Or were there problems specific to manual resizing (and only manual resizing?). Because I've said before: make automatic a default, with an option to return to manual only. It's pretty clear there aren't any people who want both at once.

I don't feel like I need a reason other than "This is the way it worked before, and I really liked it." That's why they're called "preferences" after all. This is IM, and nobody's doing mission-critical work with IM. Likewise, the developers don't need a reason to add functionality. We're all happy to try new functionality. However, when stuff is _removed_, there needs to be a clear reason why it simply can't be made to work anymore.

It should be obvious to most of the devs now that people are clamoring for manual resize back, and no amount of "you need to provide a use case" is going to shut them up. It's because they're not wrong to want it back. In fact, demanding a use case for a preference is kind of rude (can anyone really justify why they need "bold" fonts?) I know that many of the messages were harsh in the beginning, but I'd wager that most people who saw it went first to the preferences pane to try and make it work the old way (I know I did).

comment:51 follow-up: Changed 8 years ago by swbrown

This bug is getting off track. Essentially, the key problems with the implementation:

1) It doesn't expand large enough for the way many of us use pidgin.

2) The repeated re-layout of the response pane is visually jarring.

Both are solved by allowing the user to set a constant size, which was what we had in 2.3.

comment:52 in reply to: ↑ 51 Changed 8 years ago by Oktoplus

Replying to swbrown:

This bug is getting off track. Essentially, the key problems with the implementation:

1) It doesn't expand large enough for the way many of us use pidgin.

2) The repeated re-layout of the response pane is visually jarring.

Both are solved by allowing the user to set a constant size, which was what we had in 2.3.

Full Ack

comment:53 follow-up: Changed 8 years ago by tkl

Reclarifying my prior statement, the exact thing I do not like this change has to do with both "the movement is of the typing area is distracting or visually jarring" and desktop window layout. When I originally stumbled upon Gaim, it solved all my problems by providing a stable messaging client as well as fitting well into my desktop layout for Linux. I use Pidgin to communicate with various administrators around campus on a daily basis.

Having the screen "jump" or resize internally is very eye catching. When that happens, I know that some event has taken place I should review which would catch me when it scrolled upward as I typed. This caught my eye every time it scrolled upward. That's pretty much it in a nutshell for the distraction part.

As for window layout, I am a left-side tab user for communication tabs. I've already taken a hit from pidgin 2.2.1 -> 2.3.1 of losing abbreviated tab identifiers. Now from 2.3.1 -> 2.4, I lost the ability to resize the message input.

Combined together, this makes my desktop look like this if someone contacts me directly: http://www4.ncsu.edu/~tkl/pidgin/desktop1.jpg to this when someone sends me an IM from an already existing chat: http://www4.ncsu.edu/~tkl/pidgin/desktop2.jpg

Now you should understand why I want to resize the text input window -- because when I could, I could make up for not being able to have abbreviated tab identifiers by causing the window to reformat slightly so as not to be so cramped into one small typing space. I would like to trade the wasted non-abbreviated space for typing space.

So I guess in essence, I either want abbreviated tabs or the ability to resize the internal window components back.

comment:54 Changed 8 years ago by Tenchan

As per request, I post again:

No, I do not find it an acceptable solution to take control away from the user when clearly the user wishes to have this control back. Personally, I resize my text area fitting to my current need of the messenger as well as my current desktop layout. There are, for example, times when I have multiple windows open side by side during my workflow, yet I still need to be able size my input box in a way that benefits me and does not distract from my focus. A set value cannot anticipate such factors (yes, this also includes the area being too big, not only too small).

Note: I also find the attitude of certain people (who I will not name) in this 'thread' increasingly condescending and offending. I am well aware that Pidgin is a free software and as such, the developers are under no obligations to cater to their users' wishes, but I cannot imagine that making the user feel as if they are, to be frank, too stupid to know how to use their Instant Messenger 'properly' is in the teams' interest.

comment:55 follow-up: Changed 8 years ago by kepplah

1) Allow manual resize.

2) Allow automatic resize disable setting.

3) Min and max size settings.

Would this not make everyone happy? Should you bundle it as a plugin so you can urge people to do it your way, and allow those who disagree their way as well?

comment:56 in reply to: ↑ 53 Changed 8 years ago by seanegan

Replying to tkl:

As for window layout, I am a left-side tab user for communication tabs. I've already taken a hit from pidgin 2.2.1 -> 2.3.1 of losing abbreviated tab identifiers. Now from 2.3.1 -> 2.4, I lost the ability to resize the message input.

That tab thing is a bug. Can you open a new ticket, and include your GTK+ version number? 'pkg-config --modversion gtk+-2.0'

comment:57 follow-up: Changed 8 years ago by deryni

jason0x21: Yes, it proved to be impossible to get both manual sizing and automatic resizing to work at the same time. We are trying to figure out if there is a way for the current mechanism to be usable by everyone, because that would be a *better* answer than simply adding a preference.

You don't need a reason beyond that to want it, you do need a reason beyond it to convince us that adding the preference is the only solution. Which is exactly why I keep asking for reasons. I'm more than happy to give in to them when they are given and reasonable.

If harse messages were limited to the beginning rush this would be a significantly more palatable discussion, but calling us and our questions rude isn't exactly not harsh.

swbrown: Both of those are also solved by my suggestion, so thank you.

tkl: If you are actively typing in the conversation window enough that you are typing more than two lines are you not going to notice new messages anyway? What about the movement from the typing causes you such problems in that case? When you aren't in the window there is no jumping other than remote typing and new messages, so I fail to see what your point here is.

Tenchan: Under what circumstances do you find yourself resizing the input area? Are there no guidelines for this which could be handled automatically? What if we let you specify a default size in percent of the window height?

I haven't read the entire thread but in what I have read I didn't see anything condescending, so I apologize for wherever you did see it but suggest that perhaps you are misreading things.

kepplah: The question is whether anyone actually needs manual resizing or whether auto sizing (with some modification, like what I suggested before) can be made to work for everyone. A solution which is a modification of the current behaviour is significantly simpler for everyone than is adding an option back, especially if we can reasonably avoid doing so.

comment:58 in reply to: ↑ 57 Changed 8 years ago by kepplah

Replying to deryni:

kepplah: The question is whether anyone actually needs manual resizing or whether auto sizing (with some modification, like what I suggested before) can be made to work for everyone. A solution which is a modification of the current behaviour is significantly simpler for everyone than is adding an option back, especially if we can reasonably avoid doing so.

Understood. Simply keeping the text area open with 1 or 2 lines height when I've not typed anything would solve my issues with this change. My main gripe is while I'm now aware I can type with the history box active, this doesn't seem intuitive and logical. When I first opened the app after the update I was confused, thought there was a bug, and that I would be unable to chat because the text area was 5 pixels high and I could not target the box by mouse.

comment:59 Changed 8 years ago by deryni

kepplah: A text input box that is *not* always at least two lines high *is* a bug, and one that we know about and just tracked down earlier today. Turning off hiding new IM windows or the formatting should 'fix' it.

comment:60 Changed 8 years ago by thwarted

While the ability to click anywhere on the window will allow you start typing in it, this doesn't work for pasting (control-v appears to be unreliable unless the input area has focus), and a right-click anywhere shows the context-dependent menu (which is based on the widget, the conversation pane is non-editable, so the paste option is greyed out) and the input area must still be clicked to get the paste option to work. As outlined previously, a smaller input area makes it harder to target with the mouse for clicking.

Additionally, I vote for returning the ability to resize the input area using a drag handle. Have it limited to resizeing on a per-line basis (which may not make sense given the ability to change the font-size), and don't allow it to be smaller than one line or large enough that less than one line of the conversation pane is shown.

Changed 8 years ago by kepplah

Text input box behavior

comment:61 Changed 8 years ago by kepplah

Oh, this is not the desired functionality? (See my screenshot) No wonder I'm confused. Can you explain how to correct this or point me to the right url?

comment:62 Changed 8 years ago by swbrown

deryni: I don't see how your solution eliminates re-layouts of the response pane during a conversation. If it can expand, it can cause a re-layout, correct?

I'm not sure if the original intent of this change is optimizing the right problem. Is it more important to maximize the response pane or have the UI not contributing to visual noise during the conversation? I've not felt restricted by the size of the response pane, so the only thing to optimize in my case is to keep the UI from changing sizes. This is how 2.3 worked.

comment:63 Changed 8 years ago by Tenchan

A percentage value may work, as it is specific enough to avoid all too much whitespace or all too much 'cramped' space. I admit I hadn't thought of that idea.

(As an example, I am an artist/designer and often find myself working on a canvas that needs to be resized repeatedly, due to its very nature. If don't want to have to interrupt my workflow to alt-tab, I have to resize the IM window accordingly, and can end up with an all too tiny input area.)

comment:64 follow-ups: Changed 8 years ago by deryni

swbrown: My solution 'eliminates' re-layouts in that it allows people to set the size to the maximum size they normally use and then never hit the resize limit again. The difference is that instead of creating scrollbars if they do hit it it does the much more friendly thing of expanding temporarily to allow them to see that little bit extra for a minute. Do you think that is a bad thing?

Not requiring people to resize the input area when they type a slightly longer message than normal is a good thing, not requiring people to resize the input area in that case is also a good thing, not requiring people to keep a large input area to avoid the need to scroll or resize is a good thing. The question here isn't about feeling restricted it is about letting people get an input area that just works for them and doesn't need them to resize or scroll constantly. (Which to jump back a second my solution allows for significantly more people than the current solution and is why I suggested it and am planning on implementing it.)

I see no benefits to going back to manual resize only that my suggested solution doesn't have other than for the people that resize simply because they can. Do you? Can you elaborate on them?

comment:65 Changed 8 years ago by deryni

I would like to take a moment to thank the majority of the people still posting to this ticket for the polite and coherent way in which this is being discussed and for the willingness to think about modifications that might suit them.

comment:66 Changed 8 years ago by swbrown

deryni: I see scrollbars appearing in an area being edited when necessary to be preferable to an area being visually monitored for change changing when there is no change in that area due to the re-layout. It keeps visual change restricted to where change is actually occurring.

comment:67 Changed 8 years ago by mlsterben

All I want to know is why this has become a debate. We users should be able to choose whether we want the automatic resize or the old "make your own comfortable size" option.

comment:68 Changed 8 years ago by deryni

swbrown: If you are already looking around the history area because you are typing a new IM message then you shouldn't need to be 'visually monitoring' it for changes as you are almost actively looking at it. If you aren't already looking at the window then the input area size changes can't cause it to change size as you can't be typing into the input area. I'm really not at all sure what scenario you are talking about where the auto-resize is a problem the way you are stating.

comment:69 in reply to: ↑ description Changed 8 years ago by dave314159

One of the reasons I like Pidgin (though certainly not the most important) is that it is visually appealing. If I am going to have to look at this thing for many hours a day, I want it to look the way I want it to look. For this reason (along with other, more practical considerations mentioned above) I think the percentage-based solution seems to be the best.

One point that I'm not sure has been addressed here is that even if said solution is implemented, people like their manual drag-handles. Setting a numerical percentage in a preferences pane is simply less intuitive.

Perhaps we can have our cake and eat it too. I picture it like this: you open up your IM window for the first time, and it looks like it currently does (in v2.4) with a two-line mininmum. If you want to change the minimum size of the input area, you right click on the input-area menu-bar and select something to the effect of "resize input area." This would allow you to adjust the size manually. Since Pidgin would only ever have to pay attention to such resizing in that one instance, it seems to me that it wouldn't (or would at least be less likely to) interfere with the auto-resizing.

As for those of us who simply can't stand the auto-resizing, this seems like the perfect place for a plugin (albeit one crafted carefully in consultation with the pidgin devs to make sure it doesn't break anything important in the process.)

comment:70 Changed 8 years ago by kdorff

If you really hate the idea letting us set the size with a spliter, how about an option of "minimum" and "maximum" number of lines for the auto-expansion. Currently the values are 2/4, I believe. I could set it to 8/8 and when it when past it wouldn't grow and I would have the larger area I like (and hopefully a scrollbar would appear). Some might like 8/16, some 1/24. If this has already been proposed, I apologize for repeating the idea.

comment:71 Changed 8 years ago by deryni

kdorff: That is rather similar to what I've been suggesting this entire time, except I don't think setting a maximum is necessary, either you don't hit the maximum or you do and I still think being able to see that extra line for a moment is better than the scrollbars.

comment:72 in reply to: ↑ 55 Changed 8 years ago by Gookey

Replying to kepplah:

1) Allow manual resize.

2) Allow automatic resize disable setting.

3) Min and max size settings.

Would this not make everyone happy? Should you bundle it as a plugin so you can urge people to do it your way, and allow those who disagree their way as well?

The ability to disable the automatic resize will satisfy me. The point was raised that having manual sizing played hell with automatic resizing. What if manual sizing is disabled when automatic sizing is enabled?

I think that the set number of lines and percentage solutions to not satisfy all cases. Dealing with whole lines of text for spacing can sometimes get mucked up with using a shift+enter in the entry pane because of how the paragraph break spacing is different from the automatic line break. Also, and this is strictly a personal taste thing, I feel like seeing the fractions of lines of text is more natural for a scrollable window.

Similarly, the percentage setting may be inadequate for a situation where someone sets the percentage because they like how much space the input field takes up (not merely the ratio), and then they maximize the chat window. The input field would expand to match the ratios, and then appear "too large" for what the user wanted.

Finally, as dave314159 mentioned, the hard and fast line counts and percentages can be unintuitive compared to the drag handle. While the intuitiveness can be addressed by having the drag handle go to line numbers and percentages in the back end, updating the preference values behind the scenes, this wouldn't address the other issues I have pointed out.

Personally, I think 2.3 handled the window maximizing great, by expanding the chat area, and leaving the input area the same size.

This problem of automatic resizing, along with one that I think is a bug with the new version of GTK+ has led me to revert to 2.3.1.

As for responding to seanegan's post from 03/04/2008 12:38:11 PM, I find the minimum size too small for my taste (aesthetics are tricky; call me a white-space fetishist if you wish) the maximum size too small if I wish to read over a lengthy message before sending it, and the auto-resize is visually jarring. What I see happening is action strictly within a text area is now affecting the window as a whole. That, I find bothersome, and I believe many others feel that as well.

comment:73 in reply to: ↑ 36 Changed 8 years ago by badman

Replying to seanegan:

Replying to kdorff: Hehe, that's funny. Every IM client I've tried in the past 5 years or so (iChat, Adium X, Google Talk, Gmail) do it this way.

i currently use adium on my laptop and like the way that they implemented this same feature. the input box starts as a single line and will expand to hold any length of text. with v2.4 of Pidgin, the way the auto-resizing is handled looks clunky and makes the interface not seem to function properly [imho]. (see: pidgin-inputtext.PNG). the function should stay, it just needs to be adjusted to work better.

comment:74 Changed 8 years ago by deryni

badman: The interface as presented in that image is a bug, and has been acknowledged as such in this thread already.

comment:75 in reply to: ↑ 64 Changed 8 years ago by tmetro

Replying to deryni:

Not requiring people to resize the input area when they type a slightly longer message than normal is a good thing...

Yes, but marginally so. I set my input box size probably a year or more ago and haven't needed to touch it since. Occasionally I exceed the size of the box, but the consequences of scrolling aren't even enough of a negative to motivate me to adjust the box size.

The only benefit to me of the auto-resize mode is that it permits having a slightly smaller default input size, which permits more received message text to be viewed. But 30% or more of the messages I send trigger a resize, and that leads to a negative (see below) behavior, which outweighs this advantage.

I see no benefits to going back to manual resize only that my suggested solution doesn't have other than for the people that resize simply because they can.

Yes, there is the major benefit of eliminating the jumping text in the received message pane. Unless a solution is found for that in the auto-resize mode, the advantages of the auto-resize mode don't outweigh the negatives.

comment:76 follow-up: Changed 8 years ago by deryni

Gookey: "What if manual sizing is disabled when automatic sizing is enabled?" is exactly what we have now and what people are complaining about, simply allowing manual resizing again doesn't fix any of the problems people have had with the auto-resizing code and that is something I can not accept. The current code *needs* fixing, if after all that fixing it is still not acceptable to some people adding the option (or writing a plugin, or some other solution) can be considered.

I was unaware until earlier this afternoon that wrapped line spacing is different than inter-paragraph spacing, and I fully admit that this complicates the sizing more than I would like. I am still hopeful that this can be worked around cleanly, but that will need to be tested, guessing in either direction is not an answer.

If a person sets a percentage then they are indicating that should they maximize the window they *want* the input area to grow to fill the same percentage, if they don't want that they should use a number (we could consider capping the percentage at some large number of lines but I think that is just asking for confusion and annoyance). Given that ideally both line counts and percentages would be allowable I think your argument here doesn't really hold up.

Yes, I am aware that line counts and percentages are significantly less immediately obvious than dragging a handle but I think the cost is worth it.

2.3.x didn't handle window maximization at all, or if you want to call "by expanding the chat area, and leaving the input area the same size" handling it then the current 2.4.0 code handles it exactly the same way. As would my suggestion with a minimum line count. So I don't really see your argument here.

My suggestion alleviates the first two parts of your response to Sean intrinsically and properly set up avoids the visual "jarring" in all but the exceptional cases where you go over your self-defined line count.

comment:77 Changed 8 years ago by deryni

tmetro: The whole point of my suggestions for changes to the autoresizing code is so that you can do exactly what you used to do only instead of running into scrollbars when you go over you get the (even just marginally) better action of expanding. The point is not to allow you a smaller input size then you want if you find the resizing annoying, it is to allow you a smaller input size when you want to waste less space and see more history when you don't mind the resizing and avoid the resizing (basically) entirely when you don't want it by picking a default size that suits you.

By "jumping text in the received message pane" I'm assuming you mean the fact that you find the history area moving to cause you to scan it for new messages? If so, while I don't find that a problem myself (I suppose I rarely talk to people who negate a message I am typing, one that is longer than two lines mind you, by a new message), I can see how it would be annoying and welcome any thoughts on how to mitigate the problem. The only thought I have at the moment is a method I ran into while looking up javascript stuff at work a couple weeks ago known as (among other things) the Yellow Fade Technique[1] which is essentially a fading highlight on changed text. This would mean that new IMs would get a fading background/foreground/etc. highlight and text moved by the auto-resize stuff would not. I don't know if that would help (or even if it is really possible at the moment) but it is the only thought I have currently.

[1] http://www.37signals.com/svn/archives/000558.php

comment:78 Changed 8 years ago by dave314159

What if the history were to smoothly scroll instead of "jumping" when the input area auto-resizes? It would make the bottom line of history text unreadable for a fraction of a second, but it might alleviate the visual "jarring" that bothers some people. That, and it'd be kinda cool.

comment:79 follow-up: Changed 8 years ago by Minimalist360

Is there a ticket for this:

  • The default size of two lines is too small I'm not sure anyone thinks this, except maybe the "I feel claustrophobic" comment? I think most people complaining about this are actually seeing a bug where the size starts as zero instead of two lines.

I definitely have this problem with the zero lines. It was mentioned above, but I can't find another ticket for this. Is there a workaround? I get this 100% of the time on new windows.

comment:80 in reply to: ↑ 79 Changed 8 years ago by kdorff

Replying to Minimalist360:

  • The default size of two lines is too small I'm not sure anyone thinks this, except maybe the "I feel claustrophobic" comment? I think most people complaining about this are actually seeing a bug where the size starts as zero instead of two lines.

I think everyone here realizes the zero lines is a bug, nobody believes for a second that the zero lines was an intended "feature". The discussion here (see the title of the bug report) is if two lines are enough and if the compose pane should auto-size or be manually sizable. ALSO, if it is auto-sized is the only option, is two lines an adequate starting point.

Personally, I don't like the tiny starting height of two lines - maybe it's claustrophobia or maybe it's personal aesthetics. I have asked to either be able to set the minimummaximum height of the auto-size or have the manual-size be returned.

comment:81 Changed 8 years ago by deryni

Minimalist360: Do you have both hiding of new IM conversations turned on and the formatting toolbar turned on? If you do try turning one or both of them off, that seems to fix the problem for people who are hit by the bug in that way.

comment:82 follow-up: Changed 8 years ago by rfgiusti

I'd like to register my complains about this new feature.

I'm smart enough to configure my own preferences: I don't like when applications change my personal preferences. I like to have a large input field for IMming and I don't feel good about the application forcing me to accept the developers' standard of look & feel.

I'm used to the old resizeable input area: I don't know why Pidgin has been changing so much, but that's annoying me. Do you want to improve Pidgin? Great! Thank you for the great effort in making Pidgin better. But let us choose whether we'd like to change to the new exciting features or stick to the old ones.

The four lines limit is arbitrary: why four lines? Who said that's a reasonable limit? I strongly disagree. That's not how I use IM.

Pidgin is not for short messages, it's for IM: who said I should write short messages with Pidgin? Even MSN, the most crippled IM protocol ever, allows me to write nearly 1KB of text! That's not short.

The resizing feature is distracting and buggy: when the input area resizes, it changes the height of the last received/sent message and also the number of text lines shown in the conversation window. That's distracting and annoying. Not to mention that, often, the input area resizes (in my installation, but I won't open another ticket) even thought no text liens have been added.

Because of all that, I would like to be able to deactivate that feature and stick to the old behavior.

comment:83 Changed 8 years ago by quoderat

This new "feature" has made me start looking for a new IM client. One of the reasons I switched to Pidgin was the ability to manually resize the text input window. It's removal leaves me unable to use Pidgin, as I tend to send long messages (no, I don't send code, and no, e-mail would not be better).

Please revert to the old behavior. It is much-preferred by me and everyone I've talked to.

Why:

1) I want to control what Pidgin does, not have Pidgin control what I do. This is why I also run Linux.

2) It makes it hard to type longer messages; I prefer the white space as the window looks better this way.

3) It's distracting when the text re-flows.

4) This new "feature" is a usability travesty in every way imaginable.

comment:84 Changed 8 years ago by cablecarfanatic

I agree with those who want this changed back to the 2.3 behavior, or at least make it optional. I find it hard to use Pidgin at this point. I send lots of longer messages, and I like to be able to control what's happening.

I just hate when developers take away features so many people use. And want.

comment:85 Changed 8 years ago by Apewall

I don't want my input box changing size without my explicit permission, nor do i want it encroaching up into my conversation.

This new behavior is fine for users who want confined and small chat boxes, but Pidgin should memorize if the user has edited the size of the input box like it has always done.

Basicly, we need to combine this new functionality with the old.

comment:86 in reply to: ↑ 76 Changed 8 years ago by Gookey

Replying to deryni:

Gookey: "What if manual sizing is disabled when automatic sizing is enabled?" is exactly what we have now and what people are complaining about, simply allowing manual resizing again doesn't fix any of the problems people have had with the auto-resizing code and that is something I can not accept. The current code *needs* fixing, if after all that fixing it is still not acceptable to some people adding the option (or writing a plugin, or some other solution) can be considered.

What I was going for was a double implication. Yes, Pidgin currently disables manual resizing when auto-resizing is on. What I meant to also hit on was that if auto-resizing is off, turn manual resizing on. Basically, the two behaviors are mutually exclusive, and that is a problem of the complexity of the management code for auto-resizing. I'm okay with turning one off, in order to reap the benefits of the other, and vice versa.

If a person sets a percentage then they are indicating that should they maximize the window they *want* the input area to grow to fill the same percentage, if they don't want that they should use a number (we could consider capping the percentage at some large number of lines but I think that is just asking for confusion and annoyance). Given that ideally both line counts and percentages would be allowable I think your argument here doesn't really hold up.

I admit that my argument may not hold up. I was going from the assumption that it was an either/or situation.

2.3.x didn't handle window maximization at all, or if you want to call "by expanding the chat area, and leaving the input area the same size" handling it then the current 2.4.0 code handles it exactly the same way. As would my suggestion with a minimum line count. So I don't really see your argument here.

That was what I was going for. Yes, 2.4 handles window-maximization the same way as 2.3.x, but I was working again from the assumption that the proposed percentage/line count solution would be one or the other, i.e. it would either be always a percentage, or always a line count, not leaving it up for the user to decide. I think I'm a little bit more on board with your idea now that I realize that it could be one or the other. If we throw in the ability to have the line count allow fractions of lines (like: 4.2 lines of text shown), I'd sign on completely. If we're combining multiple measurements, a pixel count would be even better IMO than the floating point line count, as then you could possibly avoid some of the font-scaling math, and sidestep the difference in line heights when a crlf is inserted, vs. line wrapping.

My suggestion alleviates the first two parts of your response to Sean intrinsically and properly set up avoids the visual "jarring" in all but the exceptional cases where you go over your self-defined line count.

My problem with the visual jarring isn't the addition of the scroll bar, it's the effects of actions in a sub-area of the window affecting the window as a whole. The scrollbar appearing a la 2.3.1 is fine for me, as it only affects the text area in which I am typing, as opposed to the window as a whole.

comment:87 Changed 8 years ago by Doodle77

I'm very annoyed by this 'feature' too. Having the bottom of the conversation move up simply because you are typing a long message really irritates me. At least add an option to go back to the old behavior.

comment:88 Changed 8 years ago by K@…

Well thank you very much William "It's Not A Bug It's A Feature" Gates. Is Pidgin now in the hands of M$ developers?? And that "It doesn't bother me so screw the rest of you guys" attitude should be tarred & pidgin-feathered. The theory of "keeping the application useful" is absolute rubbish since the new version has rendered MY Instant Message window anything but. And the IM nannies that say we shouldn't be typing more than a line anyway because that's what email is for can suck it too 'cuz I would relish being limited to a couple of lines considering I don't even have a SINGLE full line of text to type in. In this build the only time I can see what I've typed at all is AFTER I've sent the message. Is this the "usability feature" you guys are patting yourselves on the back about? Careful not to break your arm there, chief.

I'm a relatively new user to Pidgin and haven't had any problems until now but the process of registering an account just to complain (like so many others here) was like pulling teeth in itself. After trying the initial search on the issue then actually registering & leaving a reply (4 times in between errors) I've wasted over an hour of my life now staring at Server Overloaded error pages referencing a high load on the server! Hmmmm...I wonder why the server for technical support would be overloaded...oh yeah, all the people who upgraded are on it trying to figure out how to disable the new "Enhancement"!!!

Back to Trillian for me. In the number of years I've used & upgraded that nice little application it has never NOT worked. If it ain't broke DON'T FIX IT!!!

comment:89 Changed 8 years ago by mlsterben

QFT

comment:90 Changed 8 years ago by quoderat

REMOVED DEFACING SPAM

comment:91 Changed 8 years ago by mlsterben

tldr, but I always thought it was the developer thinking he/she/it knows better than the user, when it is the user that ends up suffering.

comment:92 follow-up: Changed 8 years ago by end-user

add my vote; needs to be fixed or configurable.

comment:93 in reply to: ↑ 92 Changed 8 years ago by Niomar

Regardless if you like or dislike this "feature", it should be optional so that it suits everyone's needs. There is no reason not to offer it as such. I'll be dropping back a version until this is resolved.

comment:94 in reply to: ↑ 82 Changed 8 years ago by grassmonk

I agree with all of the points made by rfgiusti. I have been using Gaim/Pidgin? for the last 5 years or so, on both Windows and Linux, and have had zero problems until now.

However, the new auto-resize behavior drives me absolutely crazy. I routinely send longer-than-4-line messages to people, e.g. code snippets, quotes, etc. I don't mind scrollbars if I paste 100 lines into my, say, 20 line input area, and I also don't mind if I only type two characters into that same 20 line input area. I want a fixed size, and I want it to be as big or small as I choose.

As others have pointed out, why can't auto- and manual-resizing be mutually exclusive? Let auto-resizing be the default, but let me turn it off if I want to. If the old behavior of dragging the text area to my preferred size cannot be restored, why not the the ability to set a min/max number of lines for the input window, instead of the hard-coded 2/4 values (or even a min/max percentage)? Whatever the solution may be, I don't want the input area to auto-resize, ever.

comment:95 Changed 8 years ago by DidierG

I use Gaim/Pidgin? on both Linux (Fedora) and Windows since years and I just created an account on this site today...

Why ? Because as explained in many messages in this thread before this one, the new auto-resize features is a regression for me and Pidgin is less friendly with this feature.... I suggest to restore the old behavior or at least let the choice to the user....

comment:96 Changed 8 years ago by Haabda

Please give back the resize functionality. The automatic resizing is terribly annoying. When I first installed 2.4 I thought something was wrong or I had accidentally disabled some plugin. After awhile, I came to post a bug report but was distressed to find that it was actually intentional. I have gone back to 2.3 because 2.4 is unusable for me in its current state.

comment:97 Changed 8 years ago by ConnorBehan

I completely agree. I know you think automatic resizing is a fancy new feature but quite honestly it's stupid. We are smart enough to resize the window to a size that we like and it works alot better that way. Give us our resizing freedom back!

comment:98 Changed 8 years ago by ConnorBehan

Also I am getting really sick of opening a new chat window and seeing a 4 line input box appear for a split second and suddenly shrink down to a 2 line input box. It hurts my eyes. The old way better be available in the next version. Otherwise you are no better than closed source developers.

comment:99 Changed 8 years ago by Gookey

Ethan Blanton posted in the Pidgin news feed on this very controversy. Perhaps it goes a little farther to explain why developers are asking why the old way is good. I came back from reading it with a little more perspective though my original opinions are intact.

comment:100 Changed 8 years ago by alopecoid

I'm amazed at what I'm reading here.

I have been using Pidgin since day one, and Gaim many years prior. I have never needed to log a bug/comment because whenever something came up, I would find that the developers were already aware of the problem and on their way to fixing it.

This "feature" may have had the best of intentions, but has had two unarguable results...

  1. It resulted in a bug. Look at the image that "kepplah" attached (http://developer.pidgin.im/attachment/ticket/4986/pidgin-inputtext.PNG). Look at the two windows on the left of the image. That is exactly how my instance of Pidgin looks. Come on. If one can't admit this is a bug, then they are just being stubborn. I can't even see the input message I am typing because it smaller that the height of one character. And I use a small font size.


  1. The decision to not allow users to resize the input text area did not sufficiently take into account the way that people use this product. Just one example is... yes, like it or not, developers/programmers use Pidgin to paste little code snippets to each other. Because it is easy. In fact, in a professional work environment, I would go as far as saying that this is one of the most widely used use cases of an IM program. I would even bet that the Pidgin developers themselves have used it in this way. Now this is just one example of why someone would want to be able to resize their input text area. It should be obvious from the amount of people posting about this that there is an actual need for this ability, and to deny users this ability for no good reason... is going to do nothing but loose users.


Thanks for creating such a useful product over the years.

comment:101 follow-up: Changed 8 years ago by suncho

Please bring back the resizing functionality.

The box might grow on demand, and still be resizable. There could be a preferences option - "allow grow on demand". Please, increase the growing limit of 4 lines.

comment:102 in reply to: ↑ 101 Changed 8 years ago by jruthenberg

+1 for making the new behaviour optional in some way. It's a window, why shouldn't we be able to resize it as we like? This has been possible for quite some time, people got used to it -- what is the point in removing functionality?! Make it a plugin if you must.

comment:103 Changed 8 years ago by edgy

This change was actually the first thing I noticed and vocally complained about after installing/using 4.2.0. I've been following this ticket, optimistically waiting to see that the old behavior would be restored or put on the roadmap for the next version. But the response from the developers has me scratching my head, this makes no sense... where does this tyrant like attitude come from - why not just put the resize option back? It's what your users want. Isn't that the point, to delight your *users*? Kinda makes you wonder where this mandate comes from. But anyhow, the sentiment in this thread just leaves a bad taste. Having been a gaim user for many years (and for many reasons) and like many others I too created an account simply to express how crappy this new functionality is, express my disappointment in the developers' attitude, and to say I'm looking elsewhere to other clients as a replacement going forward.

comment:104 in reply to: ↑ 64 ; follow-up: Changed 8 years ago by suncho

I see no benefits to going back to manual resize only that my suggested solution doesn't have other than for the people that resize simply because they can. Do you? Can you elaborate on them?

Actually, auto-resizable input window is a Good Thing.

I would suggest that the main problem is the 4 lines limit for auto expanding. Some users did not want to have scroll bar in the input area, that is why they used manual resize in the first place. If you increase the limit to 16 lines, probably 99% of users will be happy, and the dreaded scroll-bar would never appear again :)

What was the reason for choosing 4 lines as expand-limit?

comment:105 in reply to: ↑ 104 Changed 8 years ago by rfgiusti

Replying to suncho:

I would suggest that the main problem is the 4 lines limit for auto expanding. Some users did not want to have scroll bar in the input area, that is why they used manual resize in the first place. If you increase the limit to 16 lines, probably 99% of users will be happy, and the dreaded scroll-bar would never appear again :)

I disagree.

You see, the rease why I use a large input area is not the scrollbar. I don't mind the scrollbar showing up, as long as it's showing up all the time! The problem for me is that when the scroll bar pops up, it forces the input area to render all the text again, and the movement of the text is something I find annoying. The automatic resizing of the input area not only doesn't prevent that from happening, but makes it happen incredibly frequently.

There's a problem with enforcing a minimal or maximum size for the input size area: you can never be sure about what limits the user would be happy with. You say 16 lines would make 99% of people happy? I say the problem is that having an initial size of only 2 lines makes people unhappy. Now what? Should we have the input area to be always larger than 4 lines and smaller that 16? But what about people who manually resized their input areas to be as large as 3 or 20 lines?

I'd like something stable. I think Pidgin should support one of those:

  • Manual resizing -- which would mean another option to the program or giving up the new functionality, something the developers conider a last resort.
  • Min/max configuration -- that's what we have now, except that min/max are fixed. Let the user choose the min/max configuration and 99.99999% of people will be happy. Obviously, Pidgin should allow min<=max so that people who don't like the autoresizing are just as happy as all the other people.

comment:106 follow-up: Changed 8 years ago by rudidude86

It's about time we got those pesky users under control. While we're at it, we should make entire windows unresizeable too! The window could start with enough room for two lines of message history, then expand itself the more you converse. Sure it wouldn't make any sense, but at least we'd see fewer scroll bars!

But seriously, the whole auto-resize issue in 2.4 seems like a bad solution to a problem no one had. I found it annoying enough to downgrade back to 2.3.1.

It's great that the dev's are trying to improve things, but this drastically damages the user interface by removing key tools for adjusting it. The best size for my text input box is whatever I set it to, and the best size for Bob's text input box is whatever Bob sets it to, despite seanegan's insistence that he and the other Pidgin devs can do a better job.

* The text input box feels extremely cramped for how I use IM

  • Dynamic resizing creates distracting and unnecessary UI noise

The best solution would be to completely revert to pre-2.4 text input behavior.

A so-so solution would be a min-height user pref (so I could make mine something ridiculously larger than 2 to avoid auto-resizing completely).

comment:107 in reply to: ↑ 106 Changed 8 years ago by lvets

Replying to rudidude86: ...

It's great that the dev's are trying to improve things, but this drastically damages the user interface by removing key tools for adjusting it. The best size for my text input box is whatever I set it to, and the best size for Bob's text input box is whatever Bob sets it to, despite seanegan's insistence that he and the other Pidgin devs can do a better job.

I cannot agree more with the above statement. I've reverted back to 2.3.1. Imho, this is a step back instead of step forward. I've always set the text input window to a size that I liked (rather large, but that's how I use it).

comment:108 Changed 8 years ago by patbarron

I have to chime in with agreement that this is a bad change - not the change of just having this behavior available, but the idea that it's been made mandatory. I must agree with the person above who described this as "a terrible solution to a problem no one was having".

I'm reverting back to 2.3.1 until this change is either backed out, or made optional.

comment:109 follow-up: Changed 8 years ago by Sim-on

i like these discussions. They are similar to other projects (doesn't matter what kind of). If you change anything in the UI-bahaviour, there are a lot of people "i dont like this"... In 2.2.0 some people didn't like the new status-bar in the conversation-window... Anyone still talking of this?

now all people don't like the autoresizing of the input-area. My first impression wasn't such good but now i has accepted this change... not it is for me like it have never been different...

comment:110 in reply to: ↑ 109 Changed 8 years ago by kdorff

Replying to Sim-on:

now all people don't like the autoresizing of the input-area. My first impression wasn't such good but now i has accepted this change... not it is for me like it have never been different...

Nothing like apathy. And we wonder why nobody complains when their rights as citizens are taken away: because people just don't want to speak up and would rather "just get used to it". As far as I can tell, the developers stopped contributing their thoughts to this issue days ago and they will either consider to our requests or they will just decide "they know better" and just push forward. How many people will be stuck at 2.3.1 or with another program, I wonder? It seems like quite a few folks aren't happy to "just get used to it".

comment:111 follow-up: Changed 8 years ago by rudidude86

I agree with Sim-on that any change to the UI will always ruffle a few feathers, but I think the scope of this change warrants all the serious questions about it.

If someone is typing a lot of stuff and they fill up their text input box, the program can either slap in a scroll bar or expand the height of the box (or a weird mixture of the two in this case). Either choice seems reasonable and this particular aspect of what changed isn't a big deal.

The real problem is that the ability to manually resize the input box has been removed. That's a huge UI change and directly hurts the experience of a lot more people than it helps.

The argument is that users don't need to bother with resizing now that Pidgin "does it for you," but what if I want to change it because that's how I likes it? Maybe it's a white-space fetish, maybe it's aesthetic taste, maybe a box that's barely bigger than my text feels psychologically limiting and claustrophobic. It's hard to concretely defend, but having an unchangeable default size feels very wrong, and it's clear that a lot of people feel this way. What's gained from removing manual resizing?

Adium (v1.2.3) handles this issue elegantly by both allowing you to manually change the size of the text input box per window and resizing it for you if you happen to run out of the room you allot yourself. Pidgin should mimic this behavior.

comment:112 in reply to: ↑ 111 Changed 8 years ago by epic9x

I'm registering for the first time here to increase the volume on this issue after recently upgrading. I've given this a spin for a few hours and can't get used to it, nor can my coworkers who've tried it. I am also being forced to revert just to get work done, and will likely lie to myself about having the skills to patch this before trying to find another client to meet my needs.

As someone previously noted, the chief problem is this prevents you from using the textbox to share and edit large blocks of text. Sharing and correcting info from customer tickets and bits of code from various places is essentially the primary use of pidgin in my work environment. The new version makes pidgin near useless for this purpose as often we want to resize the window to see the entire paragraph/text we're editing.

As I've read it, rudidude86 stated it best by saying we should be adding a feature, not exchanging one feature for another. Whether or not it has been seen this way, the way a piece of software works creates invisible 'features' like this for users, and that should be taken into account when making a major change like this to the core interface of the application.

Beyond just complaining: thanks much to the pidgin developers for all your hard work! Many of the other features/polishing added are quite nice.

comment:113 Changed 8 years ago by chtodelat

I registered just to voice my support for optional resizing as well. But at the VERY LEAST devs, please stop making the message box change size slightly ever time I backspace and re-enter a single character. It serves NO functional purpose, since I am not adding lines, just deleting/adding a single character, and it is extremely visually disturbing to watch.

comment:114 Changed 8 years ago by dcipher

+1 I registered just so i could chime in. I'm reverting back to 2.3.

comment:115 Changed 8 years ago by andrixnet

I would like to add my vote too - make text input area user resizable (or at least the new behaviour selectable in preferences).

And I confirm the slight vertical resize when entering text and pressing backspace.

I too am reverting back to 2.3 because of this, sorry :(

comment:116 follow-ups: Changed 8 years ago by ConnorBehan

For those of you revering to 2.3, this solution will work for awhile but eventually you are probably going to want new features that Pidgin developers introduce. I have created a fork for this purpose called "funpidgin" which is on sourceforge.net (http://sourceforge.net/projects/funpidgin/). It is my first software project and I'm hoping it will be a lot of fun. If it gains a serious following, it can have a more serious name.

Source code has already been released and I will put binary packages on there within the next few days. Currently it is identical to pidgin-2.4.0 except the text box is manually resizable and the "feature" where pidgin remembers your conversation window placement can be turned off if need be.

I'm using it now and it works very well. Please check it out and tell me what you think!

comment:117 in reply to: ↑ 116 ; follow-up: Changed 8 years ago by kdorff

Replying to ConnorBehan:

For those of you revering to 2.3, this solution will work for awhile but eventually you are probably going to want new features that Pidgin developers introduce. I have created a fork for this purpose called "funpidgin" which is on sourceforge.net (http://sourceforge.net/projects/funpidgin/). It is my first software project and I'm hoping it will be a lot of fun. If it gains a serious following, it can have a more serious name.

I can certainly appreciate the work you have done and the work it will take to maintain your fork (keeping it updated) but this should absolutely not be necessary. I wish the developers would come back and realize that the removal of this UI feature should have have been done so lightly and they should REALLY make it an option and not force us to use it. PLEASE DEVELOPERS: RE-JOIN THIS CONVERSATION. Don't you see that people really did like the resize-ability of the compose box? We don't want it to be "your way or the highway"? We can both have our cake and eat it two, just implement both and let us choose. It is fine if you make "your way" the default, please just give us the option.

comment:118 in reply to: ↑ 117 Changed 8 years ago by seanegan

Replying to kdorff:

PLEASE DEVELOPERS: RE-JOIN THIS CONVERSATION.

This is not a venue for conversation, but for reporting problems, requesting enhancements, and submitting patches. To that goal, this ticket has served its purpose.

If you wish to have a conversation (that won't be merely rehashing the same tired old points), we have forums for that: e-mail us at devel@…, chat with us on xmpp:devel@pidgin.im or irc:#pidgin@chat.freenode.net, or IM me personally SeanEgan?

comment:119 follow-up: Changed 8 years ago by quoderat

Yeah, forked! That's what I'm talking about! Fight tyranny! Yes we can!

Na na na, na na na, hey, hey, goodbye!

comment:120 in reply to: ↑ 119 ; follow-ups: Changed 8 years ago by hbons

Replying to quoderat:

Yeah, forked! That's what I'm talking about! Fight tyranny! Yes we can!

Na na na, na na na, hey, hey, goodbye!

that's pathetic...

comment:121 in reply to: ↑ 120 Changed 8 years ago by chtodelat

Replying to hbons:

Replying to quoderat:

Yeah, forked! That's what I'm talking about! Fight tyranny! Yes we can!

Na na na, na na na, hey, hey, goodbye!

that's pathetic...

Maybe, but so is the developers' refusal to re-implement a feature when they are confronted with how badly they underestimated its value to their users. This is not a radical demand, nor does it require an unreasonable amount of work. Given the number of people that have reverted to the previous version and the sheer number of complaints this regression turns up in a simple Google search, you'd imagine that they would admit they didn't expect so many people to miss input resizing this much and therefore provide an option. They must have been very proud about the auto-resizing idea, because they have stubbornly asserted here that they think they know what is best for us.

comment:122 follow-up: Changed 8 years ago by eddyp

I will not get into any bashing or complaining, I'll just propose a strategy for a fix.

Proposal for the fix:

Just grow when needed and let me set the minimum; I must also be able to set a fixed input area, if I want to, just as it was before.

Description:

* by default, the input box should be at the old default size - around 4 lines - keep this value stored

Because nobody complained it was too big before.

* by default, when the text in the input area imposes a scroll bar, grow automatically; after sending the message, the input area should restore its size to the default

Because, if someone found the energy to implement this, probably he likes this behaviour.

* add a small icon with a lock and an up-down arrow - will show if input's size is locked ; this should be a tri-state: resize (setting stored globally)/lock this dialog (will not be stored)/lock all dialogs (stored and globally true)

Because some people will disable automatic resizing for a conversation or even globally.

comment:123 in reply to: ↑ 120 Changed 8 years ago by kdorff

Replying to hbons:

Replying to quoderat:

Yeah, forked! That's what I'm talking about! Fight tyranny! Yes we can!

Na na na, na na na, hey, hey, goodbye!

that's pathetic...

Yes, a fork should be unnecessary. But the developers have all but stated they don't want to discuss this issue here - that this bug report is not a place for discussion. They don't seem to be entertaining rolling back, if they are considering it they haven't stated anything along those lines here. If there is an existing forum thread for discussion of this feature vs the old feature, I would suggest the URL for that thread be posted here as a last comment and this bug report closed. Maybe in a forum thread they will join the conversation or at least let us know what their intentions are (since, aside from a fork, they hold the keys to the castle). Posting their intentions or thoughts would probably put a lot of minds at rest.

comment:124 in reply to: ↑ 122 ; follow-up: Changed 8 years ago by seanegan

Replying to eddyp:

I will not get into any bashing or complaining, I'll just propose a strategy for a fix.

Proposal for the fix:

Just grow when needed and let me set the minimum; I must also be able to set a fixed input area, if I want to, just as it was before.

This is what I originally tried doing (every version of Pidgin attempts to do this, but people don't realize because it's so broken), but it turns out to be near impossible. GTK+ doesn't like to let you programatically resize things after the user has manually sized it.

These new 2.4.0 changes started as trying to fix it, realizing how hard it was, asking "hey, does anyone care if manual-resizing just goes away altogether, getting a general consensus, and working on it together until we had it behaving as we thought was best"

Description: Because nobody complained it was too big before.

I think you mean "I didn't complain it was too big before." Unless you follow devel@… (the mailing list and the XMPP conference), our IRC channel, all the Trac tickets, and personal IMs and E-mails to developers, you can't really speak for nobody. And I know that you don't, because they did complain. I'm *still* complaining it's too big.

* by default, when the text in the input area imposes a scroll bar, grow automatically; after sending the message, the input area should restore its size to the default

Because, if someone found the energy to implement this, probably he likes this behaviour.

And as I mentioned above, this has been the behavior for some time.

* add a small icon with a lock and an up-down arrow - will show if input's size is locked ; this should be a tri-state: resize (setting stored globally)/lock this dialog (will not be stored)/lock all dialogs (stored and globally true)

Because some people will disable automatic resizing for a conversation or even globally.

Nobody ever asked to before, (and that's an actual nobody), so I doubt we need this complication.

Thanks for your comment; it's more constructive than most :)

The main problem is getting GTK+ to play nice with auto-resising and user-resizing. If anyone wants to submit a patch that gets it all right, I would gladly accept it.

comment:125 Changed 8 years ago by quoderat

I will be glad to help with the fork in any way I can. I am not a coder unless I have no choice, nor do I wish to be, but my SO is, and is into open source, too.

Changed 8 years ago by G-sus

comment:126 Changed 8 years ago by G-sus

Hello,

the current resizing behaviour of the text input box also causes troubles in combination the third party plugin LazyBums. I'm referring to Pidgin on Windows XP SP2 as I couldn't test this on others OSes.

LazyBums? provides configurable buttons that send often said words or phrases to the chat partner by clicking the according button. This button bar is put at the bottom of the conversation window, actually (as of the previous versions of pidgin) right below the text input box, using about the space of 2 lines of text. Since this box is not resizable anymore by simply dragging the divider with the mouse, the conversation window often appears without the text input box - see the screenshot I attached. This happens rather sporadically, I'm not sure, but it seems to occur always when a message was sent to the systray in away mode and then later opened by clicking the blinking "message arrived" icon in the systray. It appears to be independent from the protocol used.

As a workaround I have to check and uncheck the option "Show Formatting Toolbars" in the options menu of conversation window, afterwards I have the text box back and usable.

Not sure if this is solely a pidgin issue or rather an issue of the third party plugin. Just wanted to state it for the sake of completeness.

comment:127 follow-up: Changed 8 years ago by pdwerryhouse

It's actually quite easy to revert to the old behaviour in the source; just replace gtkconv.c with a copy from an older version of pidgin (I used 2.3.1) and then recompile.

I've put patches and Debian binaries here if anyone wants them.

comment:128 in reply to: ↑ 127 ; follow-ups: Changed 8 years ago by Iyeru

Replying to pdwerryhouse:

It's actually quite easy to revert to the old behaviour in the source; just replace gtkconv.c with a copy from an older version of pidgin (I used 2.3.1) and then recompile.

I've put patches and Debian binaries here if anyone wants them.

What about windows users? >>

comment:129 in reply to: ↑ 128 ; follow-up: Changed 8 years ago by pdwerryhouse

Replying to Iyeru:

What about windows users? >>

Dunno, I'm not interested in Windows.

I presume the patch that I provided there will work; just patch it and recompile.

comment:130 in reply to: ↑ 129 Changed 8 years ago by Iyeru

Replying to pdwerryhouse:

Replying to Iyeru:

What about windows users? >>

Dunno, I'm not interested in Windows.

I presume the patch that I provided there will work; just patch it and recompile.

I don't think Windows gives us the option to "recompile" since we don't "compile" in the first place. I'm no programmer either.

comment:131 in reply to: ↑ 128 Changed 8 years ago by Sim-on

Replying to Iyeru:

What about windows users? >>

http://developer.pidgin.im/wiki/BuildingWinPidgin

comment:132 in reply to: ↑ 124 Changed 8 years ago by eddyp

Replying to seanegan:

Replying to eddyp:

I will not get into any bashing or complaining, I'll just propose a strategy for a fix.

Proposal for the fix:

Just grow when needed and let me set the minimum; I must also be able to set a fixed input area, if I want to, just as it was before.

This is what I originally tried doing (every version of Pidgin attempts to do this, but people don't realize because it's so broken), but it turns out to be near impossible. GTK+ doesn't like to let you programatically resize things after the user has manually sized it.

Maybe there is a good reason for that: an application must not decide for the user about preferences, especially after he/she made some manual tweaks.

I'd call that a feature of GTK :-) (but still, I understand why this can be an issue, being a programmer myself).

These new 2.4.0 changes started as trying to fix it, realizing how hard it was, asking "hey, does anyone care if manual-resizing just goes away altogether, getting a general consensus, and working on it together until we had it behaving as we thought was best"

Which, still, doesn't make it a good decision, judging from the huge number of replies to this BR. Heck, many people think reverting would be an improvement now (and that wouldn't mean that it can't be reintroduced after is reworked to work well for everybody).

Description: Because nobody complained it was too big before.

I think you mean "I didn't complain it was too big before." Unless you follow devel@… (the mailing list and the XMPP conference), our IRC channel, all the Trac tickets, and personal IMs and E-mails to developers, you can't really speak for nobody. And I know that you don't, because they did complain. I'm *still* complaining it's too big.

I stand corrected, "nobody I knew of".

Still, I think the people that commented vehemently against the change this ticket wants to address, are probably, in majority, in favour of rather keeping the old big-sized default, rather than having the 2-liner autosized input box (unless they can change the default).

* by default, when the text in the input area imposes a scroll bar, grow automatically; after sending the message, the input area should restore its size to the default

Because, if someone found the energy to implement this, probably he likes this behaviour.

And as I mentioned above, this has been the behavior for some time.

And since nobody complained about the auto-growing until now, they, most likely, didn't felt the feature impeded the way they used pidgin, it was transparent to them. Thus I, with all due modesty, say that the implementation was on the right track at that time. Which, clearly, can't be said now, since so many people complained.

About the impeding part and relative to the current state of affairs, it can't be said the same; now people are impeded by the way the UI works . Read below to understand why.

* add a small icon with a lock and an up-down arrow - will show if input's size is locked ; this should be a tri-state: resize (setting stored globally)/lock this dialog (will not be stored)/lock all dialogs (stored and globally true)

Because some people will disable automatic resizing for a conversation or even globally.

Nobody ever asked to before, (and that's an actual nobody), so I doubt we need this complication.

I think you're missing the point of this. This is would actually make all camps happy: autoresizers, fixed-input fans, developers and all the ones that complained here (I really want some person to prove me wrong by providing a realistic scenario that wouldn't be addressed correctly by the proposal I made).

To expand why this is necessary and why people would be happy:

  • autosizers get their desired behaviour by default
  • the occasional cases when a user needs a bigger input area for a conversation (while generally being happy with autosizing) can do that, but without risking to have fixed size until the end of days
  • the large amount of people that commented here that always want a fixed input area get that with the third option; to reiterate, this group includes:
    • people that are distracted and/or annoyed by the dynamic UI
    • space-happy people
    • the large majority of people that just don't know that the entire window is a typing area (not focus input area, since the cursor is placed in the conversation area)
    • people that often use large message areas
    • people that want to decide for themselves the size of the input area
    • people feeling that the maximum line count of 4 is not enough
  • developers : this would allow you, developers:
    • fix the regression introduced: the ability to manually resize the input area was lost
    • not to over-complicate things in the code by saving in the configuration file things "conversations with johnny always use a fixed size window, but in general the input area should be as indicated by the config
    • leave the decision of the correct behaviour to the user, where it belongs - is obvious that some people like autogrowing, others hate it and their views range so widely that you simply can't please everybody with one default option (without allowing a way out)
    • close this bug properly

This would also be good UI design because it puts really upfront the method to obtain the desired behaviour, no matter which that is (the visual hint of a lock with an up-down arrow, I think is suggestive).

Thanks for your comment; it's more constructive than most :)

I hope you'll feel the same about this one, too :-) .

The main problem is getting GTK+ to play nice with auto-resising and user-resizing. If anyone wants to submit a patch that gets it all right, I would gladly accept it.

With the risk of sounding like a troll, until such a patch appears, please, please, please revert the change, or at least, offer a way to allow the user to choose the input area minimum size (which is, I think, the most annoying thing, since, as you said, auto-growing was already present but nobody saw such a big problem with it to such a level to send tons and tons of comments about it).

As a conclusion, the problem with this change is that it has multiple flaws and this is why people are unhappy now:

  • introduces a regression - always bad - (no way to resize, which was possible before)
  • people loose control over application's behaviour (no manual override)
  • changes dramatically a default UI appearance (a lot smaller input area than before)
  • changes dramatically the default UI behaviour (the input area grows now, while before it was static)
  • changes the way people expect the UI to work (can't manually override the default input)
  • changes the way people expect the UI to work(2) (the autogrow is counterintuitive, at least for some people)
  • even when the autogrow works, it is broken (since it has a too small max limit of visible lines)
  • even when the autogrow works, it is broken(2) (the 4 lines max is arbitrary, something like "as big as possible, but not more than the size that would allow displaying at least the last line of the conversation" would be more sane)
  • people are not aware that the whole window is a typing focus area

While some points might overlap partly, this is not that relevant since the whole mix is the reason for the HUGE wave of unhappy people commenting to the ticket. OTOH the various angles from which people justify the reason NOT to like the autogrowing-initially-small-input-area-but-with-small-max feature ;-) is justified in one of these cases.

My proposal tries to fix all of the ones that can be technically fixed (the last one can't be fixed through coding) and also allow the new behaviour to enter the application in a way that doesn't make people unhappy.

comment:133 follow-up: Changed 8 years ago by UI-freak

This "enhancement" convinced me that my days with Pidgin were over. It is the most useless and annoying feature I have seen in any program for a long time. A looong time.

The number of complaints tells me that this was an utterly failure. Who ever wanted automatic resizing anyway?

The developers make useless... USELESS... changes to the user interface, but the number of new features is close to zero, especially for MSN users.

I don't need nerds to tell me to get a text editor or mail client, nor do I need automatic resizing. I didn't roll back to 2.3.1 I completely uninstalled Pidgin, installed emesene that supports MSN much better.

You have been shooting in the dark lately. Return to development of features requested by users, your current ideas have been horrible.

Goodbye Pidin.

comment:134 in reply to: ↑ 133 Changed 8 years ago by binarygodmonkey

I would have to agree with UI-Freak. If this is how Pidgin will remain, I'll just use something else eventually. I refuse to use the latest version as it is useless to me. I know this is a free program, but why ruin it? It was so good...

comment:135 follow-up: Changed 8 years ago by nodashi

I've patched current version of pidgin (2.4.0) with a following way:

  1. Add a checkbox into a "Conversation" page of Preferences dialog to implement /conversations/old_style_height parameter
  1. Depending on this checkbox, input area in a conversation window may be auto-resized as in a current release, or takes fixed size with a handle and can be resized. When conversation closed, new size stored in a configuration file.

The patch follows.

--- pidgin-2.4.0/pidgin/gtkconv.c.orig  2008-02-29 17:09:28.000000000 +0500
+++ pidgin-2.4.0/pidgin/gtkconv.c       2008-03-19 11:19:43.000000000 +0500
@@ -171,6 +171,8 @@
                int width, int height);
 static gboolean pidgin_conv_xy_to_right_infopane(PidginWindow *win, int x, int y);
 
+static gboolean use_old_style_height();
+
 static GdkColor *get_nick_color(PidginConversation *gtkconv, const char *name) {
        static GdkColor col;
        GtkStyle *style = gtk_widget_get_style(gtkconv->imhtml);
@@ -223,6 +225,10 @@
        return FALSE;
 }
 
+static gboolean use_old_style_height() {
+       return purple_prefs_get_bool(PIDGIN_PREFS_ROOT "/conversations/old_style_height");
+}
+
 static gboolean
 close_conv_cb(GtkWidget *w, GdkEventButton *dontuse, PidginConversation *gtkconv)
 {
@@ -234,10 +240,17 @@
        PurpleConversation *conv = gtkconv->active_conv;
        PurpleAccount *account = purple_conversation_get_account(conv);
        const char *name = purple_conversation_get_name(conv);
+       gboolean old_style = use_old_style_height();
 
        switch (purple_conversation_get_type(conv)) {
                case PURPLE_CONV_TYPE_IM:
                {
+                       /* When using old-style input area sizing, save lower_hbox size on close */
+                       if (old_style)
+                               purple_prefs_set_int(
+                                       PIDGIN_PREFS_ROOT "/conversations/im/entry_height",
+                                       GTK_WIDGET(gtkconv->lower_hbox)->allocation.height
+                               );
                        if (purple_prefs_get_bool(PIDGIN_PREFS_ROOT "/conversations/im/close_immediately"))
                                close_this_sucker(gtkconv);
                        else
@@ -246,6 +259,12 @@
                }
                case PURPLE_CONV_TYPE_CHAT:
                {
+                       /* When using old-style input area sizing, save lower_hbox size on close */
+                       if (old_style)
+                               purple_prefs_set_int(
+                                       PIDGIN_PREFS_ROOT "/conversations/chat/entry_height",
+                                       GTK_WIDGET(gtkconv->lower_hbox)->allocation.height
+                               );
                        PurpleChat *chat = purple_blist_find_chat(account, name);
                        if (!chat ||
                                        !purple_blist_node_get_bool(&chat->node, "gtk-persistent"))
@@ -4374,6 +4393,25 @@
        int height, diff;
        int pad_top, pad_inside, pad_bottom;
 
+       /* We can prefer old-style input area sizing */
+       if (use_old_style_height()) {
+
+               /* Find stored height */
+               height = (gtkconv->active_conv->type == PURPLE_CONV_TYPE_CHAT) ?
+                               purple_prefs_get_int(PIDGIN_PREFS_ROOT "/conversations/chat/entry_height")
+                               :
+                               purple_prefs_get_int(PIDGIN_PREFS_ROOT "/conversations/im/entry_height");
+
+               /* if there is no such value, use 128 */
+               if (height<1)
+                       height = 128;
+
+               gtk_widget_set_size_request( gtkconv->lower_hbox, -1, height );
+
+               return FALSE;
+
+       }
+
        buffer = gtk_text_view_get_buffer(GTK_TEXT_VIEW(gtkconv->entry));
 
        wrapped_lines = 1;
@@ -4406,6 +4444,7 @@
 
        gtk_widget_set_size_request(gtkconv->lower_hbox, -1,
                diff + gtkconv->lower_hbox->allocation.height);
+
        return FALSE;
 }
 
@@ -4599,16 +4638,27 @@
 setup_common_pane(PidginConversation *gtkconv)
 {
        GtkWidget *vbox, *frame, *imhtml_sw, *event_box;
+       GtkWidget * vpaned = NULL;
        GtkCellRenderer *rend;
        GtkTreePath *path;
+       gboolean old_style = use_old_style_height();
        PurpleConversation *conv = gtkconv->active_conv;
        gboolean chat = (conv->type == PURPLE_CONV_TYPE_CHAT);
        GtkPolicyType imhtml_sw_hscroll;
 
        /* Setup the top part of the pane */
+
        vbox = gtk_vbox_new(FALSE, PIDGIN_HIG_BOX_SPACE);
        gtk_widget_show(vbox);
 
+       /* Start of paned install step 1 */
+       if (old_style) {
+               vpaned = gtk_vpaned_new();
+               gtk_widget_show(vpaned);
+               gtk_paned_pack1(GTK_PANED(vpaned), vbox, TRUE, TRUE);
+       }
+       /* End of paned install step 1 */
+
        /* Setup the info pane */
        event_box = gtk_event_box_new();
 #if GTK_CHECK_VERSION(2,4,0)
@@ -4700,7 +4750,13 @@
                         G_CALLBACK(refocus_entry_cb), gtkconv);
 
        gtkconv->lower_hbox = gtk_hbox_new(FALSE, PIDGIN_HIG_BOX_SPACE);
-       gtk_box_pack_start(GTK_BOX(vbox), gtkconv->lower_hbox, FALSE, FALSE, 0);
+
+       if (old_style) {
+               gtk_paned_pack2(GTK_PANED(vpaned), gtkconv->lower_hbox, FALSE, TRUE);
+       } else {
+               gtk_box_pack_start(GTK_BOX(vbox), gtkconv->lower_hbox, FALSE, FALSE, 0);
+       }
+
        gtk_widget_show(gtkconv->lower_hbox);
 
        /* Setup the toolbar, entry widget and all signals */
@@ -4742,7 +4798,12 @@
        default_formatize(gtkconv);
        g_signal_connect_after(G_OBJECT(gtkconv->entry), "format_function_clear",
                               G_CALLBACK(clear_formatting_cb), gtkconv);
-       return vbox;
+
+       if (old_style) {
+               return vpaned;
+       } else {
+               return vbox;
+       }
 }
 
 static void
--- pidgin-2.4.0/pidgin/gtkprefs.c.orig 2008-02-29 17:09:29.000000000 +0500
+++ pidgin-2.4.0/pidgin/gtkprefs.c      2008-03-19 11:15:18.000000000 +0500
@@ -963,6 +963,7 @@
 #endif
 
        pidgin_prefs_checkbox(_("Use smooth-scrolling"), PIDGIN_PREFS_ROOT "/conversations/use_smooth_scrolling", vbox);
+       pidgin_prefs_checkbox(_("Use old-style input area sizing"), PIDGIN_PREFS_ROOT "/conversations/old_style_height", vbox);
 
 #ifdef _WIN32
        pidgin_prefs_checkbox(_("F_lash window when IMs are received"), PIDGIN_PREFS_ROOT "/win32/blink_im", vbox);

comment:136 in reply to: ↑ 135 Changed 8 years ago by Iyeru

Replying to nodashi:

I've patched current version of pidgin (2.4.0) with a following way:

  1. Add a checkbox into a "Conversation" page of Preferences dialog to implement /conversations/old_style_height parameter
  1. Depending on this checkbox, input area in a conversation window may be auto-resized as in a current release, or takes fixed size with a handle and can be resized. When conversation closed, new size stored in a configuration file.

Can we have a more non-coder friendly "Modification" text file as well? Some people are not always used to having see the SVN Style Replacements. Also, will the patch work with windows?

comment:137 Changed 8 years ago by TacBoy

Add my name to the list of numerous people that created an account just for this bug/feature/change request. That fact alone should probably tip the developers off to something.

I read the entirety of this ticket and have come to a number of conclusions:

1) The developers in charge of this area (seanegan appears to be one) likes this change personally evidenced by his statements regarding how IM is meant to be used and that he thinks the text field is still too big. Being human their personal preferences clearly play part regardless of how much they will posture otherwise.

2) One of the key developer issues seems to be that to make it work properly would take "too much work", "complicate the code" and "is impossible with GTK+". Honestly, if any of the developers I manage came to me saying "it's too much work", "impossible" or "I can't do it" they'd find themselves in a pot of boiling water. We put a man on the moon, I suspect we can manage code features.

3) There are clearly a number of people that prefer the flexibility to have their UI to their liking. And who is to blame them? This is why we have skinning, etc. And clearly there MUST be preferences. Why two lines of input? Why not one? Why not have the input box not appear unless you click on the window? Why? Because that was what was decided. In this case however it is being decided for the all users based on a subset of people's preferences despite the fact that clearly at some point it was seen that giving the users a choice was good. But, it got too difficult for the developers and their solution was to yank it rather than deal with it. Now they are put on the defensive.

4) Despite the fact that a subset of the users are asking for a feature that was already existent the developers are not going to give them what they like. At best they may compromise between what the users want and what the developers feel is right.

As such, feel free to add my name to the number of people that will stop using pidgin. It is clearly the developer's right to code the application as they wish. It is also clearly my right to use the IM I choose. I choose to use one where the developers truly listen to the people using it. I shall reinstall Trillian as I review the the code to determine if it is worth maintaining my own fork.

comment:138 Changed 8 years ago by deryni

1) The fact that we like a feature is not (in and of itself) a reason to defend it, and while I haven't read this ticket in a while that reasoning is not used as a defense in any of the comments I did read, so I would hope it is not used as one in the ones I didn't

2) The key here is that you don't manage us, a fact you are keenly aware of and even reference farther down. Another fact is that we have no requirements for any of this beyond what we feel like creating, which is a freedom your managed developers do not have. Both of these factors are central to our claim that it is more work than we care to put in and why we ask for people who do want it to write it (at which point we will happily accept it).

3) There's nothing to respond to here really.

4) Incorrect, the entire goal of the discussion we were trying to have was to figure out what *exactly* people needed and *why* exactly they needed it, with the entire purpose being to attempt to come up with a solution that works better than the previous one did. The fact that so many people are unwilling to help us is a great hindrance to this cause and not at all likely to convince us to go to any great lengths for those people complaining. The 'compromise' we are trying to reach is between all the users (including ourselves, as we are also users). Why so many people misunderstand this and object to trying to help I will never understand, but I doubt it will change anytime soon.

Enjoy using Trillian, or whatever other client you choose.

Oh, and the fact that someone actually took the time to implement the preference for switching back to the old behaviour is a very nice surprise and I would like to thank nodashi for doing so (assuming the patch is yours). I have no intention of accepting such a patch because I still believe that is the wrong way to fix this and I would think it could be written as a plugin as well, but it at least shows a proper way of handling this situation and for that I want to commend you.

comment:139 Changed 8 years ago by Niomar

How can you choose to ignore number 3? It's specifically the main point of this entire ticket. Users want preferences and everyone is not going to agree on the format. So it should be a settable preference instead of forced. That is *exactly* what people want.

For whatever reason, when I first receive an IM, there is NO box for me to type in - until I hit the first key and it resizes. How can this be desired behavior?

Changed 8 years ago by Niomar

No area to type when first receive a new IM. Once I hit a key, it resizes to 2 lines.

comment:140 Changed 8 years ago by quoderat

Oy, the developers are idiots and a deranged Mexican should chew on their faces! How do I unsubscribe from this shit before I take a dump in these comments and smack some bitches around like they was runaways?

comment:141 Changed 8 years ago by hbons

That is a bug, and is now fixed in mtn, along with the possibilty of the text box to reach a max height of half the window height before the scrollbar appears.

comment:142 Changed 8 years ago by deryni

I didn't ignore number three, I didn't respond to it, there is a difference. I didn't respond to it because, as I said, there isn't anything to respond to. It didn't ask any questions it didn't make any claims that require responding to or which demand changes, it just 'ranted' about how preferences are good and they should never be removed and always added because people always like change. If you really want me to respond to it I can. As has been stated numerous times in many places (probably in this ticket at least once), preferences always have a cost, that cost is often not small, that cost is born by both the developers and the users, repeated UI (and psychology) studies have shown that too many options are significantly worse than none, and no people don't want a preference they want things to work. The entire point of having this discussion is to try to figure out what *other than a simple reversion* will work, we (the developers) actively want to find a better solution, a small (and not very vocal) group of users are likewise interested in finding a better solution (which is where the increased maximum height decision came from), and a second small (and very vocal) group of users is not interested in finding a better solution and is instead only interested in whining, complaining, screaming, or insulting us. I leave it to you all to decide where you all fit and which of those groups I find helpful and friendly and which I find distasteful and annoying.

comment:143 Changed 8 years ago by deryni

Oh, and as hbons pointed out (and was pointed out numerous times before that) the single pixel high issue is a *BUG* and is not intended and has been fixed (as far as we can test).

comment:144 Changed 8 years ago by hbons

  • Resolution set to fixed
  • Status changed from new to closed

comment:145 Changed 8 years ago by hbons

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:146 Changed 8 years ago by quoderat

REMOVED DEFACING SPAM

comment:147 Changed 8 years ago by quoderat

REMOVED DEFACING SPAM

comment:148 follow-ups: Changed 8 years ago by ConnorBehan

I think you missed one of quoderat's spam messages. quoderat: I don't care if you want to help with my fork, don't ever try to.

nodashi: Very nice! When I tried to do that, I got the one pixel high bug every time, but your patch works perfectly. Would I be allowed to use that in a future version of the "funpidgin" fork on sourceforge? You will be properly credited of course.

comment:149 in reply to: ↑ 148 Changed 8 years ago by Sim-on

Replying to ConnorBehan:

I think you missed one of quoderat's spam messages. quoderat: I don't care if you want to help with my fork, don't ever try to.

Anyway, i don't care about what quoderat said. He forces my browser to a crahs with his spam and this is actually the WRONGEST way to spread his opinion!!!

comment:150 in reply to: ↑ 148 Changed 8 years ago by nodashi

Replying to ConnorBehan:

Would I be allowed to use that in a future version of the "funpidgin" fork on sourceforge?

Yes, of course.

comment:151 Changed 8 years ago by btm

Seanegan,

The two line default is "visually jarring" for me, usability aside I've tried it for a couple days and can't get comfortable with it. I haven't tried it at different resolutions, I don't know that it'd make any difference.

I get it if having options in the preferences for setting the min/max is unacceptable because it adds too many options for the user, and a single option to make the size manually controlled is as well.

I don't see the reason to not put an option in the prefs.xml file to turn off automatic text box sizing though. You've got the new code and the old code, it's just an if right? I think that would make everyone that misses the old way happy, and the usability people still get a cleaner preferences dialog.

comment:152 Changed 8 years ago by nodashi

In facts, I've got a plugin (as deryni told) that looks working. I will test it for several days, and if I find no bugs in the plugin, I will try to submit a patch on Monday.

comment:153 Changed 8 years ago by ralf.faust

nodashi: Fantastic! I was hoping for such a plugin which would allow me to manually change the size of the input area. Sounds great! Thumbs up!

Deryni/Seanegan?: Would you accept such a plugin for the default distribution of Pidgin, to go along with such plugins as "Markerline" and "Newline" ?

comment:154 Changed 8 years ago by nodashi

Yes. I made a plugin. See http://developer.pidgin.im/ticket/5296 for details.

I build and tested it with a pidgin-2.4.0 on my Fedora 8 box, so at least sometime it works :-)

comment:155 Changed 8 years ago by Iyeru

Oh, by the way, AIM has this feature in their conversations, but they ALSO allow you to manually resize on top of it.

comment:156 follow-ups: Changed 8 years ago by dbeusee

I am with the huge majority that believe pidgin should have a preference to turn off this auto-resizing business. Most of us completely disagree that no options (no flexibility) are better than a lot (completely flexibility), but if the developers want to minimize the amount of flexibility, then fine, we don't need a preference for every little tiny detail.

But when you have a large user base that wants a particular preference, that's the time to add a preference. Forcing something which the majority of users are against is not going to keep your users loyal - they will flee to another IM client, or as already being provided, a fork (thanks for funpidgin - I am happy to have my control back!).

A plug-in is not the answer because it's much more coding and overhead than a simple preference and a handful lines of code in the base application.

If you won't put in the preference or restore the old functionality for us, then we will flock to funpidgin or some other IM client. Is that what you developers really want?

I ask you to please put your ego aside and do us this small favor. The code was already provided, right? I think it takes less time to do it rather than argue with your users - an argument, that in the end, you cannot win (unless you consider it winning when everyone flocks to some other IM client or fork - I really hope it doesn't take that to motivate you to make this small fix).

comment:157 in reply to: ↑ 156 ; follow-up: Changed 8 years ago by suncho

Replying to dbeusee:

I am with the huge majority that believe pidgin should have a preference to turn off this auto-resizing business.

I am against adding preferences (we dont want another code-bloat like miranda).

Still, for me the proper solution is manual resize (simple behaviour) by default and automatic rezise (exotic behaviour) as a plugin. Automatic rezise turned out to be platform speciffic, something is supported by GTK, something is not. Some devices might not support the concept at all (how about the maemo port?).

However, I dont think we are in a position to force the developers to do anything. That is the beauty of open source, after all - if you don't like something in the code, then you could change it. In the mean time, I got used to the autoresize... just fix the umlaut/cyrillic bug, please :)

comment:158 in reply to: ↑ 157 ; follow-ups: Changed 8 years ago by Sim-on

Replying to suncho:

(we dont want another code-bloat like miranda).

right!

Still, for me the proper solution is manual resize (simple behaviour) by default and automatic rezise (exotic behaviour) as a plugin.

now it will be th other way around. there are already plugins to disable automatic rezise! And for people who want to write long text the maximum of the auto-rezise-input-area has changed to the half of the window-size (without scrollbar). So with a hight resolution you should have enought space for long text!!!!!

just fix the umlaut/cyrillic bug, please :)

this should be fixed in 2.4.1, which i think will be released soon.

comment:159 in reply to: ↑ 158 ; follow-up: Changed 8 years ago by Iyeru

Replying to Sim-on:

Replying to suncho: now it will be th other way around. there are already plugins to disable automatic rezise!

So you're saying we don't have to add the plugin manually? And that it will appear in the plugins list? If so, where? What plugin in the plugins list?

comment:160 in reply to: ↑ 159 Changed 8 years ago by Sim-on

Replying to Iyeru:

So you're saying we don't have to add the plugin manually?

No, but where is the Problem with adding a plugin manually? This is easy stuff. Pidgin is open source. So you can either build your own pidgin-version (with the patch or plugin mentioned above) or you seach a plugin you can easy copy to /.purple/plugins. After this, it should appaer in the plugin list. I think such a "huge majority" who want this function should be able to produce something like this ;)

comment:161 in reply to: ↑ 158 ; follow-up: Changed 8 years ago by suncho

And for people who want to write long text the maximum of the auto-rezise-input-area has changed to the half of the window-size (without scrollbar). So with a hight resolution you should have enought space for long text!!!!!

Excellent!! I would like to give thumbs-up to the idea "auto-resize upto half chat windows size". Now the solution is simple, elegant and rezolution independant.

99% of people who want manual resize simply hated the scroll-bar to appear. I spent some time thinking what number of lines will be the best limit for auto-resize... Definingit as 50% of the chat window is very good idea.

However, it is a complicated code and you should try to make it bug-free. Sometimes the input area opens with zero-height. Also, test it with "lazybums" plugin.

Good luck with 2.4.1!

comment:162 in reply to: ↑ 161 Changed 8 years ago by Sim-on

Replying to suncho:

However, it is a complicated code and you should try to make it bug-free. Sometimes the input area opens with zero-height.

Quotation to hbons:

That is a bug, and is now fixed in mtn, along with the possibilty of the text box to reach a max height of half the window height before the scrollbar appears.

comment:163 in reply to: ↑ 158 ; follow-up: Changed 8 years ago by dbeusee

Replying to Sim-on:

Replying to suncho:

(we dont want another code-bloat like miranda).

right!

How you look at code bloat depends on your perspective. If most users want manual resizing, most users would activate the plugin (if the plugin ends up being the manual control), which means more bloat and overhead is running for the majority of the users. Instead of a simple IF in the code, a plug-in has to be loaded, and it has to work it's way into the UI to override the auto-resize bahavior. I rather use funpidgin than run all this extra bloat for a basic UI feature.

Still, for me the proper solution is manual resize (simple behaviour) by default and automatic rezise (exotic behaviour) as a plugin.

now it will be th other way around. there are already plugins to disable automatic rezise!

Most users want manual control over the size, and as such, it should be the default behavior. The auto-resize is the minority, and is problematic at best (at the moment), trying to deal with different resolutions, soft and hard line breaks, copy/pasting, jumpy and distracting behavior, etc. This more fancy code should be in a plugin, and also because it is likely to be platform specific and take several releases to get it right.

And for people who want to write long text the maximum of the auto-rezise-input-area has changed to the half of the window-size (without scrollbar). So with a hight resolution you should have enought space for long text!!!!!

I would argue that 50% is not enough. I would like a ceiling of 80% at least - maybe even 90%. Reviewing the text you are writing is more important than seeing what has already been said.

Without some control over behavior (min and max limits, manual or auto sizing, it's very hard for pidgin to try to second-guess how to best make it a pleasant experience for each of us in our unique usage.

just fix the umlaut/cyrillic bug, please :)

this should be fixed in 2.4.1, which i think will be released soon.

If you don't make the majority of the people happy - make it easy for them to set it up to their liking, and soon, it may be too little too late. Do it right, and do it quickly.

I have already switched to funpidgin. I'll gladly come back to pidgin if my experience is as good as or more pleasant than it was in 2.3.1 without much trouble in setting it up and without using more memory or other overhead that makes it have the look or feel of it being more of an after-thought. I am not likely to want to activate a plugin which has to work harder to keep the UI under it's control, not for the boring, tried and true manual control.

If I wanted more spicy, automatic resizing, yeah, I'd use a plugin for that.

But I would still like to see both in the base code, controlled by min and max limits for autosizing and the choice to do auto or manual sizing. I don't think this basic UI control should be pushed to a plugin. Certainly not the behavior that most seem to want.

-Don

comment:164 Changed 8 years ago by Minimalist360

This is kind of amazing. If there was another free IM client that was decent I'd switch in a minute. I can't believe there are still people arguing that this is just people afraid of change. This feature sucks, hands down. While I'm sure whomever wrote it is happy with their code, very few other people seem to be. Roll it back, don't hack it up even further.

roll it back.

this is like when politicians make a law and it has unintended consequences but they are TOO PROUD to undo it so they tweak it. That's why our economy is being crushed under its own weight. Don't do the same thing to pidgin.

comment:165 in reply to: ↑ 156 Changed 8 years ago by nodashi

Replying to dbeusee:

A plug-in is not the answer because it's much more coding and overhead than a simple preference and a handful lines of code in the base application.

Now all work is done, there are plugin: http://developer.pidgin.im/ticket/5296

comment:166 follow-ups: Changed 8 years ago by stuporglue

Hi, I got 2.4 today or yesterday in Ubuntu Hardy and am very displeased with the fixed sized tiny input box.

The previous behavior was optimal. I chose the size, and then it could scroll within that size if needed.

I use GAIM for many purposes including chatting with family and for working one-on-one with other developers. In either of these cases I frequently send multi-line messages. When sending multi-line messages I wish to make sure that they look correct, whether that is an anecdote about my kid, or a code snipped which I've wrapped across multiple lines for clarity.

This is a regression in functionality and as such should be considered a bug.

A tiny dynamically expanding text area might be *neat* from a programming perspective, but it certainly hampers real world use for quite a lot of users (at least judging by the number of people who bothered to get accounts here just to post on this issue).

In UI design you need to know, and program for, your users. I suppose that if you ignore them, soon they'll no longer be your users.

Please fix this soon.

comment:167 in reply to: ↑ 166 ; follow-ups: Changed 8 years ago by mortan

Replying to stuporglue:

stuporglue, this statement sums it up:

03/04/2008 10:15:24 AM changed by hbons

I am sorry, but saying something like "I don't use it like that, so I don't care if you're >having problems" is exactly the kind of attitude which makes users of your software take to their heels.

I'm not saying I don't care about this "problem". Only, Pidgin wasn't designed to be a text editor. If you're complaining about you can't code in Pidgin, I would tell you to to use something else, and so would anyone else. If you realy, really want to code in Pidgin, I suggest writing a plugin that has all the features a modern text editor has.


Really, the only reason for going on with this discussion is that some of the developers can't speak things out clear.

Things are like this:

  • Some devs are in the mood telling you how you _have_ to use a IM
  • They are pretty pleased doing this
  • They notice that an appalling amount of users do not agree with _their_ _personal_ opinion about this but but they refuse to address the issue
  • They defend _their_ opinions with "hot air" arguments

Look at the discussion. "Pidgin is not a text editor", "If you want this feature build this plugin a pissed of user wrote on his own", "If you don't like this change use another IM, we don't care"

That are not arguments that address the issue, this are only statements that brings discussion away from it.

And if some guys are arguing such an behavior is okay because Pidgin is licensed under GPL they are WRONG. Free software is not about forcing other people to agree with their opinions. Maybe this people should follow the discussions about FSF and GPL3 on the LKML more closely.

To get to the point: I really dislike such an ignorant behavior where every sentence is just about defending an personal ideology (no objective arguments at all) where in the end it just ruins many peoples day.

comment:168 in reply to: ↑ 167 ; follow-up: Changed 8 years ago by stuporglue

Replying to mortan:

Replying to stuporglue:

stuporglue, this statement sums it up:

03/04/2008 10:15:24 AM changed by hbons

I am sorry, but saying something like "I don't use it like that, so I don't care if you're >having problems" is exactly the kind of attitude which makes users of your software take to their heels.

I'm not saying I don't care about this "problem". Only, Pidgin wasn't designed to be a text editor. If you're complaining about you can't code in Pidgin, I would tell you to to use something else, and so would anyone else. If you realy, really want to code in Pidgin, I suggest writing a plugin that has all the features a modern text editor has.

hbons, I agree with you that Pidgin is an instant message client and not a text editor, I think no one here is suggesting that it is. I think what people are trying to say is that as an instant message client can be very useful for real-time collaboration with other programmers.

If I'm chatting with a friend who needs help understanding the syntax of foreach in PHP (happened last week), why would I make both of us open our email clients or visit pastebin or whatever? It's just a short snippet of text which is easily sent over IM. Making that text readable is so much easier if I can resize my text input box to more than four lnes at a time.

To all the devs : We appreciate your many hours spent improving and developing Pidgin. I think most of us who use it have found it to be the best tool for the job. One of the jobs a lot of us to with this tool relies on the feature of being able to see our whole message at once, and now that feature is gone. Even without that feature most of us will likely continue to rely on Pidgin, but we will be less efficient in our jobs. Please

Thanks, Michael Moore

comment:169 in reply to: ↑ 156 ; follow-up: Changed 8 years ago by deryni

Replying to dbeusee: If you think the number of people who have complained about this constitute even a majority of pidgin users (let alone a "huge majority") you haven't read enough of our comments on this (and other issues) yet. For reference, yesterday alone (Mar 30, 2008) pidgin was downloaded from sourceforge 11,264 times. So even if we assume that each person downloaded pidgin twice, and that no one gets pidgin from any location other than sourceforge (both of which assumptions are rather unlikely to be true) then for even a simple majority of people to have commented in the negative about this feature would require 2817 people to have commented on this; seeing as how your post was post 156 and mine will be 169 (as I'm writing this at least) I think we can agree that we aren't anywhere near majority yet (and that assumes that every post in this thread was a new person and that every post disliked it, neither of which is true).

No one has claimed that flexibility is bad or that no options at all is good, despite protestations to the contrary from our users.

The time to add a preference is when their is not one clearly correct behaviour and a reasonable compromise behaviour cannot be reached. We still believe that a compromise is possible and are still actively attempting to reach it (without nearly as much help as we would like as those most vocally against the change seem to want to refuse to help us fix it).

Funpidgin has, to date, received 164 downloads from SourceForge?. Which, while significantly larger than I would have expected, is again nowhere near a majority or even a significant amount of users. If the people behind funpidgin want to maintain their fork they are welcome to do so. I think the existance of the plugin in #5296 makes the cost associated with maintaining a fork higher than is at all reasonable, but if they want to bear it that is fine. If users want to move to using funpidgin because they don't want to bother using the above mentioned plugin that is also fine (equally not worth the cost to me, but then again I don't think resizing my input area is fun).

comment:170 in reply to: ↑ 163 Changed 8 years ago by deryni

Replying to dbeusee: If you think the number of people who have complained about this constitute even a majority of pidgin users (let alone a "huge majority") you haven't read enough of our comments on this (and other issues) yet. For reference, yesterday alone (Mar 30, 2008) pidgin was downloaded from sourceforge 11,264 times. So even if we assume that each person downloaded pidgin twice, and that no one gets pidgin from any location other than sourceforge (both of which assumptions are rather unlikely to be true) then for even a simple majority of people to have commented in the negative about this feature would require 2817 people to have commented on this; seeing as how your post was post 156 and mine will be 169 (as I'm writing this at least) I think we can agree that we aren't anywhere near majority yet (and that assumes that every post in this thread was a new person and that every post disliked it, neither of which is true).

No one has claimed that flexibility is bad or that no options at all is good, despite protestations to the contrary from our users.

The time to add a preference is when their is not one clearly correct behaviour and a reasonable compromise behaviour cannot be reached. We still believe that a compromise is possible and are still actively attempting to reach it (without nearly as much help as we would like as those most vocally against the change seem to want to refuse to help us fix it).

Funpidgin has, to date, received 164 downloads from SourceForge?. Which, while significantly larger than I would have expected, is again nowhere near a majority or even a significant amount of users. If the people behind funpidgin want to maintain their fork they are welcome to do so. I think the existance of the plugin in #5296 makes the cost associated with maintaining a fork higher than is at all reasonable, but if they want to bear it that is fine. If users want to move to using funpidgin because they don't want to bother using the above mentioned plugin that is also fine (equally not worth the cost to me, but then again I don't think resizing my input area is fun).

comment:171 in reply to: ↑ 166 ; follow-up: Changed 8 years ago by deryni

Replying to stuporglue: Presumably your problem with the "fixed size tiny input box" is either the zero-pixel entry bug or the four line limit on growth, both of which should be fixed in 2.4.1 (by fixing the zero-pixel bug and raising the cap to half the window size).

So if you have a problem that is different than (or unfixed by) the above two issues, I will direct you to the discussion on how to helpfully attempt to have us fix things for your usage (within the current design idea).

comment:172 in reply to: ↑ 167 Changed 8 years ago by deryni

Replying to mortan: If you have failed to see any of the constructive comments about why we think resizing is a better idea and why we think we can fix it to work for everyone and where we repeatedly asked for help from the people who didn't like it in order to make it better than I submit to you that the problem is not that we didn't say or do that but that you chose not to understand it when we did. I submit that to you because I have on numerous occasions done exactly those things, and done them more than once.

comment:173 in reply to: ↑ 168 ; follow-ups: Changed 8 years ago by deryni

Replying to stuporglue: We have taken into account the complaints that the cap of four lines was too small and have increased it to a maximum of half the window. Virtually everyone we asked about that change (including people who came complaining) agreed that that would likely be more than enough for them.

As that change has not yet been in a release (but will be in 2.4.1 when it releases soon) we are still waiting for further feedback on this issue once people get a chance to try it.

I would also like to thank you for in all your comments being reasonable and calm and presenting your statements as what they are (personal opinions and feelings) and not assuming that you speak for some large unspoken majority of people. Also for realizing that despite the negative effects a given change might have had on your usage for the moment that the changes are not intended as attacks and are intended to make things better for everyone in the long run.

comment:174 in reply to: ↑ 173 Changed 8 years ago by stuporglue

Replying to deryni:

Replying to stuporglue: We have taken into account the complaints that the cap of four lines was too small and have increased it to a maximum of half the window. Virtually everyone we asked about that change (including people who came complaining) agreed that that would likely be more than enough for them.

Woo hoo! Yeah, that'd be sufficient for me too.

As that change has not yet been in a release (but will be in 2.4.1 when it releases soon) we are still waiting for further feedback on this issue once people get a chance to try it.

I would also like to thank you for in all your comments being reasonable and calm and presenting your statements as what they are (personal opinions and feelings) and not assuming that you speak for some large unspoken majority of people. Also for realizing that despite the negative effects a given change might have had on your usage for the moment that the changes are not intended as attacks and are intended to make things better for everyone in the long run.

This is reminiscent of when Ubuntu introduced window snapping. The border attraction settings were way too strong to be useful at first and a lot of people got mad. Then the devs tweaked it and suddenly it was a super nice feature and everyone(?!) is happy. I expect that's what'll happen here too...sometimes people (myself included) just get a little aggressive on their side of the feedback cycle.

Thanks, Michael

comment:175 in reply to: ↑ 173 ; follow-up: Changed 8 years ago by kdorff

Replying to deryni: I still contend I don't like it starting out so small. I can appreciate increasing the maximum size if we HAVE to have auto-resize (not my personal preference), but have you also (provided an option for) increasing the minimum size, too? I think 2 lines is too small. Again, my personal preference. This is why manual resize is nice, my preference doesn't need to match yours.

Also, you say you think you can "make it work for everyone" and you have "asked repeatedly for help" from people, but I contend people aren't helping you because you have expressly stated (on at least once) you aren't interested in their help or at least not interested in their solution (with no other discussion on the matter). nodashi published a diff that would, I believe, make BOTH camps happy, but you flat out rejected his offer just because it added a single option to preferences. When I read this I lost all interest in looking into helping you guys with the code because I felt any help I offered would be similarly rejected. Perhaps you can outline what kind of solution you would be willing to entertain that will make both camps happy so us coders can offer assist with a solution that you MIGHT be willing to accept? We also want to make Pidgin better and a product.

Finally, you compare the number of active people in this thread voicing their concerns to the number of Pidgin 2.4 downloads to the number of FunPidgin downloads. Personally, I think your thinking on this is a touch askew. The simple fact that so many people are voicing their opinions here is amazing and does, I would argue, suggest that a potentially huge number of people are unhappy. You cannot count on the "average" user to (a) hunt down this change request (b) create an account (c) complain. If they even got to (a) they might see that complaining seems to be gaining nothing and just not bothered. I contend that 90% of your users will see the new feature and love it, hate it and live it with or hate it and silently dump Pidgin for something else -- few users will be so pro-active as to come here and complain. The fact that THIS MANY people are complaining should tell you something, I think. But what do I know.

comment:176 in reply to: ↑ 169 ; follow-up: Changed 8 years ago by TacBoy

Replying to deryni:

I wasn't going to respond on this ticket any more but if you were serious with trying to relate number of downloads with number of comments I'd like to point out that your assumption is that every user will make a post if dissatisfied, which is just silly. One could argue that there are more dissatisfied posts than there are satisfied, but that would be silly too. (for a number of reasons) So, to be serious; there is no way to determine if a majority or even a large portion of the base that installs and uses Pidgin is unhappy or happy with this specific feature. My guess is that most don't care and don't even notice one way or the other.

However, that said, one thing that IS clear is that there are a number of people that did notice and dissatisfied to the point of not just commenting on it but creating user accounts, creating addons, creating forks, and trying other IM clients. This is no small amount of effort and is something that any reasonable person should pay attention to. The responses from the devs back to the community, no matter how intentioned, have not seemed like those of someone that is paying attention. In fact, replies with plain nonsense quoting of numbers as if they mean anything is the exact sort of things that give this impression. It is beyond dismissive.

I commend you (and other devs) for trying to come up with a "compromise". However, I think the sticky point that quite a number of people (including myself) don't get is why a "compromise" is required in the first place. We simply do not understand how having a default value that can be manually overridden is a "bad thing" that needs to be changed.

I agree that the devs have not said options or flexibility are bad. That's certainly not why the feature was altered/removed. As near as I can tell it was done because correcting/maintaining the feature was not deemed with the effort. As well as hints that the devs like the current behavior better for their own personal use.

"Also for realizing that despite the negative effects a given change might have had on your usage for the moment that the changes are not intended as attacks and are intended to make things better for everyone in the long run."

And therein lies the crux of all of it if you ask me. (which you did not) A contingent of people don't see how removing the ability to set the size as you wish was "making things better" for anyone.

However, I was unware of funpidgin (as I'm sure most of the Pidgin users are unaware. Just as most of them are probably unware of this ticket.) and now that I do know I will go add my number to those downloads. Don't mistake ignorance of options for acceptance.

comment:177 in reply to: ↑ 171 ; follow-up: Changed 8 years ago by btm

Replying to deryni:

Replying to stuporglue: Presumably your problem with the "fixed size tiny input box" is either the zero-pixel entry bug or the four line limit on growth, both of which should be fixed in 2.4.1 (by fixing the zero-pixel bug and raising the cap to half the window size).

So if you have a problem that is different than (or unfixed by) the above two issues, I will direct you to the discussion on how to helpfully attempt to have us fix things for your usage (within the current design idea).

For the record, my UI issue is with the "small initial size tiny input box".

I still can not find the argument for why to not have a manual size preference. If the argument is that adding more options to the UI is bad for inexperienced users, why not an advanced mode like the preferences in azureus or about:config in firefox? As I asked earlier, couldn't we even settle for a change to prefs.xml so advanced users, who may not be a majority but at least are going to be numerous can have manual control back?

comment:178 follow-up: Changed 8 years ago by mortan

@stuporglue

hbons, I agree with you that Pidgin is an instant message client and not a text editor, I think no one here is suggesting that it is. I think what people are trying to say is that as an instant message client can be very useful for real-time collaboration with other programmers.

You are talking in a very friendly manner, but unfortunately you did not get what's wrong with hbons arguing.

To all the devs : We appreciate your many hours spent improving and developing Pidgin. I think most of us who use it have found it to be the best tool for the job. One of the jobs a lot of us to with this tool relies on the feature of being able to see our whole message at once, and now that feature is gone. Even without that feature most of us will likely continue to rely on Pidgin, but we will be less efficient in our jobs.

Of course I honor and estimate the enormous work the Pidgin developers have done, too. They do a great job but that's not the point of this ticket (even if it sounds rough).

If you think the number of people who have complained about this constitute even a majority of pidgin users (let alone a "huge majority") you haven't read enough of our comments on this (and other issues) yet. For reference, yesterday alone (Mar 30, 2008) pidgin was downloaded from sourceforge 11,264 times. So even if we assume that each person downloaded pidgin twice, and that no one gets pidgin from any location other than sourceforge (both of which assumptions are rather unlikely to be true) then for even a simple majority of people to have commented in the negative about this feature would require 2817 people to have commented on this; seeing as how your post was post 156 and mine will be 169 (as I'm writing this at least) I think we can agree that we aren't anywhere near majority yet (and that assumes that every post in this thread was a new person and that every post disliked it, neither of which is true).

I disagree with your calculation about "how less users are indeed unsatisfied". To compare downloads with responses in this wiki is wrong. I think you agree with me that the majority of pidgin users are "normal users" from which a huge amount don't write here or even know the ticket system. Also there are many upset users who know the ticket system but for whatever reasons don't write here (in the Arch Linux forums is a threat about it, the first thing my friend asked me after he upgraded was "how do I make this horrible auto resize go away?"). So, I think there are far more users than your calculation would suggest that don't agree with this change. To a better picture about the numbers I suggest to start a poll which is

1) easy to fulfill

2) reaches most of the pidgin users (i.e. visible on the pidgin.im front page)

No one has claimed that flexibility is bad or that no options at all is good, despite protestations to the contrary from our users.

That are good news! I really thought this because of your arguing about options == code bloat and the following statement from you

The time to add a preference is when their is not one clearly correct behaviour and a reasonable compromise behaviour cannot be reached

... wrong! You've missed one important point. There is no general way how to do a thing right nor a superior way for everyone (don't tell this GNOME developers, they would not understand this anyway). Different users have different habits which are by no way "wrong". So to come back to your statement where you really missed a point I would add:

The time to add a preference is when their is not one clearly correct behavior and a reasonable compromise behavior cannot be reached or if it's an essential point where different users tends to use different ways to accomplish the same thing.

We still believe that a compromise is possible and are still actively attempting to reach it (without nearly as much help as we would like as those most vocally against the change seem to want to refuse to help us fix it)

Please give an example in which way you (the developers) are attempting to reach a compromise. Denying user wishes here on the ticket system don't count for me.

If you have failed to see any of the constructive comments about why we think resizing is a better idea...

Hm, maybe I missed the constructive comments and the pros you are talking about. I'll take a closer look.

... and why we think we can fix it to work for everyone and where we repeatedly asked for help from the people who didn't like it in order to make it better

Yeah, and you got _many_ response and even a working patch from nodashi! Am I wrong or did you put it down with the argument that _you_ think it is not the "right way" to handle the issue? Oh man...

... than I submit to you that the problem is not that we didn't say or do that but that you chose not to understand it when we did.

Again, wrong! Don't assume that if I don't agree with you I actually chose to not doing it just for whatever reason.

... I submit that to you because I have on numerous occasions done exactly those things, and done them more than once.

I understand you. It's exhausting to answer to the same "hot air" arguments all the time (no irony at all!). But to force others to do what you think is right is not ok.

Please let some facts come into this discussion about what's wrong giving users the option to _chose_ what suits _their_ needs (not yours).

comment:179 Changed 8 years ago by mortan

The last 3 posts above my own covers many points of my view... Fine, how can one ignore all this concerns people have?

comment:180 Changed 8 years ago by G-sus

Hello,

can one of the admins of this site (or maybe someone else who might know) please state how I can unsubscribe from this ticket? I guess trac was not made for such a lively discussion, though, this discussion could be good if it would really move something (or someone, in that case the devs... ;-). So I think maybe unsubscribing wasn't implemented on purpose. But after receiving dozens of mails about new replys for weeks now, I'd really like to stop it. And I don't wanna creat a spam filter rule for this site.

As this ticket has already been spammed by someone for the same reason, I guess I'm not the only one who'd like to unsubscribe. But what I find strange is that both the links "My Acount" and "Settings" way at the top of this site only link to the FAQ. Not very helpful. First I thought it was temporary because of that childish spammer, but after two weeks or so the links still don't do what they promise to do.

So, any help there?

Regards, G-sus

comment:181 Changed 8 years ago by Apewall

I really fail to see why there would be a problem with combining the auto-resize with the ability to scale the input area.

Anything but this is a regression in usability in either direction.

comment:182 in reply to: ↑ 175 ; follow-up: Changed 8 years ago by deryni

Replying to kdorff: No, as of yet we have not added the ability to control the minimal size. If we continue to receive complaints (valid complaints not just complaints for the sake of complaining) about the default two line size I at least (I can't speak for anyone else) am open to coming up with a way to allow for people to control the default/minimal height of the entry area. As we have seen a small handful of requests for both a larger default size and a smaller default size.

I have repeatedly asked for constructive help and repeatedly asked not to be told that the only possible help is to revert the change or add an all-or-nothing preference. Which is exactly why the patch posted to this ticket is not something I have actively considered. I really do not believe an all-or-nothing switch is at all necessary and as such am unwilling to consider such a solution while there is still a chance of finding a real solution. At no point was this (or any other idea) rejected "just because it added a single option to [the] preferences [dialog]" but you are free to continue believing that as opposed to the actual reasons I (and others) have presented if doing say makes you feel better about not helping this move forward. I have routinely indicated that I am interested in ideas which help move the current design forward and which modify it to better serve all users without requiring a simple disabling switch, the fact that you (and so many other people) seem to have ignored (or just flat out missed) my comments to that effect is something I do not at all understand.

My comments about the download numbers were *precisely* designed to indicate how ridiculous any such discussions about majorities and minorities, and vocality are *in their entirety*. The fact that you (and others) seem to only see the insanity when the concepts are presented from our side is exactly the problem I was trying to bring out. I don't expect the average user to do any of the things you suggest and it is exactly for that reason that I cannot believe that the numbers of people who do that represent anything approaching even a representative sample of users let alone the clear and "huge" majority it has so often been presented as. I hope this makes my point more clear, I would dearly love to do away with any and all comments on numbers of users one way or the other as that is an entirely unhelpful metric in each and every way.

I might add that the fact that you are able, in essentially back-to-back sentences, to make the claim that the numbers of people who are willing to comment on this ticket is somehow representative of some larger unvoiced whole and yet that the numbers of people who aren't complaining (as seen as a portion of the volume of downloads from the SourceForge? statistics) is not representative of anything is an amazing display of mental gymnastics of a caliber I am afraid I am not capable of. I am amazed at your masterful ability to claim that the fact that the number of people commenting here is clear evidence of a large untapped group of likeminded people while simultaneously claiming that the (larger) number of people who have not done so is *not* an indication of the number of people who disagree with you (and thus either agree with me or do not care in the slightest).

comment:183 in reply to: ↑ 176 ; follow-up: Changed 8 years ago by deryni

Replying to TacBoy: I am amazed (and insulted) at your assertion that the amount of time the developers in general (and myself in particular) have spent in attempting to respond to the comments in this ticket, the duplicate tickets on this topic, the handful of discussions in the #pidgin IRC channel, and the (smaller) handful of discussions on the devel mailing list can *possibly* be seen as an indication of the fact that we aren't "paying attention". Does your definition of "paying attention" involve nothing beyond immediate capitulation to ill-formed and ill-defended requests? Do you really not see a difference between my taking the time to respond to as many possible posts here as I can and not responding to any posts here? Because if you don't (and this would explain why people seem not to read and understand my comments) I'll stop and save myself the time.

As to your comment about my numbers, you apparently failed to notice that I was intentionally being ludicrous *exactly* to indicate that any such discussions are insane and of essentially zero use. I did this specifically because I was responding to more than one comment which made the (indefensible) claim that the number of users commenting here is indicative of an overwhelming majority of users who believe likewise.

The fact that you (and other people) seem to be unable to understand (or accept) the arguments I (and others) have put forward more than once to explain why in fact we made the change we did and what benefits we think it has had for everyone (including the people that don't like) as well as the reasons we made the change this way rather than simply adding a boolean all-or-nothing option is *exactly* the problem that most confuses me. I have attempted to be clear on both of those points numerous times and have had seemingly zero ability to actually get anyone to read and understand my comments.

As I have said to others before, if you feel your time is best served by swithing to funpidgin by all means feel free to do so. I hope it serves you well and that the people behind it have the time to keep up with our releases, for their sake (I wouldn't want to be there when they fail and all of you who moved across realize they aren't infallible either).

comment:184 in reply to: ↑ 177 ; follow-ups: Changed 8 years ago by deryni

Replying to btm: Adding options for things which serve no purpose is not worth it, regardless of cost. I am still unconvinced that given a properly functional auto-resizing entry area there is any reason to need a manual resizing option.

All users believe themselves advanced users (who wants to believe they are stupid or that others are better then they are?). As to your comments about advanced preferences I direct you at large sections of http://pidgin.im/~elb/cgi-bin/pyblosxom.cgi/giving_back.html which covers the costs of preferences and how advanced preferences suffer from this more than others.

As a specific aside about:config is a UI abomination and should not be duplicated or used as a basis for ideas. It is a horrible hack for a program with many too many options for its size; and further it is simply an excuse to toss in random option garbage without needing to consider even attempting to create a user interface for said options.

*Why* do you need manual control back? What about the auto-resizing (of the new 2.4.1 version, so minimum of two lines maximum of half the window and no zero-pixel bug) is unacceptable to you? Is there anything that could be done to it to make it acceptable to you?

comment:185 in reply to: ↑ 178 ; follow-up: Changed 8 years ago by deryni

Replying to mortan: You also missed my point entirely, my point was not that my numbers were correct, or accurate, or meaningful. My point was exactly the opposite; my numbers were entirely meaningless exactly the same way the constant assertions that the opinion presented in this ticket is secretly held by the majority of pidgin users is meaningless (and as I said before unverifiable).

The case where different users use different ways to do the same thing, when both ways are equally valid, is *exactly* the case I am referring to when I say "when there is not one clearly correct behaviour". So yes, when there is not one correct method and no way to satisfy both/all of the equally valid and correct ways is when you need to add a preference. My *entire* goal in this ticket (and in all the other discussion venues for this issue) has been to attempt to determine if, in fact, there is *not* a suitable compromise. My attempts to do that have been greeted almost uniformly by insults about the effort I put into this, insults about how I clearly don't care about anyone, insults about my intelligence, and a blatant ignoring of my repeated requests for constructive comments. This is a most unhelpful and unfortunate reality and not one conducive to further attempts of this nature (not that I'm going to stop, I seem to be unable to help myself).

"Please give an example in which way you (the developers) are attempting to reach a compromise." <- Have you *not* read anything I've said? Have you not noticed *any* of the times I have asked for people to give me real concrete ideas about how the current mechanism can be tweaked to suit them better? Have you not seen any of the time I've asked for people to explain to me *explicitely* what about the current mechanism is unacceptable to them? Have you further managed to not see that I have gotten next to no useful constructive responses to those requests? At no point have I flat out denied a user wish here without explanation, at no point have I not attempted to draw out further information and further ideas. The amazing ability people have to ignore that fact continues to astonish me.

I challenge you to point me at a comment here which is a constructive approach to fixing the current mechanism to work better for a specific usage case (other than comments about the maximum size as we have already fixed that, exactly because we did in fact get concrete comments and usages). I further challenge you to point out where I put the presented patch down because I claimed that it is not the right way to handle the issue (without further explaining why I think that there is more work to be done in fixing the current mechanism). I further would like to point out that I have repeatedly indicated that I do not think an all-or-nothing preference is the right idea because I have repeatedly indicated that I think the current mechanism can be fixed (an idea I stand by and which I would still like help with).

I have ignored *NOTHING* anyone here has said (at least not intentionally) and I would challenge someone to prove me wrong on this point. I whole-heartedly dislike the continued insinuations that I am not giving this the attention it deserves or that I am somehow failing to pay the due attention to ideas presented here. I am growing decidedly annoyed by these continued insinuations and would very much appreciate it if they were to stop.

comment:186 Changed 8 years ago by deryni

G-sus: I believe that it is actually impossible to be unsubscribed from a ticket in trac, at least not without manually mucking about in the trac databases. Welcome to the varied and bizarre world of suck that makes up trac. Sorry.

Apewall: I hinted at the reasons in http://developer.pidgin.im/ticket/4986#comment:49 I know they were explained in slightly more detail in one of the other locations this issue was discussed, I'm unsure which location at the moment offhand, but the essence is that GTK+ did not make having both work correctly at all easy (or even possible).

comment:187 Changed 8 years ago by mlsterben

At this point I really don't understand why automatic chat input resizing isn't optional, and I'm really beginning to not care. How do I unsubscribe from these e-mails? It's really annoying to constantly see that people are still bickering and saying the same things.

"This feature is crap! Bring back the old way that has been in use without any complaints for years!" "Wah, I'm a lazy developer and we like it this way, so you guys can go eat a dick!" "Don't make me go Dr. Tran on your ass!" "Bring it on!" *internet squabble*

comment:188 in reply to: ↑ 185 Changed 8 years ago by TacBoy

Replying to deryni:

Replying to kdorff: No, as of yet we have not added the ability to control the minimal size. If we continue to receive complaints (valid complaints not just complaints for the sake of complaining) about the default two line size I at least (I can't speak for anyone else) am open to coming up with a way to allow for people to control the default/minimal height of the entry area. As we have seen a small handful of requests for both a larger default size and a smaller default size.

And herein lies part of the reaction you are seeing. Who are you to determine which complaints are just "for the sake of complaining"? What objective criteria are you using. It boggles the mind.

And the fact that you hear requests both for smaller and larger default sizes would seem to indicate (to me at least) that an option is desirable. Allowing the user to decide. Just what a good number of the responses have been saying.

I have repeatedly asked for constructive help and repeatedly asked not to be told that the only possible help is to revert the change or add an all-or-nothing preference.

It seems to me the reasonable thing requested (and now repeated) is a box with the behavior you have now but allowing people to set a default initial size by dragging the top of the chat window. It appears the people you accuse are not the only ones listening.

Which is exactly why the patch posted to this ticket is not something I have actively considered.

Perhaps it is this lack of active consideration that people seem to be taking for closed mindedness.

I really do not believe an all-or-nothing switch is at all necessary and as such am unwilling to consider such a solution while there is still a chance of finding a real solution.

Again, I believe this unwillingness is exactly part of the blow back you are encountering.

At no point was this (or any other idea) rejected "just because it added a single option to [the] preferences [dialog]" but you are free to continue believing that as opposed to the actual reasons I (and others) have presented if doing say makes you feel better about not helping this move forward.

As repeatedly stated, we've yet to hear a reason other than code comlexity vs developer time. Perhaps if you could restate what overwhelming argument there is for not having an manually adjustable box because after repeated re-readings of this thread myself (and others from what they have posted) have missed it. That may help rather than repeatedly referring to reasons nobody can seem to find.

I have routinely indicated that I am interested in ideas which help move the current design forward and which modify it to better serve all users without requiring a simple disabling switch, the fact that you (and so many other people) seem to have ignored (or just flat out missed) my comments to that effect is something I do not at all understand.

It could be because the ideas given are dismissed out of hand as noted above, without any clear indication given as to why. Other ideas such as just allowing a manual adjustment of the default level seem to have been ignored. I have found in life that if people are ignoring something it is because they don't want to hear it or don't understand it. With the devs it seems the former, with the users the latter.

My comments about the download numbers were *precisely* designed to indicate how ridiculous any such discussions about majorities and minorities, and vocality are *in their entirety*.

May I suggest then that you actually *say* that, because it is clearly not what came across. Or are the users wrong in the way they interpret and you right in the way you deliver a message also?

The fact that you (and others) seem to only see the insanity when the concepts are presented from our side is exactly the problem I was trying to bring out.

Perhaps this "us versus you" "our side, your side" is also part of the issue. As for insanity, do you honestly believe that these views and feelings are born out of nothing or ill will? It is a desire for an application that is usable for themselves. To continue to discount and dismiss it and demand alternate solutions without indicating what is truly wrong with the proposal seems unproductive.

I don't expect the average user to do any of the things you suggest and it is exactly for that reason that I cannot believe that the numbers of people who do that represent anything approaching even a representative sample of users let alone the clear and "huge" majority it has so often been presented as.

The options I believe you refer to were clearly indicated as for advanced users. So this is truly irrelevant. And while not the best solution doesn't address that point. I agree however there are better solutions that others can benefit from. But again part of the problem seems the dismissive nature of the denial of request.

I hope this makes my point more clear, I would dearly love to do away with any and all comments on numbers of users one way or the other as that is an entirely unhelpful metric in each and every way.

I'd say it's hardly unhelpful. It's entirely helpful. What it is not is possible in this forum and thus irrelevant.

I might add that the fact that you are able, in essentially back-to-back sentences, to make the claim that the numbers of people who are willing to comment on this ticket is somehow representative of some larger unvoiced whole and yet that the numbers of people who aren't complaining (as seen as a portion of the volume of downloads from the SourceForge? statistics) is not representative of anything is an amazing display of mental gymnastics of a caliber I am afraid I am not capable of.

The fact that you can relate a download to a comment, especially of an application prior to knowing how it opperates (potentially) or knowing it ever could have operated a different way is a mental gymnastic of a caliber I am happy I am not capable of.

I am amazed at your masterful ability to claim that the fact that the number of people commenting here is clear evidence of a large untapped group of likeminded people while simultaneously claiming that the (larger) number of people who have not done so is *not* an indication of the number of people who disagree with you (and thus either agree with me or do not care in the slightest).

If you thought it through you would realize that a) not everyone knows they can b) some that are see this and think it sufficient and c) some people would never say regardless. This is not a place to post tickets of congratulations. It's apples to oranges.

I am amazed at your masterful ability to claim that a number of people taking the time to do these things is not a clear indication of a greater number suffering it. It seems common knowledge to me. If your cable goes down do you think every single person unhappy about it calls the cable company? Of course not. So to think every single person unhappy posted in this ticket is just silly, but that seems to be your implication.

But, again, as I (I won't speak for others) said I'm sure the vast majority of users don't care one way or another. It's a tiny blip on their radar. But since they don't, it's neither an argument for or against any solution.

But to sum up the most important point:

What's wrong with the current solution with a half-height growth and allowing a grabbable bar to set the default size which installs at a default size of 2 lines? It seems simple, intuitive, straight forward and to meet the requirements of what everyone is asking for. Perhaps I am missing something as to how this wasn't grasped as what was wanted by several in the first place.

comment:189 in reply to: ↑ 183 Changed 8 years ago by TacBoy

Replying to deryni:

Replying to TacBoy: I am amazed (and insulted) at your assertion that the amount of time the developers in general (and myself in particular) have spent in attempting to respond to the comments in this ticket, the duplicate tickets on this topic, the handful of discussions in the #pidgin IRC channel, and the (smaller) handful of discussions on the devel mailing list can *possibly* be seen as an indication of the fact that we aren't "paying attention". Does your definition of "paying attention" involve nothing beyond immediate capitulation to ill-formed and ill-defended requests?

No, it means answering legitimate questions and concerns with reasons as opposed to out-of-hand denials with no reason given. If they have been given they have clearly not been misunderstood. It was not intended to be insulting, but truthful. I'll let you decide if the truth is insulting. However, I suspect instead that since you believe these things are "complaints for complainings sake" that you will instead decide that people saying they don't understand why as an attack rather than what it is... a truth. They don't make these things up.

Do you really not see a difference between my taking the time to respond to as many possible posts here as I can and not responding to any posts here? Because if you don't (and this would explain why people seem not to read and understand my comments) I'll stop and save myself the time.

I see a number of responses. The majority of which you seem to spend your time refuting what people say and then saying "why won't you give me ideas" when they have. What they have not given you is ideas you seem to like. But again, no solid reasons as to why or why it was even put in place in the first place. Again, perhas an iterration of that would help.

As to your comment about my numbers, you apparently failed to notice that I was intentionally being ludicrous *exactly* to indicate that any such discussions are insane and of essentially zero use.

Try clear communication instead of sarcastic allegory next time. It may communicate your idea more effectively seeing as how everyone that responded missed your point.

I did this specifically because I was responding to more than one comment which made the (indefensible) claim that the number of users commenting here is indicative of an overwhelming majority of users who believe likewise.

Funny, I agree with that, yet I communicated it clearly. (I believe)

The fact that you (and other people) seem to be unable to understand (or accept) the arguments I (and others) have put forward more than once to explain why in fact we made the change we did and what benefits we think it has had for everyone (including the people that don't like) as well as the reasons we made the change this way rather than simply adding a boolean all-or-nothing option is *exactly* the problem that most confuses me. I have attempted to be clear on both of those points numerous times and have had seemingly zero ability to actually get anyone to read and understand my comments.

I suggest that you consider that if nobody seems to understand your comments perhaps it is not the people that are the problem.

As I have said to others before, if you feel your time is best served by swithing to funpidgin by all means feel free to do so. I hope it serves you well and that the people behind it have the time to keep up with our releases, for their sake (I wouldn't want to be there when they fail and all of you who moved across realize they aren't infallible either).

I hold no illusion that they are infallible. I also hold no illusion that you can please all the users or that the way that I want it is the best or only way or that devs will listen objectively at all times. All I can do as a user is go with the option that best fits my need at the time. My sincere hope is that this main branch would be that. This is why I propose keeping it as it is with a half height growth with an adjustable default. I really don't understand what the downside of this is.

comment:190 in reply to: ↑ 184 Changed 8 years ago by TacBoy

Replying to deryni:

Replying to btm: I am still unconvinced that given a properly functional auto-resizing entry area there is any reason to need a manual resizing option.

Well, it could be that we get warm fuzzies from it. It could be that it presents a nicer obvious target area. Or, in my particular case it could be that I have limited screen real estate and have my chat window open all day. And given my usage pattern I (not the computer) have determined how much window I need for messages and how much for input. That a growing window either covers up the last thing a person said or pushes something they said out of views. Things that I am often replying to. Thus meaning I have to scroll the message portion of the window. Or it could just be because there is nothing "wrong" with a manual option and it is desired and given it *was* the behavior it doesn't seem unreasonable to request it. Especially when there has been no compelling reason given as to why users should NOT be given that ability, much less have it taken away.

And with that I guess I have nothing constructive left to add to this conversation.

And, yes, everything I have posted I feel has been constructive, even if that purpose was just to point out there was disatisfaction reasonable or otherwise. That in and of itself (your users opinions) ARE constructive and probably should be respected.

Thank you for taking the time to read these things.

comment:191 follow-up: Changed 8 years ago by dave314159

I just want to point out that seanegan explained in comment # 124 (and possibly even earlier) why auto-resizing and manual resizing are effectively mutually exclusive - It's all GTK+'s fault.

seanegan:

GTK+ doesn't like to let you programatically resize things after the user has manually sized it.

It seems to me that someone needs to talk to the GTK+ devs about this problem, and in the meantime, we need to come up with an interim solution.

The 2.4.1 implementation might be an acceptable interim solution. Or, maybe something like what I proposed in comment # 69 could work. What I had suggested there was to have something of a "manual resize mode" wherein the the auto-resize would be temporarily disabled until you had finished your handle-dragging.

comment:192 in reply to: ↑ 191 ; follow-up: Changed 8 years ago by seanegan

Replying to dave314159:

It seems to me that someone needs to talk to the GTK+ devs about this problem, and in the meantime, we need to come up with an interim solution.

It's not a 'problem'. It makes 100% sense for GtkPaned? to behave that way. If someone wants to have a hand at it, overriding GtkVPaned size-allocate function is probably the best way to get things working the way you want.

comment:193 in reply to: ↑ 184 Changed 8 years ago by btm

Replying to deryni:

Replying to btm: Adding options for things which serve no purpose is not worth it, regardless of cost. I am still unconvinced that given a properly functional auto-resizing entry area there is any reason to need a manual resizing option.

I'd be happy if the auto-resize functionality started at four lines, then grew up to eight or so. But I feel like that's larger than the average user probably cares for, and preferences for min/max size seems like twice as many options as a manual option

All users believe themselves advanced users (who wants to believe they are stupid or that others are better then they are?). As to your comments about advanced preferences I direct you at large sections of http://pidgin.im/~elb/cgi-bin/pyblosxom.cgi/giving_back.html which covers the costs of preferences and how advanced preferences suffer from this more than others.

I'd disagree, with some software I consider myself an advanced user, other software I do not. I'll forgo a lengthly example, but I'm sure there are many others like me in this regard. Who knows if they use pidgin or not.

As a specific aside about:config is a UI abomination and should not be duplicated or used as a basis for ideas. It is a horrible hack for a program with many too many options for its size; and further it is simply an excuse to toss in random option garbage without needing to consider even attempting to create a user interface for said options.

I'd consider that a personal opinion, but since you're a pidgin contributor and I'm not, your disgust works as a "we won't do that", and I'm okay with whatever you will or won't do, because I <3 OSS. I personally love about:config, because I use firefox so much on daily basis the ability to tune the little bits that don't work well with me makes my day much less gloomy. Of course many of those bits don't deserve check boxes, as there would be pages of them in the end.

*Why* do you need manual control back? What about the auto-resizing (of the new 2.4.1 version, so minimum of two lines maximum of half the window and no zero-pixel bug) is unacceptable to you? Is there anything that could be done to it to make it acceptable to you?

As I mentioned, I'd consider auto-size an improvement if I had four lines minimum. It's simply because the UI feels cramped at two lines. It's functionally adequate for me. It seems silly to complain about how it looks, but we are in bubble 2.0 are we're hiring "User Experience Designers" rather than "User Interface Designers" these days. I think if anyone considers it, they'll agree that how an interface feels to the user is pretty important (which I think is the UI argument for getting rid of options, because it makes the program -feel- complicated to the user)

comment:194 in reply to: ↑ 184 Changed 8 years ago by grassmonk

Replying to deryni:

*Why* do you need manual control back? What about the auto-resizing (of the new 2.4.1 version, so minimum of two lines maximum of half the window and no zero-pixel bug) is unacceptable to you? Is there anything that could be done to it to make it acceptable to you?

I have not yet tried the new version 2.4.1--I will soon--but I suspect that, based on your description of the improved behavior, that I will dislike it as well.

I cannot speak for anyone but myself, but I never found the max size of 4 lines to be the problem. I actually think 4 lines is pretty reasonable--I think I have my manually-sized input pane in 2.3.1 around 5 or 6 lines--and I think that I will find 50% of the window height to be excessive. I don't mind having scrollbars appear if I type/paste some extra text here and there that exceeds the input pane size. My problem with auto-resizing is that it is visually distracting to me, even jarring. It may seem silly, but it is important enough to me that I went back to using 2.3.1 after trying 2.4.0 for while.

I do have a question: instead of making the input pane resizeable by using a drag bar, why not simply let the user edit the minimum and maximum sizes of the pane? Even if a UI is not provided for it, couldn't the sizes be read from the prefs.xml file (and thus just be edited manually)? I assume that the values for 2 lines and 50% of the window height are stored somewhere, so what is the problem with loading a dynamic value at runtime, and letting the auto-resizing continue to happen, albeit without any visual change? Does that type of behavior run akin to the about:config abomination you mentioned? (While I don't often venture into about:config, I have found the need to use it on a few occasions, and I do appreciate it being there.)

At any rate, I do appreciate all the hard work that the Pidgin developers put into this project. As I mentioned in my previous comment, I have used Gaim/Pidgin? for the last 5 years or so and I am glad that such a great IM client is available. I hope that this issue with the resizing can reach a satisfactory compromise for all involved.

comment:195 in reply to: ↑ 192 Changed 8 years ago by eddyp

Replying to seanegan:

Replying to dave314159:

It seems to me that someone needs to talk to the GTK+ devs about this problem, and in the meantime, we need to come up with an interim solution.

It's not a 'problem'. It makes 100% sense for GtkPaned? to behave that way. If someone wants to have a hand at it, overriding GtkVPaned size-allocate function is probably the best way to get things working the way you want.

OK, after the comments about the new default max size (50% of height) which seem reasonable (at least to me), the only remaining issue seems to be the minimum default height.

Some people say it should be one line, some say that the current 2 line is ok, other would prefer a bigger default for the minimum height.

It is clear that this is also an issue where people disagree, so we should agree do disagree and see that we need some way to specify that default.

Developers have made it clear that they would like to avoid as much as possible adding an option, so the only way I see this can be fixed is to do this by setting the minimum by dragging the upper edge of the input box that separates it from the conversation area (and storing the minimum in the preferences as the new default for all the new windows from that point on, when such dragging occurs).

The only thing would stop such an approach to work and needs fixing, is the GtkPaned? behaviour wrt to manual readjustment and auto resizing.

I hope this solution would satisfy everybody and put an end to all this quarrel.

Note: I still see a problem with storing the minimum and using it from that point on, since there might be a temporary need for a new minimum in a conversation, but that could be easily corrected by dragging when a new window with that broken default is opened.

comment:196 in reply to: ↑ description Changed 8 years ago by Niomar

How does one remove them self from automatic emails when a ticket is updated?

comment:197 follow-up: Changed 8 years ago by suncho

I see big controversy in this thread and one thing keeps me wonder. No, really.

If you don't like changes of Pidgin UI (nothing wrong with that), why do you upgrade then? If you like Pidgin 2.3, and think it is perfect as it is, why go 2.4?

For example, I don't like Vista, and I still use XP. You can't have your cake and upgrade it too...

comment:198 follow-up: Changed 8 years ago by btm

Replying to deryni:

Replying to btm: Adding options for things which serve no purpose is not worth it, regardless of cost. I am still unconvinced that given a properly functional auto-resizing entry area there is any reason to need a manual resizing option.

I'd be happy if the auto-resize functionality started at four lines, then grew up to eight or so. But I feel like that's larger than the average user probably cares for, and preferences for min/max size seems like twice as many options as a manual option

All users believe themselves advanced users (who wants to believe they are stupid or that others are better then they are?). As to your comments about advanced preferences I direct you at large sections of http://pidgin.im/~elb/cgi-bin/pyblosxom.cgi/giving_back.html which covers the costs of preferences and how advanced preferences suffer from this more than others.

I'd disagree, with some software I consider myself an advanced user, other software I do not. I'll forgo a lengthly example, but I'm sure there are many others like me in this regard. Who knows if they use pidgin or not.

As a specific aside about:config is a UI abomination and should not be duplicated or used as a basis for ideas. It is a horrible hack for a program with many too many options for its size; and further it is simply an excuse to toss in random option garbage without needing to consider even attempting to create a user interface for said options.

I'd consider that a personal opinion, but since you're a pidgin contributor and I'm not, your disgust works as a "we won't do that", and I'm okay with whatever you will or won't do, because I <3 OSS. I personally love about:config, because I use firefox so much on daily basis the ability to tune the little bits that don't work well with me makes my day much less gloomy. Of course many of those bits don't deserve check boxes, as there would be pages of them in the end.

*Why* do you need manual control back? What about the auto-resizing (of the new 2.4.1 version, so minimum of two lines maximum of half the window and no zero-pixel bug) is unacceptable to you? Is there anything that could be done to it to make it acceptable to you?

As I mentioned, I'd consider auto-size an improvement if I had four lines minimum. It's simply because the UI feels cramped at two lines. It's functionally adequate for me. It seems silly to complain about how it looks, but we are in bubble 2.0 are we're hiring "User Experience Designers" rather than "User Interface Designers" these days. I think if anyone considers it, they'll agree that how an interface feels to the user is pretty important (which I think is the UI argument for getting rid of options, because it makes the program -feel- complicated to the user)

comment:199 in reply to: ↑ 197 Changed 8 years ago by btm

Replying to suncho:

If you don't like changes of Pidgin UI (nothing wrong with that), why do you upgrade then? If you like Pidgin 2.3, and think it is perfect as it is, why go 2.4?

For example, I don't like Vista, and I still use XP. You can't have your cake and upgrade it too...

Because pidgin is awesome, and will certainly get awesomer. Whilst XP is functional, Vista is less functional.

A better analogy is having a sports car that gets 5mpg and uses a baby grinder for fuel. A new model comes out that gets 50mpg, goes twice as fast, has a microwave oven, and comes with kittens, sans baby grinder too. But the door handles are a different color, and you don't like that. Isn't it better to fix the door handles than waste all those kittens?

comment:200 in reply to: ↑ 198 Changed 8 years ago by dbeusee

Replying to btm:

Replying to deryni:

Replying to btm: Adding options for things which serve no purpose is not worth it, regardless of cost. I am still unconvinced that given a properly functional auto-resizing entry area there is any reason to need a manual resizing option.

One of the big problems with auto-resizing (that's been said already many times here, which none of the developers have addressed) is the constant visual jarring effect. A lot of people like static size boxes that don't move often - it's easier on the eyes and and it's easier to tell when new messages come while you are typing (which seems to happen a lot). This is what is so appealing about manual resizing. The other thing is the sense of control. People like having total control over the size of their windows. The user knows best what works best for him/her.

I'd be happy if the auto-resize functionality started at four lines, then grew up to eight or so. But I feel like that's larger than the average user probably cares for, and preferences for min/max size seems like twice as many options as a manual option

For me, 50% max is not sufficient. I might need to copy/paste some code (or some document text or some email text I want send, but have the person on the other end review first), so I want the input box to go to the max height possible (the full window, as the manual resize allowed in 2.3), review my text, then send it, then put the input box back down to minimum size.

Since I don't think every user can agree on a min and max, there needs to be a way to override the defaults. And I still think manual resizing is more desirable and user friendly. It will always be MY preference. If you developers agree flexibility is a good thing, then give me the flexibility to choose manual resizing. Don't force your preference on the rest of us.

-Don

comment:201 Changed 8 years ago by labrat

I am yet another person who registered for the sole purpose of doing a drive-by on this ticket. I consider the new chat entry window to be a major (versus minor) usability regression and will be moving back to 2.3 until there is a built-in way to reactivate the old behavior.

comment:202 Changed 8 years ago by ralf.faust

Dear developers, I really hope that you reconsider this issue and accept that our now many-voiced point of view is valid even if you don't find our arguments "constructive" enough. I suggest adding this as a plugin shipped by default.

Having said that, there is now a Windows DLL for the manual resize plugin of nodashi. See http://developer.pidgin.im/ticket/5296.

comment:203 Changed 8 years ago by ralf.faust

By the way, I completely agree with TacBoy?. :)

comment:204 follow-up: Changed 8 years ago by lunaticinterior

I just signed up to bemoan this regression and ask for it to be changed back. This really impacts the usability of the application and of all my friends who use Pidgin, not a single one likes it (most have already downgraded to 2.3, and the rest will soon).

Why are the developers being so obstinate? It's beyond me. This is a change that has only pissed people off and harmed your project. I now no longer recommend Pidgin to neophytes, and I will be contributing time and money to the FunPidgin fork.

What a terrible idea, and what terrible arrogance on display here by the developers, free software or not.

comment:205 in reply to: ↑ 204 Changed 8 years ago by btm

Replying to lunaticinterior:

I just signed up to bemoan this regression and ask for it to be changed back. This really impacts the usability of the application and of all my friends who use Pidgin, not a single one likes it (most have already downgraded to 2.3, and the rest will soon).

It feels to me that this new feature, which many people don't like, for different reasons, probably took some work to write and to imply that it should be thrown out is a little short sighted. Some are uncomfortable with the size changing automatically, others like me don't like the minimum size, and there are/were a couple minor bugs associated. This bug should be likened more to a discussion as to how to improve the usability of pidgin for the trillions of users. Seaneagan had a nice bolded list waaaaay back in #26

Why are the developers being so obstinate? It's beyond me. This is a change that has only pissed people off and harmed your project.

I would disagree that arrogance or stubbornness has been displayed here on the part of pidgin developers. I haven't seen it, maybe I've missed it. Those commenter's that I have identified in my mind as pidgin developers seem to either be asking what exactly peoples complaints are or growing tired of having to keep asking. "I don't like it, get rid of it" is not very constructive criticism.

Now I'd personally prefer a check box on the interface tab of preferences to disable auto-size. I get why it was designed, and I understand that UI people don't like options (look at any Web 2.0 website these days). I'd personally compromise with the minimum being a larger number of lines, but I love Pidgin, I love that it's open source, and I appreciate that these folks are trying to improve it on a regular basis.

I now no longer recommend Pidgin to neophytes, and I will be contributing time and money to the FunPidgin fork.

What a terrible idea, and what terrible arrogance on display here by the developers, free software or not.

Your reaction feels a mite harsh and short tempered.

comment:206 Changed 8 years ago by ccb

I too registered an account to protest this change.

I'd intended to do so in the harshest terms possible but it's pretty clear from the other comments that there's been plenty of spleen vented on the poor hapless guy that did this.

Being a working programmer I normally run at very high resolutions with small fonts. This thing is NASTY when running at 1600x1200 on a 15" 4:3 LCD or 1920x1200 on 15.4" 16:9.

I don't know if it show arrogance but there's this thing called "the principle of least astonishment": don't shock the monkey.

In the meantime I'm rebuilding the 2.2.2 SRPM that originally came with Fedora 8 and have blacklisted Pidgin updates until this gets fixed.

comment:207 Changed 8 years ago by ccb

Ok... having read them all in detail I'll put a point on it:

I need a splitter pane that goes from 0 to 100% of the size of the parent pane. I need to be able to paste and review 60 lines of code at one whack. I turn off tabbed, I turn off sound and smileys, I turn on OTR. I don't use colors, I don't use fonts.

If I could have the send and recv panes in separate windows where my window manager controls the size of each I'd take it.

comment:208 in reply to: ↑ 184 ; follow-up: Changed 8 years ago by ddm

Replying to deryni:

Adding options for things which serve no purpose is not worth it, regardless of cost. I am still unconvinced that given a properly functional auto-resizing entry area there is any reason to need a manual resizing option.

I'm yet another person who signed up for an account here specifically to complain about this misfeature. I DO NOT LIKE AUTO RESIZING, AND I DO NOT WANT LIMITS OF ANY SORT ON MY TEXT INPUT AREA. I can't emphasize this enough. I want to have full control over the pane sizes of my conversation clients. The application can't guess how I want to use it, and how big I want the panes depends very greatly on the size of my screen, who I'm chatting with, what information I want to convey to them, and what the situational context is. In some situations, like at work where I have two giant heads to display my desktop, and fairly standard (for me that is) usage patterns, I'm able to set it to a particular size that works (fixed-width font, 100 colums wide, 6 lines tall) and leave it that way. In other situations, particularly on my work laptop, which has a small screen, and where I typically have to run about 2 dozen applications simultaneously, I'm constantly fussing and fighting with the Pidgin conversation window to meet my needs for that moment. Not having full control is simply UNACCEPTABLE.

In creating this functionality, you, as the developers, are making a judgment about how you think I should want to use the client most likely based on your own usage, or based on some assumption that all IM users use IM the same way, which is obviously an incorrect assumption. Based on that judgment, you're making a decision to place a limit on how I use the application, which a) never existed in the years of development history of the app, and b) which I, along with many users, clearly find distasteful. This change makes it impossible for me to use Pidgin in a way which is comfortable to me, and in a way that meets my needs.

I've been a happy GAIM/pidgin user for years, but if this behavior isn't reverted, it will definitely serve as cause for me to look for a different client.

*Why* do you need manual control back?

Why *WOULDN'T* we want it back? To answer your question more directly: Because I don't want a minimum. I don't want a maximum. And I surely don't want my text input box to resize on me without me telling it to. To be honest, I can't believe that it didn't occur to any of you guys that a lot of people would be upset by this change...

comment:209 in reply to: ↑ 182 Changed 8 years ago by ddm

Replying to deryni:

Replying to kdorff:

I have repeatedly asked for constructive help and repeatedly asked not to be told that the only possible help is to revert the change or add an all-or-nothing preference.

In other words, you refuse to accept that many people simply hate your change, and find it unacceptable. For me, it really is that simple: only one of those two options is acceptable. You've complained about people criticizing you for dismissing the desires of the users, but in saying the above, that's exactly what you've done. You have dismissed the only remedy which is acceptable to me, and many other users who've posted here.

I have routinely indicated that I am interested in ideas which help move the current design forward and which modify it to better serve all users without requiring a simple disabling switch,

Which completely ignores the reality that no such solution can be achieved, as many of us really do want to have full control over the conversation panes. I use this feature *often*, and the fact that it is now missing makes me frustrated and *irate*.

the fact that you (and so many other people) seem to have ignored (or just flat out missed) my comments to that effect is something I do not at all understand.

We have not missed them. They simply do not apply. The current design is wrong, and should be reverted, or made optional.

comment:210 Changed 8 years ago by Iyeru

Now that the 50% limit is on here, it's better for me; but I don't like the fact that the box goes way back down to 1.75 lines after I submit a message. I want to be able to still manually resize, but only up to 50% of the convo window, or whatever I set as a limit for the auto-resize; and not have it go back to the 1.75 lines after submitting.

Like have a setting just for auto-resizing, a whole sub-category for messaging.

[Check] Do Not Roll Back to Minimum Input Size After Sending an IM.

Maximum Input Size (In Pixels/Percent?): [Input Box]

[Check] Allow Manual Resizing To Specified Maximum (Above.)

comment:211 Changed 8 years ago by darose

+1

comment:212 follow-up: Changed 8 years ago by ccb

I think the major disconnect is *cultural*. This has been a screamfest where both sides are talking past each other. I don't understand the developer side of the argument at all. The complainers are on about this:

  1. a heavily used feature was removed
  2. the removal of the feature violates 'the principle of least astonishment' http://en.wikipedia.org/wiki/Principle_of_least_astonishment
  3. most "old school" UNIX people HATE HATE HATE MDI. MDI belongs in windows. Some applications make sense as MDI but MDI haters can only cope if all of the subwindows are highly configurable.

I tried to provide usable input:

  1. I said that I cannot compose outgoing messages in a two-line text input window. At my usual resolution I can barely see it let alone type there.
  1. I said that I often have cause to compose largish messages
  1. I've had an X workstation on my desk for 23 years. I've been at it for 10 hours a day every day. I've lived through UWM and Motif. If a program has multiple text panes, the X-windows programs ALWAYS make them resizable. If a program has multiple toolbars and menus, X-windows programs SHOULD make them detachable and reorderable.

The core issue is the cultural one. Once one establishes a work flow for X windows and uses it for a quarter century your expectations for how applications are going to behave sink in pretty deep. If the evolution developers were to decide by FIAT that the splitter pane between messages-list and message-content would be fixed at 4 messages in messages-list an identical firestorm would ensue.

http://www.faqs.org/docs/artu/ch01s06.html

The FunPidgin link came up empty...

comment:213 in reply to: ↑ 212 Changed 8 years ago by kdorff

Replying to ccb: I agree this change should have been something worthy of discussion. After 212 messages, having read every one of them at least once, trying to understand both sides I have come to this conclusion: in spite of the fact every other IM program (including Pidgin 2.3) follows a specific UI convention and that manually sizable panes is pretty much a standard in UI design, the developers had this cool idea they thought would revolutionize UI design and IM. They implemented it. They use it. It makes them happy. It seems their take is everyone else loves it the new UI... just us naggy few who thought resizing the composition pane was ever a good idea.

No amount discussion or pleading from their users will sway them from the idea that their new, revolutionary design is anything but perfect. Sure, it may have a bug or two which they are willing to address, but after 210+ messages in this thread and the various responses from the developers I think it is now safe to say our desire to have the previous UI is a complete waste of time and effort. We tried a compromise (option) that would satisfy both camps but again, if it means a manually sized pane they have no interest in that solution. As I see it, our options now are (a) learn to see the brilliance of the design (b) live it it (c) adopt another program (Pidgin 2.3, FunPidgin, Trillian, something else). I guess I'm done beating my head against the wall with this thread. Maybe with Pidgin, haven't decided yet - but obviously the developers just don't care if they loose users or not.

comment:214 in reply to: ↑ 184 Changed 8 years ago by Proto

Replying to deryni:

Replying to btm: Adding options for things which serve no purpose is not worth it, regardless of cost. I am still unconvinced that given a properly functional auto-resizing entry area there is any reason to need a manual resizing option.

All users believe themselves advanced users (who wants to believe they are stupid or that others are better then they are?). As to your comments about advanced preferences I direct you at large sections of http://pidgin.im/~elb/cgi-bin/pyblosxom.cgi/giving_back.html which covers the costs of preferences and how advanced preferences suffer from this more than others.

As a specific aside about:config is a UI abomination and should not be duplicated or used as a basis for ideas. It is a horrible hack for a program with many too many options for its size; and further it is simply an excuse to toss in random option garbage without needing to consider even attempting to create a user interface for said options.

*Why* do you need manual control back? What about the auto-resizing (of the new 2.4.1 version, so minimum of two lines maximum of half the window and no zero-pixel bug) is unacceptable to you? Is there anything that could be done to it to make it acceptable to you?

The default minimum of two lines is just bad UI design. You have the formatting bar and the tiny input box jammed at the bottom of the screen. It makes things look really cramped when initially typing. The window looks "unbalanced" because of it. Furthermore, because of the relatively small area to click into it adds just a little irritation where there shouldn't be any.

Extending the default minimum to say 6-8 lines would be an improvement. But really, the best fix would be to allow the user to alter it manually. IM programs are all about the user interface. If that doesn't work right the user will go elsewhere. Every programmer likes to think they are good at UI design, but very few of us are. That's why the best solution is to let the user configure the interface to meet their needs whenever possible.

comment:215 Changed 8 years ago by Bosmon

Yes, yet *another* drive-by signup. On downloading the new version I independently Googled for an issue such as this, read the thread with mounting outrage, and feel obliged to add myself in as yet another data point in this depressing example of communication in a distributed project "doing its thing" :)

quoting dernyi:

I have repeatedly asked for constructive help and repeatedly asked not to be told that the only possible help is to revert the change or add an all-or-nothing preference.

Will you please stop trying to bias what you consider could be the opinion of your user community? The only possible help *is* to add an all-or-nothing preference, since that is what I, and a large number thread participants have clearly articulated *is* the top-level feature they require. I don't know how many repetitions of this process you will require until you accept that this *is* the constructive help, since what you are seeing here is users directly demanding the feature that they know they want :)

If you consider somehow this request is not "constructive", I can only assume what this implies is that you believe your users are "wrong" in what they want (perhaps it violates some UI or design guideline you have in your mind), and goodness only knows where that line of thinking might lead :)

Just to be completely clear - I *do not want any form of auto-sizing applied to my input area at all*. I do not care how much time and thought has been lavished on any devlishly cunning algorithm that is provably "almost always right". I want to decide this height for myself, and I do not want it to change.

comment:216 in reply to: ↑ 208 ; follow-up: Changed 8 years ago by kluvik

Replying to ddm:

Replying to deryni:

Adding options for things which serve no purpose is not worth it, regardless of cost. I am still unconvinced that given a properly functional auto-resizing entry area there is any reason to need a manual resizing option.

I'm yet another person who signed up for an account here specifically to complain about this misfeature. I DO NOT LIKE AUTO RESIZING, AND I DO NOT WANT LIMITS OF ANY SORT ON MY TEXT INPUT AREA.

+1

comment:217 Changed 8 years ago by mlsterben

How do I stop receiving e-mails about this?

comment:218 Changed 8 years ago by mortan

You also missed my point entirely, my point was not that my numbers were correct, or accurate, or meaningful. My point was exactly the opposite; my numbers were entirely meaningless exactly the same way the constant assertions that the opinion presented in this ticket is secretly held by the majority of pidgin users is meaningless (and as I said before unverifiable).

Maybe it was like this. You can't expect that if you are arguing over the internet every person gets your subtile thoughts straight away. So speak clear. By the way, I adviced to do a poll to disprove your claim. But that's not needed if you agree with me that there are quite a few (not to say: much) people that don't like the change.

The case where different users use different ways to do the same thing, when both ways are equally valid, is *exactly* the case I am referring to when I say "when there is not one clearly correct behaviour". So yes, when there is not one correct method and no way to satisfy both/all of the equally valid and correct ways is when you need to add a preference.

So, you finally put this mess down? There is no correct way in this case or are you really that egocentric to claim _your_ way is the only one for all?

My attempts to do that have been greeted almost uniformly by insults about the effort I put into this, insults about how I clearly don't care about anyone, insults about my intelligence, and a blatant ignoring of my repeated requests for constructive comments.

That's because you put everything down that users suggest. I agree insulting is not the right way, but not everyone has the calmness to talk to a wall.

"Please give an example in which way you (the developers) are attempting to reach a compromise." <- Have you *not* read anything I've said? Have you not noticed *any* of the times I have asked for people to give me real concrete ideas about how the current mechanism can be tweaked to suit them better? Have you not seen any of the time I've asked for people to explain to me *explicitely* what about the current mechanism is unacceptable to them? Have you further managed to not see that I have gotten next to no useful constructive responses to those requests? At no point have I flat out denied a user wish here without explanation, at no point have I not attempted to draw out further information and further ideas. The amazing ability people have to ignore that fact continues to astonish me.

I read all your comments and I'm quite angry that I did. A waste of time, always the same pattern. Excerpt:

Comment 42

You are asking for comments about wether a customizable auto shrink is aceptable or not.

Comment 50

You are telling jason0x21 that automatic resizing could (!) work with significantly less problems (what problems?)

Comment 65

Not requiring people to resize the input area when they type a slightly longer message than normal is a good thing, not requiring people to resize the input area in that case is also a good thing, not requiring people to keep a large input area to avoid the need to scroll or resize is a good thing. The question here isn't about feeling restricted it is about letting people get an input area that just works for them and doesn't need them to resize or scroll constantly. (Which to jump back a second my solution allows for significantly more people than the current solution and is why I suggested it and am planning on implementing it.)

Not resizing the input box manually is "a good thing" in some way, yes. Making a normally static element becomming dynamic is not "a good thing". As one poster further up stated, the whool X-Environment is build upon the design that you have the possibility (a splitter) to adjust the size of controls at your needs. Do you want Kate (KDE text editor) to shrink / expand its document window all the time you open a new file with a short / long name? Pidgin resizing its buddy list if a buddy goes offline? Hell! I don't want such a life of its own.

Commment 72

kdorff: That is rather similar to what I've been suggesting this entire time, except I don't think setting a maximum is necessary, either you don't hit the maximum or you do and I still think being able to see that extra line for a moment is better than the scrollbars.

You see it like this... it's your "feature". You like it like this....

Comment 77

Gookey: "What if manual sizing is disabled when automatic sizing is enabled?" is exactly what we have now and what people are complaining about, simply allowing manual resizing again doesn't fix any of the problems people have had with the auto-resizing code and that is something I can not accept. The current code *needs* fixing, if after all that fixing it is still not acceptable to some people adding the option (or writing a plugin, or some other solution) can be considered.

Then fix your code!

"simply allowing manual resizing again doesn't fix any of the problems people have had with the auto-resizing code and that is something I can not accept"

Really, if I read this sentence over and over I like to puke. What a egocentric person you are! It's about not liking the concept and not about not liking the bugs!

(Your response to me, I want to put this in context)

I challenge you to point me at a comment here which is a constructive approach to fixing the current mechanism to work better for a specific usage case (other than comments about the maximum size as we have already fixed that, exactly because we did in fact get concrete comments and usages)

Guess what? I don't like the current mechanism at all! So I can't help you to "improve it". There is only one improvement for me: [x] auto shrink input field.

Comment 78

The point is not to allow you a smaller input size then you want if you find the resizing annoying, it is to allow you a smaller input size when you want to waste less space and see more history when you don't mind the resizing and avoid the resizing (basically) entirely when you don't want it by picking a default size that suits you.

Another "good thing", yes. But again, the fact that most of people don't need maximal history size and many are disturbed by a "controll with a life of its one" is a contra.

Comment 139

2) The key here is that you don't manage us, a fact you are keenly aware of and even reference farther down. Another fact is that we have no requirements for any of this beyond what we feel like creating, which is a freedom your managed developers do not have. Both of these factors are central to our claim that it is more work than we care to put in and why we ask for people who do want it to write it (at which point we will happily accept it).

Yeah, you don't need to follow someones will. Thats good! But don't state "we ask for people who do want it to write it (at which point we will happily accept it)." because that's not true!

(Your response again)

I further challenge you to point out where I put the presented patch down because I claimed that it is not the right way to handle the issue

Comment 139 Oh, and the fact that someone actually took the time to implement the preference for switching back to the old behaviour is a very nice surprise and I would like to thank nodashi for doing so (assuming the patch is yours). I have no intention of accepting such a patch because I still believe that is the wrong way to fix this and I would think it could be written as a plugin as well, but it at least shows a proper way of handling this situation and for that I want to commend you.

"I still believe that is the wrong way to fix this" (fix what? The user responses of upset users or the bugs in your code?)

Hope you are happy now that I actually can use STRG+V.

I have ignored *NOTHING* anyone here has said (at least not intentionally) and I would challenge someone to prove me wrong on this point. I whole-heartedly dislike the continued insinuations that I am not giving this the attention it deserves or that I am somehow failing to pay the due attention to ideas presented here. I am growing decidedly annoyed by these continued insinuations and would very much appreciate it if they were to stop.

I agree with you, you took yourself quite a lot time to DENY everything that's against your implemention.

I'm losing patience, so I tell you about the "pattern" in your posts and come to an end.

1) You patiently ask for comments about _improving_ your concept. 2) You deny everything that is against your concept with the same patient. 3) You put comments and complains down with the argument that you want your feature to suit all. Improving your code is the only thing you see.

I don't know if it is more clear if I explain it like this: You invented concept A that is in contrast to concept B. You constantly ask for improvements for feature A to make it A' that people like more. You are thinking that at a stage of A'''' it suits everyone, but this is NOT the case. You can improve your concept till the end of days but it's still concept A. And quite a few users don't like the nature of A.

quo errat demonstrator

I don't know an English phrase for it, but you are a person who itself put his own on an island, denying to make a step but continuing asking for reasons that would make him do a step.

Telling users not liking a concept is not an argument. Blame them that they should stop complaining and make suggestions how to improve feature A to make it suck less. But denying to put it down in a whole. You are a smart one!

comment:219 Changed 8 years ago by mortan

For people complaining about the huge amount of emails they receive for a thread they gave up: As deryni stated, train spamassassin / bogofilter.

comment:220 in reply to: ↑ 216 Changed 8 years ago by megaloman

Replying to kluvik:

Replying to ddm:

Replying to deryni:

Adding options for things which serve no purpose is not worth it, regardless of cost. I am still unconvinced that given a properly functional auto-resizing entry area there is any reason to need a manual resizing option.

I'm yet another person who signed up for an account here specifically to complain about this misfeature. I DO NOT LIKE AUTO RESIZING, AND I DO NOT WANT LIMITS OF ANY SORT ON MY TEXT INPUT AREA.

+1

+1 from me too

comment:221 in reply to: ↑ description ; follow-up: Changed 8 years ago by hobbified

Please please please fix this.

1) I use pidgin with my IM window and contact list side-by-side, taking up the full height of the screen. With the "single line" text input, it looks like complete crap.

2) Interactive elements in a UI shouldn't change their shape for no good reason. Having the input field resize itself while I'm typing is distracting and stupid.

3) The auto-resize seems to have failed to take into account custom convo font sizes, so if I set a font that's larger than the default, the input field will resize itself on the first character I type, and then resize itself back down again every time I send a message.

4) The whole braindead GNOME philosophy issue. My machine was set up for my best ease of use (and don't laugh, pidgin is an important part of my work environment). You've gone and made it worse, and made it as difficult as possible for me to make it better again. Stop doing that.

comment:222 follow-ups: Changed 8 years ago by Sim-on

i only want to highlight some issues, which does not seem to be clear for everyone:


1. There is a Plugin (#5296) and another pidgin-Version called "funpidgin" where auto-resizing is disabled. And you are free to use them or reinstall 2.3.1.


  1. We recognizes all criticism and we will try to realise them. So one of the main arguments against this issue in 2.4.0 was, that e.g. code-developers weren't able to send/format correct long messages, because the maximum height of 4 lines was to small. The maximum changed in 2.4.1. to half of the window-size. We changed this according to YOUR desires.

  2. Now people complain that 2 lines minimum is too small and that this doesn't look nice. Furthermore it is much more difficult to click in the input-area for a new message and/or to focus the window. So i already heard developers thinking about changing this, too. Would this help you?

comment:223 in reply to: ↑ 222 ; follow-up: Changed 8 years ago by kdorff

Replying to Sim-on:

  1. Now people complain that 2 lines minimum is too small and that this doesn't look nice. Furthermore it is much more difficult to click in the input-area for a new message and/or to focus the window. So i already heard developers thinking about changing this, too. Would this help you?

NOW we're complaining? I complained that two lines is too small back on 03/04/2008 at 12:56:24 PM and have complained about this issue several times. As much as the developers love their auto-sizing feature, I love the manual sizing feature. I hate the that autosize spazzes out the UI when it jumps. It just looks like crap. I am a stauch supporter of if they want to keep auto-sizing make it an OPTION.

If you absolutely must make manual sizing only via a plug-in, it should be distributed with Pidgin - there are 20 other plugins most of which do nothing for me, what's one more? Sure, there is a binary of the plug-in now (does it work with 2.4.1?) but for quite a while it was just source. How is having a plug-in any better than an option in Preferences? A click on one place vs a click in another place. That said, If they won't make it a preference I cannot imagine they will make it a bundled plug-in.

comment:224 in reply to: ↑ 223 Changed 8 years ago by hobbified

Replying to kdorff:

I hate the that autosize spazzes out the UI when it jumps. It just looks like crap. I am a stauch supporter of if they want to keep auto-sizing make it an OPTION.

If you want some perspective on it, look at it this way. Auto-sizing should be filed under "stupid window tricks", along with smooth-scrolling. Smooth-scrolling that the devs insisted for ages was a great idea until they finally capitulated and added an option that allows users to restore pidgin to consistent behavior and removes irritating graphical glitches. In the backwater swirling, there are some things that will never change.

comment:225 Changed 8 years ago by dbeusee

Replying to mortan:

...

Very nicely said, but I think all our comments have fallen on deaf ears, or should I say, non-caring and non-compromising developers. sim-on has re-enforced their non-caring/non-compromising nature in his latest reply:

Replying to sim-on

1. There is a Plugin (#5296) and another pidgin-Version called "funpidgin" where auto-resizing is disabled. And you are free to use them or reinstall 2.3.1.

Still "our way or the highway", it seems. This what you call "compromising"?? This is what you call "we care"??

We want manual resize built-in the base program that is easy to activate (by default ideally, or at least a very easy to find option - ideally right there on the conversation window) and provided for out-of-the-box (on install of pidgin - not via additional download and install, not by recompiling, etc).

If we didn't mind relying on a fork like funpidgin just for this little, but basic UI functionality, we would not need to keep arguing with you guys here. I am using funpidgin, but I shouldn't have to. We are still waiting for YOUR compromise (a plugin - whether installed with pidgin or not, a fork, a "bug-fixed" auto-resize, a previous version... are not compromises). We want manual, you want auto. Can we meet in the middle via an OPTION? PLEASE? Can you guys just show a LITTLE flexibility?

Replying to ccb:

The FunPidgin link came up empty...

Get it here: http://sf.net/projects/funpidgin/

comment:226 in reply to: ↑ 221 Changed 8 years ago by daihard

Replying to hobbified:

Please please please fix this.

3) The auto-resize seems to have failed to take into account custom convo font sizes, so if I set a font that's larger than the default, the input field will resize itself on the first character I type, and then resize itself back down again every time I send a message.

That happens to me too when I type in Japanese. Apparently the default Japanese font is larger than the English one; the text input area automatically resizes as I type in Japanese, and it will shrink back to the original height once I hit the return key to send my message. If it matters, the OS is CentOS 4.6. The version of Pidgin is 2.4.1.

The "auto resize" feature itself is bearable to me, although I'm still not used to being unable to resize the text input area myself. The problem hobbified and I described above -- that's something I cannot stand.

comment:227 in reply to: ↑ 116 Changed 8 years ago by kluvik

Replying to ConnorBehan:

For those of you revering to 2.3, this solution will work for awhile but eventually you are probably going to want new features that Pidgin developers introduce. I have created a fork for this purpose called "funpidgin" which is on sourceforge.net (http://sourceforge.net/projects/funpidgin/). It is my first software project and I'm hoping it will be a lot of fun. If it gains a serious following, it can have a more serious name.

It seems the dispute can last forever without useful results. And such 'features' could be arised whenever another one brilliant idea will be made by a developer of pidgin. I believe there is only one solution for the pidgin's community, we have to move to this fork.

comment:228 Changed 8 years ago by msoltyspl

As for "we can't have auto-resizing and manual control" at the same time - how can you even think that forcing *any* type of automation is better than leaving it under manual control ? Have you been using microsoft products too much ?

  • having manual control is useful and natural thing to have. Especially for unix-minded people. And this particular feature (should it even be called as a feature ?) has been in gaim for ages.
  • forcing auto-sized typing area (or for that matter, forcing anything that could be set manually) is not a progress. It's a regression.

Why did you even bother wasting time to implement it ?

To make a blunt and ugly example: Do you consider office 2007 a progress ?

It actually reminds me about the change you forced from 1.5.x versions, where user's avatar was nicely placed to the left of the typing space (and could be turned off for those that didn't want it). It was excellent and far better than what you have now (and probably simpler in code, considering functionality of that tiny, pointless top-right thingy)

I can live without that (I don't understand the point of current implementation), but removing manual control in favor of automatizm is just crazy.

You're not making any progress in UI department with things like that. Of course it's my opinion, but looking at this wall of comments, I guess many people would agree.

comment:229 Changed 8 years ago by dexx

My god!! Please change it to an option! It's either that or I'm uninstalling pidgin, the auto-resize is just to damn annoying to get used to!

comment:230 Changed 8 years ago by bagatonovic

I think the pidgin devels are using this ticket as a form of amusement. Since my last post I have given up on Pidgin. I'm using https://www.meebo.com for IM. Yeah it sucks that I have to keep my browser open for IM, but if I open it in a tab its actually pretty cool. The reason why I will not be going back to Pidgin is that the team has showed the community what they think of us. I'm certain this isn't the last time they'll make some kind of terrible change to Pidgin and refuse to change it back. I don't have time to deal with it. Good bye, Pidgin.

comment:231 in reply to: ↑ 222 Changed 8 years ago by ddm

Replying to Sim-on:

i only want to highlight some issues, which does not seem to be clear for everyone:


1. There is a Plugin (#5296) and another pidgin-Version called "funpidgin" where auto-resizing is disabled. And you are free to use them or reinstall 2.3.1.

These issues are perfectly clear to me, and have been since before my first post. Let me say that none of these are real solutions (at least, not currently). Allow me to explain:

  • The plugin solution could work if it were part of the standard distribution of Pidgin and the user were able to enable it via preferences (i.e. it behaves like an option, and I don't need to do anything special to get it). Otherwise, it will be left up to the user to do manual maintenance of their IM client. Considering the clear outcry from the user community, leaving this up to them to maintain means the user will need to spend considerable effort to ensure they have the latest version, for security fixes, bug fixes, and interoperability with the latest pidgin release. In the modern world, IM is one of the key features of an OS, and asking the user to do this much to maintain a key feature seems clearly wrong. It places an undue burden to avoid bugs and security issues in a key desktop application. This feature is a basic, fundamental part of Pidgin, and as such it should be included with the distribution.
  • Realistically, the fork project will probably die fairly quickly. This happens a lot with forks (mutt-ng comes to mind, as do others). We can't count on it being available, current, or even usable; and in the grand scheme of things, it is stupid to waste all that effort on maintaining a fork just because of one small but horribly offensive feature.
  • Downgrading to 2.3.x and remaining on it is a foolish suggestion. As always happens, someone will discover bugs, and most likely security problems, which will remain unplugged in older versions. Users who feel tied to old releases due to this misfeature will not be able to avail themselves of new features, and will soon enough find themselves running broken, insecure code.

But, my dear developers, it should be a clue to you how much people really do hate this feature, that not only did someone make the effort to write a plug-in to restore the old behavior, but someone is actually willing to maintain an entire fork of your project, over this distasteful choice that you've forced on us. What more do you need to convince you that your unwavering devotion to this new functionality is a disservice to your user community?

  1. We recognizes all criticism and we will try to realise them. So one of the main arguments against this issue in 2.4.0 was, that e.g. code-developers weren't able to send/format correct long messages, because the maximum height of 4 lines was to small.

That, as you yourself point out, was only one of the main complaints. Another of the main complaints, even from very early on, was that this feature should be made optional. It should be obvious that a person making such a comment prefers the old behavior, and does not want the new behavior.

Comment #4: "Having the program work some magic seems cool, but users should be given the option to activate the feature."

Comment #7: "The automatic resizing is unacceptable."

It seems to me that the devs are only hearing what they want to hear; they are blocking out all of the comments indicating that no matter how they decide to adjust the new functionality, for a substantial percentage of us, it will still be unacceptable unless we're given an option to use the old functionality, *in the default distribution of pidgin*, be it by plug-in or otherwise.

There is an old adage which goes something like, "For every complaint you receive, you should assume that at least 10 more people have the same complaint." If we assume that's true, then the number of people upset by this change is at least around 1000, based on this forum alone.

Many people who are irritated by this feature will not complain about it, for many possible reasons. They may simply not like to complain. They may see that lots of people are already complaining, and feel their voice is being heard. They may see the reaction from the developers, which appears to dismiss their desire to have the functionality reverted, and not bother to post because they've given up hope that it will be fixed. They may feel that, even though they are irritated, their time and energy is better spent on something else. They (especially users relatively new to Linux and/or pidgin) may not know how to complain in a way that will reach you. They may be irritated, but not enough to provide incentive to complain. But, one thing that is true is that even though they don't complain, they would still be happier if the behavior were reverted. It may even be that they *are* complaining, but just in the wrong forums for you to hear about it.

https://bugzilla.redhat.com/show_bug.cgi?id=436010 https://bugzilla.redhat.com/show_bug.cgi?id=440437 http://ubuntuforums.org/showthread.php?t=739573&highlight=pidgin+resize https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/209553 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469109 http://geektimelinux.com/page/7/?q=node%2Fview%2F12 (mentions funpidgin and this problem) http://www.linuxquestions.org/questions/debian-26/pidgin-convo-box-all-messed-up-627921/

The wikipedia article even mentions this in the 3rd paragraph of the features section:

http://en.wikipedia.org/wiki/Pidgin_(software)

If one cared to dig, it would not be too difficult to find more places people were complaining about this than just the list above. The net is rife with complaints about this misfeature.

The maximum changed in 2.4.1. to half of the window-size. We changed this according to YOUR desires.

Not MY desires. My desire, my ONLY desire, is to have the old behavior restored.

ddm

comment:232 Changed 8 years ago by mlsterben

What he said. Very well put, sir.

comment:233 Changed 8 years ago by DSK

[and another user having registered for the sole purpose of complaining about this 'feature']
Why is it that you want to _force_ such a change of one of the most substantial elements in an IM on your users? The current behaviour is a misfeature because of several reasons:

A program should follow the `Law of Least Astonishment'. What is this law? It is simply that the program should always respond to the user in the way that astonishes him least.


A program, no matter how complex, should act as a single unit. The program should be directed by the logic within rather than by outward appearances.


If the program fails in these requirements, it will be in a state of disorder and confusion.

Another article on the principle of least surprise

It absolutely goes against the principle of the least surprise. I will expect, that an area in which I can enter text, to be static. I will expect that, because it is just like that in every other program there is out there, and has always been. And even before that, when we still had to write on paper, the area in which I could write was static in size. Principally users will see all input fields the same - be it in an editor, e-mail client, mobile phone, or an input field in an IM. And I _never_ ever would want my editor to just resize itself in the progress of writing.

It's a consequence of the fact that human beings can only pay attention to one thing at one time (see The Humane Interface [Raskin]). Surprises in the interface focus that single locus of attention on the interface, rather than on the task where it belongs.

The primary task while working on any arbitrary input area is writing. There might be the additional task of reading what has been previously written. Now with an automatically resizing input field, there comes the additional task of refocusing because the input area suddenly grows and thus the chatlog area shrinks - maybe making stuff I was currently reading disappear. And now it has completely destroyed my flow of work. I have to scroll up again, which in itself already needs the task of moving away my hand from the keyboard to the mouse, and back - and alas! You've got the user completely annoyed. Probable solution there would be to make the chatlog area stay the same size and make the window itself grow. [Just the idea of that just makes me shrivel, apart from maybe not even being possible programmatically.] Now the program gets absolutely intrusive, maybe blocking the view of what was behind the chat window, doing something completely unexpected, in expecting to be the only program that's running - no good. In no way. Furthermore, you're being absolutely obstrusive in expecting to know what the users want. Or, even worse, expecting the users to not know what they want - making them feel stupid, or incapable of making decissions of their own.
If you feel like providing a user with a special, and extraordinary feature - give them an option field to turn it on [_opt in_]. _Too_ many options might be a bad idea because they might overwhelm the user, when not being presented in a way that will make him feel like having a lot of control without having to do much. And users - being mostly human as of yet, love control. Everything else will make him/her feel constricted. And Pidgin is far from having too many options. Users like to be able to tell a program how to behave.

Here another article that might be interesting for you:
http://www.osnews.com/story/6282/The_Command_Line_-_The_Best_Newbie_Interface_/
Derived from that article, you will see that users like to work with something that is less intelligent than them. Not behaving less intelligent, as in not being able to tell exactly what the user wants.

You're putting a Sisyphean task on yourself there, chasing to improve your implementation in trying to reduce the ways in which the autoresizing input field can behave in a way that would be unpleasent for the user, probably introducing other ways in which that will be the case; trying to make an extraordinary feature suit for everybody. DWIM is not feasible yet. Yet. Do a decent implementation of a DWIM interface, and I - and surely all other people, will go happily along. But trying to do that - no, sorry; trying to force that on users, as in giving them no other choice than to use that anti-feature - when there has been a most reasonable and satisfactory solution for that all along - let the user decide on the size of the input field, and let it be static - is not something to go with.

And if a feature just does not seem sensible, do not be afraid to throw it away.

DSK

comment:234 Changed 8 years ago by aine

A longtime Pidgin user, I registered for this site for the purpose of adding my own datapoint to this discussion: a UI change is badly needed here.

At the very least the default size of the input area should be proportional to the size of the window it's in. A tall window on a 24-inch monitor with a two-line input area? Awful.

Keep the goofy auto-height thing, but at least give me 25% for input, 75% for messages by default. And bring back manual resize. Even though I KNOW it does not work, I still find myself trying it.

comment:235 Changed 8 years ago by loufoque

I also just registered to request for this bug to be fixed.
Because of this new "feature" I had to drop pidgin for another IM client, which is fairly sad.

I want static size, not dynamic.
Dynamic resizing is obviously obtrusive, as all the comments here have already stated.

comment:236 follow-up: Changed 8 years ago by hbons

"At the very least the default size of the input area should be

proportional to the size of the window it's in. A tall window on a 24-inch monitor with a two-line input area? Awful.

Keep the goofy auto-height thing, but at least give me 25% for input, 75% for messages by default."

I think this is a good point and a good solution.

comment:237 Changed 8 years ago by kdorff

I think, at this point, the developers of Pidgin must be taking a psychology class... take away a feature everybody who uses IM knows and uses and replace it! Then largely ignore the community, watch the chaos, write a term paper about it. Another absurd option: The Pidgin developers must feel they have too many users, thus have no real interest in what their opinions are.

hbons and loufoque: You say 25%/75% is right and will hake you happy. But why is that any better than what is in the auto-resize? Pidgin developers want 2 lines, you want 25% of the space. Why should the developers dictate the size? Why should you dictate the size (at 25%). We have a perfectly good solution: make the size of the window the size that YOU want it. Why would we continue to regress to "just make it 25%/75%" and make the software even more unusable?

The fact that they have a perfectly good solution (make auto-resize an option) and they continue for almost a month and a half to "just not care" is ridiculous. I loved Pidgin and I preached the religion to everyone I met. Now they are coming back to me and I have to propose other solutions. Half a dozen people I know have switched from Pidgin just because of this feature because they don't see it coming back. They aren't has happy with the alternatives but the auto-resize is just too annoying. Obviously, I completely agree with them.

comment:238 Changed 8 years ago by loufoque

I never said I thought 25% was right.
I want static size and the ability to choose the size myself with the usual resizing method.

comment:239 Changed 8 years ago by hbons

"hbons and loufoque: You say 25%/75% is right and will hake you happy. But why is that any better than what is in the auto-resize? Pidgin developers want 2 lines, you want 25% of the space."

I don't want 25% of the space necessarily. This is a solution for people with very high res screens. On second thought, those people should just increase their font size.

comment:240 Changed 8 years ago by kdorff

loufoque: Sorry, I was attributing aine's message to you, copy and paste error.

I don't really figure either aine or hbons really want 25%, I just wanted to point (mostly for the developers) the fact that setting the input size to ANY set size will never make people happy. Bring back the manual sizing.

comment:241 Changed 8 years ago by sylock

I add my voice to support the come back of this feature.

comment:242 Changed 8 years ago by ogre_x

I also consider this a regression bug in 2.4.0. If you want to add a new feature like automatic resizing it should not be default, but optional. Bring back the manual resize function and make it the default behavior.

comment:243 Changed 8 years ago by ionoff

bump, it should be optional, even if enabled in this way by default.

I personally prefer a larger input box or a fixed input box size more for aesthetics.

comment:244 Changed 8 years ago by Ionic

First of all, I want to state, that I am of course against this "feature improvement", which indeed is no one. The old behavior with the static size was just fine, I do not understand why the developers again think, that they [b]mustb improve a thing, which was already ok and nobody ever complained about. Instead, you should/could just fix other bugs or add new functionality, which is, NOT remove any freedom. This is far not the first time, just think of the protocol icons removal, which was just as unnecessary as this one. Of course, one can live with that, but I still do not, and probably never will like it. Showing some sort of procotol icons is not confusing any user, it is indeed even easier to search for a specified person. For example, if you have the same person on three protocols, but want to communicate over just ONE, and the user has the same nickname everywhere... it's a pain to first search for the nickname and after this hold on, drop your mouse about the entry to SEE which protocol this is. Do you really want to call this an improvement? Whereas a few time ago you just to had a quick look at the icon - "Oh, it's the wrong one, so I'll just scroll down in search mode to get to the other entry." I do not.

Okay, sure, this has nothing to do with THIS problem now, but it shows some kind of unlogic thinking of a couple of persons which is still alive and will get even worse.

Guys, please, stick to [b]your ownb motto and fix existant bugs, there are enough, or implement really useful features. Some time ago, finch was not even capable of using other console charsets than UTF-8. I don't know whether this is fixed yet or you are "still waiting for patches" for that and instead decided to remove old features and to replace them with your own "automagic" style. On the other hand, I see your spent freetime on this, without any financial support from anyone, but I tell you to not use this time for unnecessary things either.

I hope you also saw, that there were a few real arguments in it and not only the "I don't like it !! 1 !!11 1" thing you might be experiencing often. Of course, without any "real" feedback, it is hard to believe that my own improvement was bad. But keep in mind, that nobody is perfect and even you can make a wrong decision. And also remember of the peer presure in the group which will let also other developers change their mind and say, that this is the [b]best improvement ever[b].

Now, back to the topic.

Look, I have been playing around with it for a while. First of all I was astonished by the small size of the input box and thought, that you even might remove multiline boxes (which would have been a real PITA, of course.) But after writing some lines in the box, I saw that it has been dynamically resized. So, on my Laptop, the edit box can become the size of 10 lines and the text output gets only 6 lines. To be honest, this is crap. Even if the feature might be a good one (though, sorry, I do not see any improvement in it, but rather many disadvantages, like: the redrawing has to be done after adding one line mostly and will affect the whole window... it DOES flicker, it DOES consume CPU power and it DOES NOT look well.), the current implementation is horrible. I see the text output much more important than the edit box, thus the output should be in [b]anyb case bigger than the input box. To reach that goal, I personally would do it this way: the combined size of output and input form 1/1, thus 1 in my calculation. The output box should get AT LEAST 2/3 of the total size. It is the most important window box and so it "deserves" the biggest size. The input box should contain two lines initially and as most 1/3 of the total size. So, when you have 15 lines in total, you would have at least 10 lines for the output box and at most 5 lines for the input box. In the "worst case", we still would have a split of 2:1 for the output box, and that is, what would be really cool. Some people have already spoken about 25% and so on, but I guess my idea is the fairest one. It is right, Pidgin is an IM client and no text editor. Thus the most important thing there is the conversation - or in other words the output box. Doing the 2/3:1/3 thing is the most convinient solution for an IM client, I guess.

The best solution, however, would of course the the reversion of these changes to the input box and just letting people arrage the box how THEY want.

My two cents (which will be, I guess, either ignored or thrown into trash anyways.)

-Ionic

comment:245 follow-up: Changed 8 years ago by dbeusee

With auto-sizing, I don't agree the output is more important when you are typing away. You have seen the output already, and you can scroll it. I rather have a 90% cap in the input size.

One thing should be obvious by now... The way to make EVERYONE people happy is with OPTIONS. Most want manual sizing and would be perfectly happy with NO auto-sizing at all, but we are willing to meet 1/2 way by putting up with it if it is an OPTION that can be turned OFF. And if you want more people to use auto-sizing, have the min and max be OPTIONS, AS WELL.

Are you developers LISTENING? I mean REALLY LISTENING to us? If you care, please SHOW US you care. Restore manual sizing and put this ticket to rest!

-Don

comment:246 Changed 8 years ago by mlsterben

The short version of the above comment is simply the name of this ticket. Allow me to reiterate:

Automatic chat input field resizing should be

OPTIONAL

comment:247 in reply to: ↑ 245 ; follow-ups: Changed 8 years ago by hbons

Replying to dbeusee:

[...] but we are willing to meet 1/2 way by putting up with it if it is an OPTION that can be turned OFF. [...]

Wow that's really nice of you! Now only the developers need to code this right? I can't believe some of the attitudes in here.

comment:248 in reply to: ↑ 247 ; follow-up: Changed 8 years ago by mlsterben

Replying to hbons:

Replying to dbeusee:

[...] but we are willing to meet 1/2 way by putting up with it if it is an OPTION that can be turned OFF. [...]

Wow that's really nice of you! Now only the developers need to code this right? I can't believe some of the attitudes in here.

I can't believe how big of a baby you're being. I swear, some people are so protective of their follies they start thinking their farts don't smell.

Give me one good reason why you cannot make this an option, either via a plugin or in the preferences. Not why you don't want to or why you don't feel the need to, but why you cannot.

comment:249 Changed 8 years ago by rekkanoryo

  • Resolution set to wontfix
  • Status changed from reopened to closed

I'll put this entire ticket to rest quite simply. We are not reverting the automatic resizing. This ticket is being closed with the resolution "wontfix".

comment:250 Changed 8 years ago by mlsterben

Dev: Waaahhh, Mommy, people don't like what I did! They're saying they shouldn't have to use what I made! Mom: Now now Devvy, you should be nice to everyone. Dev: No! I'm going to make this problem disappear by ignoring it! They'll forget eventually. Mom: ....What sort of monster did I raise!?

comment:251 in reply to: ↑ 248 Changed 8 years ago by hbons

Replying to mlsterben:

Give me one good reason why you cannot make this an option, either via a plugin or in the preferences. Not why you don't want to or why you don't feel the need to, but why you cannot.

Well I certainly can't because I'm not a programmer. :) Technical problems are almost never the reason. You really think the devs can reverse engineer secret propietary protocols and not make it an option in preferences?

comment:252 Changed 8 years ago by mlsterben

I'm not a programmer either, so I'll say sure.

comment:253 follow-up: Changed 8 years ago by ionoff

Boo, will this be rejected if I make the change and post it for inclusion?

It is not worth the time to make a change just to have it rejected, and not worth the effort to fork to keep up the project.

I have been screwed in the past having to maintain a project fork just to add features that were removed.

comment:254 in reply to: ↑ 247 ; follow-up: Changed 8 years ago by hobbified

Replying to hbons:

Replying to dbeusee:

[...] but we are willing to meet 1/2 way by putting up with it if it is an OPTION that can be turned OFF. [...]

Wow that's really nice of you! Now only the developers need to code this right? I can't believe some of the attitudes in here.

Nope! They don't have to code a goddamn thing, that's already been done. They just need to quit being assholes, and learn that despite their assertions to the contrary, the users are actually the most important part of open source, especially the users who are motivated to contribute, and that ignoring them spells death.

However, I don't think any of the devs are likely to realize that, so I'll say again that what they really need to do is retire. Disband the secret cabal and let the maintainership pass into the hands of people who actually have an interest in improving the product, without the trouble of forking.

comment:255 in reply to: ↑ 254 ; follow-up: Changed 8 years ago by hbons

However, I don't think any of the devs are likely to realize that, so I'll say again that what they really need to do is retire. Disband the secret cabal and let the maintainership pass into the hands of people who actually have an interest in improving the product, without the trouble of forking.

How is that different from a fork?

comment:256 in reply to: ↑ 255 Changed 8 years ago by hobbified

Replying to hbons:

However, I don't think any of the devs are likely to realize that, so I'll say again that what they really need to do is retire. Disband the secret cabal and let the maintainership pass into the hands of people who actually have an interest in improving the product, without the trouble of forking.

How is that different from a fork?

"Fork" implies two concurrent, "competing" streams of development; change of maintainership means only one. It's the difference between the VPs leaving to form their own company, and the board forcing the president to step down, to use quite a loose, inappropriate metaphor.

comment:257 Changed 8 years ago by EvilJohn

"I'll put this entire ticket to rest quite simply. We are not reverting the automatic resizing. This ticket is being closed with the resolution "wontfix". "

Lame Choice. Lame attitude. Fun Pidgin it is. This project should be renamed "facist pidgin" so the users don't get confused.

comment:258 in reply to: ↑ 253 Changed 8 years ago by Ionic

Replying to ionoff:

Boo, will this be rejected if I make the change and post it for inclusion?

It is not worth the time to make a change just to have it rejected, and not worth the effort to fork to keep up the project.

I have been screwed in the past having to maintain a project fork just to add features that were removed.

Replying to ionoff:

Boo, will this be rejected if I make the change and post it for inclusion?

Yes, it will.

The problem is not that the developers could not make it an option, but rather that they do not want. In fact, the old behavior is still out there, when thinking of the code. Surely it would not be too difficult to check for an option and depending on this change the handling.

The most difficult part here is, was, and will be the mentality of people. Heck yes, they even hacked proprietary protocols. It should be no problem to implement such a feature. But rather than that, some people like to waste their time with other stuff...

Replying to EvilJohn:

Lame Choice. Lame attitude. Fun Pidgin it is. This project should be renamed "facist pidgin" so the users don't get confused.

To be honest, I as a Pidgin developer would not do that either, when I see SUCH comments. People should stay on topic and not insult the ones doing all the work.

See, if there is nothing but rants, would you still have the desire of doing somethings for those users and users in general?

I would not, YMMV.

The same thing goes to mlsterben etc. There is no point in leaving such comments here, rather than it will fix developers to their decision just more.

Replying to hbons

Wow that's really nice of you! Now only the developers need to code this right? I can't believe >some of the attitudes in here.

I do not see the problem. As you said yourself, it would be not a piece of hard work for them. They even still have the code of the old behavior, so there would be no complete rewrite needed. Which attitude should we show? Even you have said, that...

Replying to hbons

Well I certainly can't because I'm not a programmer. :) Technical problems are almost never the >reason. You really think the devs can reverse engineer secret propietary protocols and not make >it an option in preferences?

this would be no problem, but what then?

-Ionic

comment:259 Changed 8 years ago by mlsterben

It's obvious that reason will not reach the developers, so I turned to calling them babies. I still stand by that notion.

comment:260 follow-up: Changed 8 years ago by Ionic

Replying to mlsterben

It's obvious that reason will not reach the developers, so I turned to calling them babies. I still stand by that notion.

Doing so will not only make the devs stick to their opinion, but rather also disqualify you as an idiot and by that not only you, but also other users. Please, this is a field full of diplomacy. If you do not want to show this kind of stuff - it is ok, but please do not post any insulting comments anymore.

As you should know, there is kind of the same rule also in nature. When not doing anything to animals but leave them in peace, they will not attack/harm you. Though, if you attack them, they will fight back. Do you see my point?

We do not need insults and rants, we need ideas and the ear of the devs. 8 postings containing insults out of 10 are rather cutting down that ear (if not already done so - "wontfix".)

I hope you all understand this and are willing to discuss, not to abuse.

If so, you are welcome (and also the devs to reopen the bug for now.)

-Ionic

comment:261 in reply to: ↑ 260 Changed 8 years ago by hobbified

Replying to Ionic:

As you should know, there is kind of the same rule also in nature. When not doing anything to animals but leave them in peace, they will not attack/harm you. Though, if you attack them, they will fight back. Do you see my point?

Yes, we see that you have no grasp on reality whatsoever. Or at least you know nothing about animals and should avoid them in future metaphors.

comment:262 Changed 8 years ago by mlsterben

Hey now, I tried being diplomatic. If you use your browsers Find function, you'll see that I was the third person to post and started out very level-headed. Then as the days rolled on I grew less interested and more annoyed simply by all the e-mails. (I still haven't figured out how to disable those)

Now I'm just tired and cranky. Finals are coming close and seeing every developer whine in his own unique way is getting old. After the little bitch move called "wontfix" I have determined that no matter what anybody says or does at this point is irrelevant and inconsequential. I'm happily using the 2.4.0 fork at the moment that lets me choose the size I want.

But anywho, if you want me to get on topic, fine.

I am a scientist and a writer. Because I am known as a notorious grammar Nazi, many of my friends turn to me to edit the spelling, sentence structure, et cetera in their papers. The fastest way they always figure is to send the whole essay over IM. This takes up quite a bit of space and when I need to edit large portions at a time, I need a large window. It's that exact situation where I want to make the input box take up 90% of the screen. As far as science goes, I need to put in chemical equations. Because GAIM has limitations as far as sub- and superscript go, a LOT of extra characters are needed. For example, glucose has to be written "C_6 H_12 O_6." This gets lengthy. Two lines are too little and I want to see the whole equation at once, without having to scroll.

Are you happy now, Ionic? In addition, Hobbified made me laugh. After reading that sentence from Ionic I was thinking about all the animals out in nature that will attack indiscriminately, such as army ants, jellyfish, or tigers. (Tigers are territorial, but meh. They don't like it when you get in their turf)

comment:263 Changed 8 years ago by loufoque

Where may I find that fork?

comment:264 Changed 8 years ago by ConnorBehan

This is unbelievable. I tried adding my support to this sensible ticket, hoping all of us would cumulatively hold some sway over the developers (there are now three times as many posts below my first post as there are above).

I tried discussing this in IRC but the biggest promise I could get was elb saying that we might get manual resizing back if people are still complaining about this in three years (I was later blocked from #pidgin). This "wontfix" position has me even more worried now.

I tried letting it rest. Clearly many people replying to this ticket are much better at articulating their opinions than me. I had made my position known and there was no point belaboring it.

So we're only making it worse by complaining? Then what should we do... NOT complain? We are in a no win situation here.

If we had kept our mouths shut, respected your so called wisdom and refrained from getting involved... would you have really said "We will bring back auto-resizing because it looks like the users are considerate enough to deserve our attention." Absolutely not, you would not even know that people hated the auto-resizing if this were the case.

Now lets say most people kept their mouth shut but maybe 10 people or so posted well thought out constructive criticism on these forums. Then you would say we are a "vocal minority." I heard those exact words used on IRC. According to Ethan Blanton, some people did request an intelligent text box that you didn't have to resize. I'm not sure how many people requested this but something tells me it wasn't a majority either. If you really require a majority vote to revert a feature you are looking at over a million users.

Ok so getting the majority of Pidgin users to voice their opinions is not realistic, so we did the next best thing. We got a good one hundred people to respond to this ticket. It may not be a million but we did our best. Now what are you telling us? That our attitudes are so ungrateful that you are losing interest in reverting the feature?

What if by some miracle, hundreds of people HAD replied to this forum but had kept their cool and discussed the matter logically for these two months without getting impatient? Then you would say what seanegan already said... that users were just repeating "the same tired old points."

So if we complain, we lose, if we don't complain, we lose. Is there any way we can bow down to you and earn enough of your respect for you to consider this tiny code change? Of course not, there is no way to convince the developers that manual resizing is better. Their vision of what Pidgin should be is non-negotiable and every response to this ticket (the kind ones and the not-so-kind ones) has only reinforced that they are the ones in charge and that there is absolutely nothing we can do.

Gaim has always been very special to me. It was only the second open source application I ever used (after Firefox) and played a huge role introducing me to the world of GNU/Linux and other free software. Perhaps I am just afraid of change, and could eventually get used to auto-resizing. But now I am going to send one of your questions back down this two way street. I am not going to be open minded about auto-resizing because YOUR attitudes have not convinced me to change my lifestyle this way.

Alas, there is no way to restore manual resizing to the main branch of the program we used to love. Sure there are probably thousands of us who would be happier with manual resizing, and sure we helped make Pidgin what it is today, but the developers don't work for us, they work for themselves. We are just a bad case of FSUES.

I would rather let the user decide what features go into a program. Naturally there are limits to this... we don't want Pidgin to be a text editor, a web browser, an newsreader and an email client but we DO want manual resizing. Refusing to add our much requested feature isn't wrong... the developers have every right to develop the program how they see fit without giving a damn about anyone else... but it isn't what I would do.

For many of us this was the last straw. Other users will probably leave in the future, when they update to the newest version of Pidgin or when they get offended by poor UI choice after poor UI choice, but for me this is the last straw. Life is full of disappointments that cannot be changed but luckily this is one of the rare cases where a completely desirable solution is in my reach... and I intend to take advantage of it.

Unless the Pidgin developers bring back manual resizing among other things and change their entire philosophy in general, you can rest assured that I will maintain Funpidgin for the rest of my life. Even if I never learn enough programming to add advanced improvements, I will make sure the simple changes I have already made are matched with each new version of Pidgin. Even if all of my work is made available in plugin form (like nodashi's manualsize), I will still make sure Funpidgin is distributed WITH these plugins. Even if I am the only one using Funpidgin, I will keep it updated because Pidgin has had a profound effect on my life and I am not about to let it go.

So that is my last rant on the issue. Future posts to this ticket will only be to alert people of new releases of Funpidgin and such.

In case anyone doesn't know, Funpidgin 2.4.1 is http://funpidgin.sourceforge.net|out. Look for "Entry area manual sizing" in the plugins list!

comment:265 Changed 8 years ago by ConnorBehan

Looks like I screwed up that link, Funpidgin: [funpidgin.sf.net]

comment:266 follow-up: Changed 8 years ago by loufoque

Maybe the developers simply think the preferences panel should be as simple as possible and not bloated with lots of options. That's quite understandable.

Just make an advanced configuration editor for power users.

comment:267 in reply to: ↑ 266 Changed 8 years ago by ionoff

Replying to loufoque:

Maybe the developers simply think the preferences panel should be as simple as possible and not bloated with lots of options. That's quite understandable.

Just make an advanced configuration editor for power users.

I do agree that the developers have the right to choose what to add and what not to add. It just means a fork gets created to support what some feel may be better for them. I suggest we all stop complaining, since it wont get fixed here.

After saying that, I do feel this feature should be an option, and I love funpidgin's implementation of the option in plugins. Hopefully the fork will keep up and live long. Long live Fun Pidgin :) [although the site needs a few fixes, missing links]

I also agree with the statement above about keeping the options clean, but the plugin location is a pretty good location for this option, although it is not an intuitive location or name.

The pidgin auto-resize can be good in some situations, but not all.

Pidgin Team, Thank You for all you have brought and will continue to bring.

Fun Pidgin Team, Thank You for making it fun and implementing the features users want.

comment:268 Changed 8 years ago by kdorff

Kudos to the FunPidgin folks: It is working nicely.

comment:269 Changed 8 years ago by aflores

I registered just so I could comment on this ticket. I know that this issue has been discussed at great length, but I'd still like to voice my opinion, even if the ticket has already been marked "wontfix".

I also miss the ability to manually resize the text input area. It seems unreasonable to not include this as an option. Please include this as an option. In the meantime, I guess I'll just have to use funpidgin or trillian.

comment:270 Changed 8 years ago by TacBoy

I can highly recommend funpidgin since this is "wontfix". Not only does it resolve this issue but also lets you put the typing indicator back to where I prefer it (not adjusting the message area) and allows me a send button which I also prefer but was deemed not necessary by the developers.

comment:271 Changed 8 years ago by rfgiusti

It AMAZES me the developers have decided this ticket should be "wontfix". Over 270 responses for this ticket, 8 other tickets related to what many users consider a defect, and the developers can't see THIS WAS A BAD IDEA! Sorry, Mr. Ethan, but you're wrong. You've got lots of constructive criticism, many suggestions, complains, patches, a fork and you still act as the guy who just had the best (but misunderstood) idea on Earth!

I know options are expensive. But when a change in the UI makes this so many people unhappy about your software, something must be wrong.

I also know it must be very disappointing to be a developer and get the "I don't like the new <feature>!" kind of response. But, first of all, that's not the totallity of your feedback here. Second, if users don't like the changes you make to your software, and they do whatever they can do to tell you, why should you not listen to them and consider that a bad opinion? After all, the only reason you guys are the developers of one of the most used IM is because users like all the <feature>s of your IM, right? What would happen if your users were to hate all your new <feature>s? One thing is sure: you certainly would not be "The Developers" anymore... instead, woul'd just be "the developers of that software with a funnny name no one uses". And I'm sure that would not be very fun for you.

I hope you guys understand. I'm not saying you guys are forced to do what I think you should do. I'm just asking that you listen to your users. We've been with you for a long time helping make Gaim (and then Pidgin) be reckognized as a great software and we would like it to continue that way. And it's pretty obvious to me that we want and that many of us feel like we need that new feature to be optional.

comment:272 follow-ups: Changed 8 years ago by DanLivingston

Well, let me first thank everyone for contributing their feedback to this tracking ticket.

I teach "Collaboration in an Open Source World" at a local college. I have been searching for, and in this ticket have found, a perfect example where communication between open source developers and users fails at multiple, fundamental levels.

Obviously, the motivations of open source developers are varied; some do it for technical enjoyment, others enjoy knowing they are contributing intellectual capital to a better world. The problem is when the motivations of open source developers conflict with the expectations of users.

Consider every wildly successful open source project: the users are enthralled with their ability to perform new activities in ways previously unimagined. Rabid dedication grows, and an evangelical fan base results. Pretty soon, it's obvious why users would not want to go with non-open source software alternatives.

What happens when those same newfound powers are taken away? What happens when the developers impose their personal dogmas upon the project? Even for as small an issue as chat window resizing, a minority (or majority) of users will emphatically express dissent.

It's easy to see why open source developers could develop dogmas. Some like to fantasize about the theoretical limits to which a design may become "pure", developing a vile repulsion to anything which steers away from purity. Others become obsessed with metrics such as maintenance effort per line of code, even though they often worry about features and lines of code which only contribute to 1% of the complexity of the application. Yet others develop fixation on "ultimate user simplicity", feeling that two options are better than five options which deliver more power. 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."

The initial lure of open source software is that quality software should resoundingly meet the needs of users. As demonstrated up until Pidgin 2.4, the fan base has emphatically been extolling the virtues of Pidgin. But when developers take a feature away, presumably to implement a "better version", and that better version in fact is a step backwards from the functionality previously available, they had better have a damn good reason. Such a reason is lacking here.

"This is how IM should be used." "Our design is better." "We will only consider a 'pure' design in which we can accomplish the old functionality in a paradigm that also supports the new functionality." "An additional checkbox is too detrimental to the user interface." "Maintaining two branches of logic within the dialog sizing component will be untenable." "We have no interest in not pushing our shiny new object."

These are all statements, which if executed within a corporate arena, would get developers fired. Developers, make note: you are doing a disservice to the community you claim to represent, and are doing so with false illusions that you are "right" because you have convictions in your justifications.

It does not matter that you are open source developers with the autonomy to ignore your user base. It does not matter that a plugin "could" be developed to solve the problem. It does not matter that you feel your default solution is superior. It does not matter that you only want to consider solutions which can be implemented through the new solution framework. It does not matter that your users should abandon your product if they don't like it. It does not matter that someone could fork the code base. It does not matter if 11 thousand people download your source code per day, and only 270 complain about it. For each of these, there are very valid rebuttals.

So, only 270 complaints for this feature, out of 11 thousand downloads? How many people immediately uninstalled the program when they realized it could not longer do the simplest functionality that GAIM and other IM agents do? How many don't know that they are using software that is now crippled in comparison to its former flexibility? How many use the software today, but will switch to GAIM tomorrow when they hear from their friends that it's so much easier to resize in GAIM?

The fact is that typing letters into an IM window is THE most critical task of an IM program. Users have varying needs, needs which can not be addressed by your limited attempts to come up with "one solution for everything" that incorporates "shiny new logic" that demonstrates how smart you are. You 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.

For the sake of everyone involved, I hope you find your path back to the light.

comment:273 in reply to: ↑ 272 Changed 8 years ago by seanegan

Replying to DanLivingston:

I teach "Collaboration in an Open Source World" at a local college. I have been searching for, and in this ticket have found, a perfect example where communication between open source developers and users fails at multiple, fundamental levels.

Do you have a lecture about insulting hobbyist developers you've never met on their bug tracker?

comment:274 Changed 8 years ago by ConnorBehan

Most of us have not met you personally but we are allowed to have strong feelings about this particular crippling of the code for which you are responsible. And venting such frustrations on the bug tracker is probably the best way to make sure multiple developers and sympathizing users get to see it. Even if you think DanLivingston? insulted you there, it is the content of his arguments you should be addressing.

comment:275 in reply to: ↑ 272 ; follow-ups: Changed 8 years ago by rekkanoryo

Replying to DanLivingston:

I teach "Collaboration in an Open Source World" at a local college. I have been searching for, and in this ticket have found, a perfect example where communication between open source developers and users fails at multiple, fundamental levels.


You are making a fundamental mistake here in assuming that communication has failed. The fact that we aren't willing to undo our UI changes is not a sign of communications failure. We have listened to the whining, the complaining, the threats, and the few well-presented and logical arguments we've received. We are working to improve the changed UI; reverting this is a step backwards in the development process that we're not willing to take.


What happens when those same newfound powers are taken away? What happens when the developers impose their personal dogmas upon the project? Even for as small an issue as chat window resizing, a minority (or majority) of users will emphatically express dissent.


As I noted in another ticket related to the automatic resizing, we had similar numbers of complaints about our changes to the buddy list and status UIs in the transition from 1.5.0 to 2.0.0. The complaints died down after several weeks. The loss of protocol icons as status indicators is a dead issue and has been for many months now. The change to a status selector that is a first-class citizen in the buddy list window also caused some friction that died down after a short time. The same will happen with the input area resizing given time.


<snip of long, rambling text only tangentially related to the following>
The fact is that typing letters into an IM window is THE most critical task of an IM program. Users have varying needs, needs which can not be addressed by your limited attempts to come up with "one solution for everything" that incorporates "shiny new logic" that demonstrates how smart you are. You 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.


None of us develop Pidgin as a function of our job. Pidgin is a hobby for us. We don't claim to represent a community--we claim to make an IM client that meets our own needs and hopefully meets others' needs as well. We aren't forcing anyone to use our software, nor are we profiting from our users. As you noted, we have the autonomy to make our own decisions. We are the people putting forth the development effort, and therefore we have a right to decide what goes into our software.

Quite simply, it doesn't matter if we have one user or six billion users outside the developer community. We have long understood that we can never please all our users with our single user interface--it's simply not possible. Because of that, we do not aim to please all our users, but instead to please ourselves and hope that we have pleased like-minded users. We encourage users whose needs are not met by our software to find other software that does meet their needs.


For the sake of everyone involved, I hope you find your path back to the light.


We never strayed from our path. The Path to Enlightenment is unique for each individual.

comment:276 in reply to: ↑ 275 ; follow-up: Changed 8 years ago by megaloman

Replying to rekkanoryo:

Replying to DanLivingston:

I teach "Collaboration in an Open Source World" at a local college. I have been searching for, and in this ticket have found, a perfect example where communication between open source developers and users fails at multiple, fundamental levels.


You are making a fundamental mistake here in assuming that communication has failed. The fact that we aren't willing to undo our UI changes is not a sign of communications failure. We have listened to the whining, the complaining, the threats, and the few well-presented and logical arguments we've received. We are working to improve the changed UI; reverting this is a step backwards in the development process that we're not willing to take.


As far as I can tell, he is actually right. You (developers) claim, that you want to improve your brand new idea, which is actually broken by design. Don't get offended. I have tried this new improved feature and I cannot stand it, I cannot get use to it. And communication has failed, because you don't listen your users. Your users don't ask you to revert that, they ask to make it optional.

As I noted in another ticket related to the automatic resizing, we had similar numbers of complaints about our changes to the buddy list and status UIs in the transition from 1.5.0 to 2.0.0. The complaints died down after several weeks. The loss of protocol icons as status indicators is a dead issue and has been for many months now. The change to a status selector that is a first-class citizen in the buddy list window also caused some friction that died down after a short time. The same will happen with the input area resizing given time.


What about another annoying feature smooth scrolling? thanks god, it's optional now. how long did developers insist, that it cannot be optional?


None of us develop Pidgin as a function of our job. Pidgin is a hobby for us. We don't claim to represent a community--we claim to make an IM client that meets our own needs and hopefully meets others' needs as well. We aren't forcing anyone to use our software, nor are we profiting from our users. As you noted, we have the autonomy to make our own decisions. We are the people putting forth the development effort, and therefore we have a right to decide what goes into our software. Quite simply, it doesn't matter if we have one user or six billion users outside the developer community. We have long understood that we can never please all our users with our single user interface--it's simply not possible. Because of that, we do not aim to please all our users, but instead to please ourselves and hope that we have pleased like-minded users. We encourage users whose needs are not met by our software to find other software that does meet their needs.


I am a developer too and I cannot stand that attitude, I just don't have a words. How can you say something like that? You don't care about your users? Major linux distributions are including your software as a default IM - that's a responsibility you should care of. You're not writing this just for you, you're writing it for millions of users. And following your website “If you are a regular user, we encourage you to let us know about any problems you encounter and to provide us with suggestions for improvement.” - we are asking about an improvement, make it optional.


For the sake of everyone involved, I hope you find your path back to the light.

We never strayed from our path. The Path to Enlightenment is unique for each individual.


Do more features like that, you will eventually get Enlighten without any users supporting and using your software. That will be sad, but maybe with your Enlightenment you will understand, that sometimes it's easier to say Sorry guys, we made a wrong decision.

comment:277 Changed 8 years ago by TacBoy

" As I noted in another ticket related to the automatic resizing, we had

similar numbers of complaints about our changes to the buddy list and status UIs in the transition from 1.5.0 to 2.0.0. The complaints died down after several weeks. The loss of protocol icons as status indicators is a dead issue and has been for many months now. The change to a status selector that is a first-class citizen in the buddy list window also caused some friction that died down after a short time. The same will happen with the input area resizing given time."

Given that my good friend and system administrator where I work who originally turned me to Pidgin STILL complains about this and some other changes and how it was not listened to says that just because it died down doesn't mean TRUE resolution was reached. Just that people figured out that they were not going to be listened too. Don't mispercieve acceptance for happiness.

comment:278 follow-up: Changed 8 years ago by TacBoy

" As I noted in another ticket related to the automatic resizing, we had

similar numbers of complaints about our changes to the buddy list and status UIs in the transition from 1.5.0 to 2.0.0. The complaints died down after several weeks. The loss of protocol icons as status indicators is a dead issue and has been for many months now. The change to a status selector that is a first-class citizen in the buddy list window also caused some friction that died down after a short time. The same will happen with the input area resizing given time."

My friend and system administrator who sold me on using Pidgin STILL complains today about the icon changes. And cites that as why posting on this ticket is pointless since the developers won't listen. Just because people stopped saying anything doesn't mean they were happy about it... just that they realized the fruitlessness of saying anything.

Don't misperceive acceptance for happiness.

comment:279 in reply to: ↑ 275 ; follow-up: Changed 8 years ago by hobbified

Replying to rekkanoryo:

As I noted in another ticket related to the automatic resizing, we had similar numbers of complaints about our changes to the buddy list and status UIs in the transition from 1.5.0 to 2.0.0. The complaints died down after several weeks. The loss of protocol icons as status indicators is a dead issue and has been for many months now. The change to a status selector that is a first-class citizen in the buddy list window also caused some friction that died down after a short time. The same will happen with the input area resizing given time.

Er yes, the icon issue died down because, silently, in the next release, YOU EFFECTIVELY UNDID YOUR CHANGES. You made the program worse, people complained, and then you fixed it -- only without admitting you were wrong or admitting you fixed anything. And this is what you're doing again. All you need to say is "yeah, we totally fucked up. We'll improve on that." But instead you maintain, as before, that fixing your regressions constitutes "a step backwards". So you have to fix it a different way. If experience is any guide, the eventual replacement will be better than what came before, but here's a suggestion from the backseat driver department: if your experiments on the path to progress break shit, DON'T RELEASE THEM TO THE INTERNET BEFORE YOU FIX THINGS. And if you do, don't pretend your shit isn't shit! The problem isn't code or pixmaps. It never was. The problem is you have no clue whatsoever how to communicate with your users, and this results in them getting pissed of at you on a regular basis. (Your denial of it in the very first sentence of your own post simply suggests that you are, as the paper says, "Unskilled and Unaware of It").

comment:280 in reply to: ↑ 276 Changed 8 years ago by rekkanoryo

Replying to megaloman:

What about another annoying feature smooth scrolling? thanks god, it's optional now. how long did developers insist, that it cannot be optional?


Smooth scrolling was never not optional in a release.


I am a developer too and I cannot stand that attitude, I just don't have a words. How can you say something like that? You don't care about your users? Major linux distributions are including your software as a default IM - that's a responsibility you should care of. You're not writing this just for you, you're writing it for millions of users. And following your website “If you are a regular user, we encourage you to let us know about any problems you encounter and to provide us with suggestions for improvement.” - we are asking about an improvement, make it optional.

Yes, we encourage our users to discuss the software with us. We are not obligated to act upon any discussion, nor are we obligated to change our opinions when we don't agree with the arguments presented. We're not even obligated to provide a mechanism for submitting any form of feedback.

The fact of Pidgin development is that we wrote it for ourselves. We released it to the world in the hopes that it would be useful to others. There is a huge difference between this and bending over backwards to satisfy every request or complaint. If our desired development path no longer makes the software usable, we're sorry, but you'll need to find another piece of software to meet your needs.

As for the resizable input area, it already is optional, as a plugin clearly now exists to restore the functionality. The "improvement" you desire has been made.

comment:281 in reply to: ↑ 278 Changed 8 years ago by rekkanoryo

Replying to TacBoy:

Don't misperceive acceptance for happiness.

I don't. I perceive it as either a willingness to compromise or a willingness to live with the decisions made. Either works for me.

comment:282 in reply to: ↑ 279 ; follow-up: Changed 8 years ago by rekkanoryo

Replying to hobbified:

Er yes, the icon issue died down because, silently, in the next release, YOU EFFECTIVELY UNDID YOUR CHANGES. You made the program worse, people complained, and then you fixed it -- only without admitting you were wrong or admitting you fixed anything. And this is what you're doing again.


It was not the next release. The protocol icons were taken away in 2.0.0beta7 and did not come back until version 2.2.0, a full six releases later. Those icons still did not come back as status icons--instead they came back as an additional icon column in the buddy list. It was not a silent change, either, as there was debate when the addition of that stupid option happened, and it was clearly noted in the ChangeLog.


If experience is any guide, the eventual replacement will be better than what came before, but here's a suggestion from the backseat driver department: if your experiments on the path to progress break shit, DON'T RELEASE THEM TO THE INTERNET BEFORE YOU FIX THINGS. And if you do, don't pretend your shit isn't shit! The problem isn't code or pixmaps. It never was. The problem is you have no clue whatsoever how to communicate with your users, and this results in them getting pissed of at you on a regular basis. (Your denial of it in the very first sentence of your own post simply suggests that you are, as the paper says, "Unskilled and Unaware of It").


While most of the above is nonsensical crap not worth replying to, I will note that our development model has worked for 10 years, and will continue to work regardless of a few disgruntled users.

comment:283 Changed 8 years ago by rlaager

I'd like to ask everyone to please wait for the next release (2.4.2). Please try that release for at least two days. At that time, if you're still unhappy with this feature as implemented then, please let us know why.

This request is intended to serve a couple purposes: First, I'd like to ensure that we're all on the same page with regard to code updates and that everyone has had a chance to truly test out the latest code. Second, I'd like to see everyone here take a moment to step back from this discussion.

If this needs further addressing after the 2.4.2 release, we can do so.

comment:284 in reply to: ↑ 282 Changed 8 years ago by hobbified

Replying to rekkanoryo:

While most of the above is nonsensical crap not worth replying to, I will note that our development model has worked for 10 years, and will continue to work regardless of a few disgruntled users.

You haven't had a development model for ten years. I was around five years ago, and things were incredibly different then. And things were even more different a couple years before that. And no, I wasn't spouting incoherent crap. Incoherent is more like "I had one grunch but the eggplant over there." My post was, if anything, somewhat lacking in punctuation and paragraph breaks. :)

comment:285 Changed 8 years ago by yesimahuman

Yea guys, this really needs to be changed. I can't barely even click into the box to start typing! WHY DO YOU NEED TO PUSH YOUR AGENDA? I'm a user of your program. If I stop using it, I will tell my friends to stop using it too (and they do use it, due to my recommendation). Why are you taking this so personally?

comment:286 in reply to: ↑ 275 Changed 8 years ago by kluvik

Replying to rekkanoryo:

Replying to DanLivingston:

I teach "Collaboration in an Open Source World" at a local college. I have been searching for, and in this ticket have found, a perfect example where communication between open source developers and users fails at multiple, fundamental levels.


You are making a fundamental mistake here in assuming that communication has failed. The fact that we aren't willing to undo our UI changes is not a sign of communications failure. We have listened to the whining, the complaining, the threats, and the few well-presented and logical arguments we've received. We are working to improve the changed UI; reverting this is a step backwards in the development process that we're not willing to take.

The fact is that your new step is a feature only for narrow group of developers and it is a bug for the rest users of pidgin. You do not going to recognize your fault and still act as a mules. Someone of you (i.e. developers) have very horrible conception of design. The case with autoresize IS NOT not the single one, but it is the awfulest all of its. Yeah, others small design "impruvements" are sufferable but not this one! That is why now you get so much feedbacks.

Please, do not feed us with the shit like 'backwards in the development'. Just say as it is -

We are not willing to listen to our users, we are developing the product on our own.

At least this would give us opportunity not to waste time on these debates.

comment:287 follow-up: Changed 8 years ago by DanLivingston

Kluvik,

You make an excellent point. From now on, the user base of Pidgin should just assume that the following fictitious letter was ghost written for the Pidgin development team:

"Dear Users:

You are most undoubtedly reading this page because you want to know how to manually resize the text input area in Pidgin. It is a feature that you have perhaps grown accustomed to and comfortable with, but please make note - this feature is no longer supported.

We have received many complaints from a very small minority of the user base who nonetheless persists in being very vocal about their displeasure. Please take comfort in the fact that they are only a very small percentage base of Pidgin users, and if ignored, will go away and bother some other open source project.

Nonetheless, we feel it very important to make the following proclamation regarding on our stance on this project: we will not "fix" it. In fact, please notice that the status of this "bug" is "wontfix". So would you please just get this idea through you head and go away now?

We are developers of this software, and we develop Pidgin so that it may fulfill our explicit needs and desires. If you want to join us for the ride, then fine. Just shut up, though. Please, if we've made a feature a certain way, it's because WE WANT IT THAT WAY. Is that so hard to understand? All day long our bosses tell us what to do. Our wives tell us what to do. Our government tell us what to do. YOU will NOT tell us what to do.

Some say that as the developers of the premier open source IM client, we have a "responsibility" to serve as wardens of our precious charge, nurturing it into a fine, outstanding, model citizen of the open source community. That's rubbish. The last time we checked, we didn't sign up for day care. We signed up to write software that WE want to use.

So please take your ideas and go elsewhere. If you want a development team that responds to the desires of their user base, hoping to release world-class, quality software to millions of people, then start your own open source project. It's not that hard. It's free. All you have to do is commit your time, just like we commit ours.

The development team would very much like to come up with a solution that meets the needs of ourselves and the general user base. However, we cannot understand your needs. You speak in a foreign gibberish, gobbledy gook language that none can understand. "I just like it that way!" That is not an answer! You must enumerate the metrics and aspects of your preferences and desires in ways that we can evaluate and then assimilate into our collective. We cannot currently assimilate any of your idiotic reasons for wanting a resizable text box. And by idiotic, we mean "any solution which does not fit into the scheme of our cleverly intelligent auto-resizing text field."

So, just to make it clear: we will not listen to your suggestions unless your suggestions make sense to us, and we like them. If you do not like it, there are plenty of other ways on the Internet in which you may occupy your time.

Regards, Pidgin development team"

comment:288 in reply to: ↑ 287 Changed 8 years ago by megaloman

Replying to DanLivingston:

We have received many complaints from a very small minority of the user base who nonetheless persists in being very vocal about their displeasure. Please take comfort in the fact that they are only a very small percentage base of Pidgin users, and if ignored, will go away and bother some other open source project.


At my work place we have a group of 8 linux users, 7 of them are using Pidgin. Only one of them found your new feature actually usable, others installed optional plugin. 6 out of 7 gives me about 85% - it is a very small percentage base of Pidgin users. When my sister got an update, she called me straightaway Marek, my Pidgin is broken, she could not stand the new so called feature, but she's happy now with a plugin, which fixes this annoying bug.


The development team would very much like to come up with a solution that meets the needs of ourselves and the general user base. However, we cannot understand your needs. You speak in a foreign gibberish, gobbledy gook language that none can understand. "I just like it that way!" That is not an answer! You must enumerate the metrics and aspects of your preferences and desires in ways that we can evaluate and then assimilate into our collective. We cannot currently assimilate any of your idiotic reasons for wanting a resizable text box. And by idiotic, we mean "any solution which does not fit into the scheme of our cleverly intelligent auto-resizing text field."


The best solution is to make it optional - it cost you almost nothing. You don't listen to anyone. Many users gave you strong arguments, why they want manual resizable input field, but you're not listening to them. You're locked your mind on your so called feature and that's it. You want to improve it, but just denying to do anything. Why can't you just understand, that people are different, they vary from each other, they have their own tastes, etc - one will like 2 up to 4 lines, other will like 5 to 50% of input field, but you cannot pleased everyone. With your approach you're going nowhere. Your cleverly intelligent auto-resizing text field does not work for everyone and won't work for everyone - is it that hard to understand? By denying that you're just showing around your closed minds and stupidity.

So, just to make it clear: we will not listen to your suggestions unless your suggestions make sense to us, and we like them. If you do not like it, there are plenty of other ways on the Internet in which you may occupy your time.

Thank you for making that clear. Sooner or later this thread will die, but it does not mean users started to love your new feature. My mother used to say “Don't talk with a stupid, he won't understand” - I think we got to that point, you're just showing of your stupidity and people will just keep quiet, because no one likes to discuss anything with dummies.

Thanks god someone has developed a plugin.

comment:289 Changed 8 years ago by mlsterben

Megaloman, I believe DanLivingston?'s post was a satire of the developers' attitudes. Where's this plugin I hear of? I'm using the fork right now, but that is probably not very helpful to the cause.

comment:290 Changed 8 years ago by ConnorBehan

The plugin: http://developer.pidgin.im/ticket/5296 is probably the best way to go if this really is the only issue you've had with the Pidgin developers. But if there are other rejected features you'd like to have, Funpidgin will get better.

comment:291 Changed 8 years ago by rfgiusti

(...)

Quite simply, it doesn't matter if we have one user or six billion users outside the developer community.

(...)

That's the most freaking stupid thing ever written in this ticket... and, man, I have read a lot of crap here. Worst of all, it was written by a developer.

Fortunatelly, it's pretty obvious that this is a huge lie. We know you are proud of the software you use and we know you wouldn't really appreciate if Linux distributions stopped including Pidgin as the default IM application. Unfortunatelly, on the other hand, that statement of yours just show how freaking arrogant you are. The problem is, it is not that you don't care if six billion people ignore your software, but that you consider yourself so damn good that you think you can do whatever you want to your software and people will always accept it as good software.

I give up. I'll just wait for the next update, as some of you have asked. If it's not good enough, I'll leave Pidgin. And I hope the other six billion people will do the same.

comment:292 Changed 8 years ago by ConnorBehan

Wikipedia has recently annoyed me with Ajax suggestions showing up when I search for something. I'd rather just see recent entries that I made in the form and not what Wikipedia thinks I should see. The hilighting color also clashes with my theme.

Luckiy,it is an:

Option

which I can:

Disable

Someone at Wikipedia understands me.

comment:293 Changed 8 years ago by pdwerryhouse

For Linux users, I have created a package of Artemy Kapitula's manualsize plugin, which allows it to be compiled and installed independently of the Pidgin source code. I've also put a Debian package there, and there will be an Ubuntu package coming in the next few days.

Some people might find this less problematic than removing Pidgin altogether and installing Funpidgin.

comment:294 Changed 8 years ago by darose

@pdwerryhouse: Awesome! Works great! Thanks much for setting this up! I think I'm going to go upload a package of this for my distro. (Arch)

And given the various parties' stances here, perhaps this might wind up being the best compromise for now: if the devs don't want to add back the feature, install this plugin and you can get it back. Problem solved ... enough. :-)

comment:295 Changed 8 years ago by alanrr_sr

Hi, I do not like teh new feature too, it is also annoying to type and see the window moving around. I also believe that 2 options, automatic and manual resize would, rocks. I believe that I read every post of this thread, and I do not like the 50% solution also. So, just a doubt: If creating options is a "usability problem" for devs, why have they created "group or ungroup" items above the input chat window? (why not have a decision about that to) Connecting to question above, why (for possibility's sake) is not possible to add a "Allow manual resize" in this right click menu, that would work as the grouping itens? We already have this "context menu" with just one option, would add another option bloat or complicate the interface? Just one more 0,02... I believe that "drastic" changes annoy users (Windows Vista is a kind of example), so, progressive changes would benefit all. It looks like you are "forcing changes"...

Sorry about my english or if i looked rude in any of my others, it was not the intention.

comment:296 in reply to: ↑ 236 Changed 8 years ago by willie_wang

Automatic resize is frustrating. My family and I have been using pidgin for a while now and all agree that it's very frustrating to see a text input autoresize.

It looks messy.

Me and my sis are sticking to 2.3 versions. My brother's using kopete now.

It's so frustrating I made an account here just to tell you.

comment:297 Changed 8 years ago by ralf.faust

The reason why this page was made static was a /. article about this controversy (http://tech.slashdot.org/article.pl?sid=08/04/30/1822237&from=rss). The comments are pretty insightful as well...

comment:298 Changed 8 years ago by kpobococ

adding my voice to those requesting an option. I really hate this input field being not resizable.

comment:299 Changed 8 years ago by clickwir

what the monkey fu~ck is going on with this? Give me back my resize. I'm the user, I decide what size I want the window. That's the point of open source software, to let it be what the users want, not what some overload deems it to be. Listen to the users or me and everyone I've convinced to using GAIM/Pidgin will be using something else.

comment:300 in reply to: ↑ description Changed 8 years ago by vamonos

I also registered an account here just to add my voice -- and though I'm a committed supporter of open-source, I've never needed to to voice criticism of a program, nor felt the need to.

However enthusiastic the developers may be about auto-resizing -- and no doubt it's a very clever bit of programming -- it's simply not for everyone. I prefer wheat bread to white, and brunettes to blondes, but that doesn't mean I have the moral imperative to eliminate blondes! Don't take it personally, I'm a big fan of your work otherwise. And I respect that this trick must have taken considerable effort, and I'd appreciate that if it weren't, y'know, forced on me.

This compromise of how many lines the auto-resize will permit me to have isn't much better, by the way. Why on earth does it max out at eight lines? Just let us choose between manual and automatic resizing, and let go of this grating micromanagement.

comment:301 Changed 8 years ago by Iyeru

However, if you ask me, that minimum lines to show changer is enough for me.

They also made a news post about this, and they said that allowing "manual resize is expensive." Or rather, they said, "options are expensive."

comment:302 follow-ups: Changed 8 years ago by suncho

I was reading Ari Jaaksi blog today (you know, Nokia bought Symbian) and one of the key principles he mentioned made me remember this ticket (another thing than makes me remembering this thicket is that I cant freaking unsubscribe)

So, here it is, what I always wanted to say here:

"-Contribute code. If not, shut up."

comment:303 in reply to: ↑ 302 Changed 8 years ago by TacBoy

Replying to suncho:

I was reading Ari Jaaksi blog today (you know, Nokia bought Symbian) and one of the key principles he mentioned made me remember this ticket (another thing than makes me remembering this thicket is that I cant freaking unsubscribe)

So, here it is, what I always wanted to say here:

"-Contribute code. If not, shut up."

Well, since I can't unsubscribe either, let me say that blogs are hardly the authority. And my particular revulsion (and thus my discontinuation of using pidgin) has far less to do with the feature at this point and more that the user/developer relationship is a one-way street and that as a developer I detest that. So, while I could add code, I refuse to participate in this particular insulting developer base lest I become tainted with their attitude.

So for my pithy quote to contribute:

"You get what you pay for."

comment:304 in reply to: ↑ 302 Changed 8 years ago by TacBoy

"-Contribute code. If not, shut up."

On second thought, I really like that quote. I think it should be on the front page of pidgin.im in big bold letters.

comment:305 Changed 8 years ago by vamonos

It's worth pointing out that code HAS been contributed to fix this, on a divergent fork called FunPidgin. The Pidgin developers simply don't want to include it.

It's no longer a question of effort or cost -- now it's one of control, one entirely antithetical to the entire concept of open-source. There's no apparent reason to take away manual resizing -- a feature obviously in heavy demand -- but to exercise power over others. There's not even a practical aesthetic argument for removing the user's ability to control his own text box. It's the fat guy on the beach kicking over the skinny guy's sandcastle just because he can.

I don't hate the developers -- in fact, I don't think they get nearly enough credit, drawing attention only when they do something wrong. Pidgin's a masterful piece of software, and I wouldn't be here now if I didn't believe in it. But for all their hard work and hard-won successes, some jackass is tarnishing their reputation with this personal vendetta against distributed control. Quit it, and listen to the community. Please.

comment:306 in reply to: ↑ 302 Changed 8 years ago by thwarted

Replying to suncho:

So, here it is, what I always wanted to say here:

"-Contribute code. If not, shut up."

Comment #127 has a link to patched code, so the code has been contributed. It has nothing to do with the code having been written or not.

One wonders what it means to have to contribute code that already existed in previous versions though. Asking for contributions of code that already exists doesn't speak highly of the developers' revision control system.

comment:307 Changed 8 years ago by ionoff

Thank you Vamonos, I was just about to point out Carrier/FunPidgin? to the recent posters.

hxxp://funpidgin.sf.net (xx=tt)

comment:308 Changed 8 years ago by bagatonovic

LOL contribute code or shut up huh? I wish I could unsubscribe from this crap. Unfortunately my email sometimes gets spammed by this all-but-forgotten nightmare. USE MEEBO - FORGET PIDGIN!!!! https://www.meebo.com

comment:309 Changed 8 years ago by suncho

I would like to correct my statement for people which did not get the irony from the previous one:

  • Shut up, or be eternally subscribed to the discussion.

We should call this "Rule #4986" :)

comment:310 Changed 8 years ago by Izkata

+1 here. My main issue is that the minimum size is too large.

And thanks for the "FunPidgin" link. I may well switch over.

comment:311 Changed 8 years ago by mickrussom

I made an account to complain that not allowing control over the interface F-ing sucks. I hate Office 2007 for forcing Ribbon up people's butts, and I hate pidgin forcing UI crap up butts as well.

Please consider how bad this behavior is, and who is being emulated here (microsoft).

This is a foul sickening turn things are taking for pidgen, and if pidgin had done this CRAP before roping in millions, it would have never gotten this far.

Hitler complex by the leadership, plain and simple. HITLER. But he was a more effective leader. Miranda, meebo, Kopete or back to trillian. Tah tah, fascists. .

comment:312 Changed 8 years ago by mickrussom

I made an account to complain that not allowing control over the interface F-ing sucks. I hate Office 2007 for forcing Ribbon up people's butts, and I hate pidgin forcing UI crap up butts as well .

Please consider how bad this behavior is, and who is being emulated here (microsoft).

This is a foul sickening turn things are taking for pidgen, and if pidgin had done this CRAP before roping in millions, it would have never gotten this far.

Hitler complex by the leadership, plain and simple. HITLER. But he was a more effective leader. Miranda, meebo, Kopete or back to trillian. Tah tah, fascists.

comment:313 Changed 8 years ago by hajma

+1, this is such a nasty behaviour

Unfortunately Kopete still does not support TLS or I would have already switched.

comment:314 follow-up: Changed 8 years ago by yesyesyesyes

I just upgraded to (portable) Pidgin 2.4.3 from an older version, and am having to consider reverting back.

The constant shifting of the conversation text caused by the text entry window resizing is very intrusive. There are two particular side effects of the new behavior which are the most distracting :

1) Every time I start typing a new message, it causes the conversation text to shift upwards as if the other person had sent a message. But they have not sent a message. This breaks the previous and natural 1:1 association of conversation text scrolling upward meaning a new message has been added to the conversation.

2) The text entry area has contracted to such a small size when no text has been entered that it is now very difficult to set the focus to it using the mouse. The "minimum input area height in lines" option does not alleviate the problem because it only applies once one or more characters have been entered into the text field. My usage pattern is to very commonly be performing other tasks and periodically switching back to the IM window. The previous implementation was conducive to this, it is more difficult to do this with the new one.

I find the previous implementation, in which the conversation and text entry area were manually sized by the user, to be much more user friendly.

I know a lot of the negative feedback about this is being chalked up to "users fearing change", but the tremendous amount of feedback about this feature hints that it may not be the case. It is worth pointing out that many positive changes have been made to pidgin over the years which have not generated this level of negative feedback - users typically like change when it makes the application easier and more intuitive to use.

So, lastly - pretty pony please, please, please allow users to override this. It will make a lot of people much happier.

comment:315 in reply to: ↑ 314 ; follow-up: Changed 8 years ago by tmetro

Replying to yesyesyesyes:

2) The text entry area has contracted to such a small size when no text has been entered that it is now very difficult to set the focus to it using the mouse. The "minimum input area height in lines" option does not alleviate the problem because it only applies once one or more characters have been entered into the text field.

I believe what you are observing is a bug, which is related, but a separate issue from what this ticket is about. There are reports in this ticket describing the text entry area being one line or less, and that's a bug (and acknowledged by the developers as such). I though it had been fixed. If you're still seeing it in the latest release, I'd recommend searching for a relevant ticket or opening a new ticket if necessary (and post a link to it here).

comment:316 in reply to: ↑ 315 Changed 8 years ago by clickwir

Replying to tmetro:

I believe what you are observing is a bug, which is related, but a separate issue from what this > ticket is about. There are reports in this ticket describing the text entry area being one line > or less, and that's a bug (and acknowledged by the developers as such). I though it had been fixed. If you're still seeing it in the latest release, I'd recommend searching for a relevant ticket or opening a new ticket if necessary (and post a link to it here).

Just to remind, a fix has been suggested and written, I believe also tested.

It puts the text area back to how it was, resizeable by the user. So there's no excuse for the bug to be there or the whole "automatic" resizing thing, altogether.

comment:317 Changed 8 years ago by yesyesyesyes

(I know this is slightly abusing the ticket scope, but it may ease the burden for users affected by the won't-fix status)

OK, a week after trying the new pidgin release I gave up and switched to Carrier/FunPidgin? as recommended by another poster in this ticket. Carrier patched Pidgin to make the text entry re-sizable again. As a pleasant surprise it also includes patches to make other, recent UI changes optional. For example, typing notification can be switched back to an icon instead of being inside the chat text area.

http://funpidgin.sf.net

comment:318 Changed 8 years ago by Sim-on

Ticket #6921 has been marked as a duplicate of this ticket.

comment:319 Changed 8 years ago by jlechem

This is simply stupid. It's obvious your users want you to change this feature. But as of 2.5 it isn't done and after reading this exchange I can see why. From one developer to another to see this kind of reaction to your user base saddens me deeply. I implore all pidgin users to go over to funpidgin it has the features you are looking for. And I personally hate the new entry area, it's too small and the auto size thing just doesn't work. I often paste large spots of code from my real IDE to pidgin (suggesting we use pidgin for coding, make you a jackass of the nth degree) and not being able to re-size is a real pain.

comment:320 Changed 8 years ago by B3nno

Hopefully if enough people complain about how dumb this lack of usability is, they might still change it eventually. I too am saddened that so many people can want a feature from a previous version, yet the developer continues to keep it out.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!