Context Navigation

Ticket #4986 (closed enhancement: wontfix)

Opened 2 years ago

Last modified 6 months ago

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

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

Change History

follow-up: ↓ 21 Changed 2 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.

follow-up: ↓ 22 Changed 2 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.

in reply to: ↑ 19 Changed 2 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.

in reply to: ↑ 20 ; follow-up: ↓ 23 Changed 2 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".

Changed 2 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?

follow-up: ↓ 30 Changed 2 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.

follow-up: ↓ 36 Changed 2 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).

in reply to: ↑ 27 ; follow-up: ↓ 33 Changed 2 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?

Changed 2 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.

in reply to: ↑ 30 Changed 2 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.

in reply to: ↑ 29 ; follow-ups: ↓ 43 ↓ 73 Changed 2 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 :)

in reply to: ↑ 31 Changed 2 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?

in reply to: ↑ 39 Changed 2 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.

Changed 2 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.

follow-ups: ↓ 44 ↓ 47 Changed 2 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.

in reply to: ↑ 36 Changed 2 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.

in reply to: ↑ 49 Changed 2 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).

follow-up: ↓ 56 Changed 2 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.

Changed 2 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.

follow-up: ↓ 58 Changed 2 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.

in reply to: ↑ 57 Changed 2 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.

Changed 2 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.

follow-ups: ↓ 75 ↓ 104 Changed 2 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?

in reply to: ↑ description Changed 2 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.)

in reply to: ↑ 55 Changed 2 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.

in reply to: ↑ 36 Changed 2 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.

in reply to: ↑ 64 Changed 2 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.

follow-up: ↓ 86 Changed 2 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.

Changed 2 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

in reply to: ↑ 79 Changed 2 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 minimum/maximum height of the auto-size or have the manual-size be returned.

follow-up: ↓ 94 Changed 2 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.

Changed 2 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.

in reply to: ↑ 76 Changed 2 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.

Changed 2 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!!!

in reply to: ↑ 82 Changed 2 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.

Changed 2 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.

2. 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.

Changed 2 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.

in reply to: ↑ 64 ; follow-up: ↓ 105 Changed 2 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?

in reply to: ↑ 104 Changed 2 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.

follow-up: ↓ 107 Changed 2 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).

in reply to: ↑ 106 Changed 2 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).

in reply to: ↑ 109 Changed 2 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".

follow-up: ↓ 112 Changed 2 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.

in reply to: ↑ 111 Changed 2 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.

follow-ups: ↓ 117 ↓ 227 Changed 2 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!

in reply to: ↑ 116 ; follow-up: ↓ 118 Changed 2 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.

in reply to: ↑ 120 Changed 2 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.

follow-up: ↓ 124 Changed 2 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.

in reply to: ↑ 120 Changed 2 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.

in reply to: ↑ 122 ; follow-up: ↓ 132 Changed 2 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.

Changed 2 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.

in reply to: ↑ 124 Changed 2 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.

follow-up: ↓ 134 Changed 23 months 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.

follow-up: ↓ 136 Changed 23 months 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

2. 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);

in reply to: ↑ 135 Changed 23 months 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 2. 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?

Changed 23 months 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.

Changed 23 months 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.

Changed 23 months 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.

Changed 23 months 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.

follow-ups: ↓ 157 ↓ 165 ↓ 169 Changed 23 months 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).

in reply to: ↑ 156 ; follow-up: ↓ 158 Changed 23 months 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 :)

in reply to: ↑ 157 ; follow-ups: ↓ 159 ↓ 161 ↓ 163 Changed 23 months 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.

in reply to: ↑ 158 ; follow-up: ↓ 162 Changed 23 months 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!

in reply to: ↑ 158 ; follow-up: ↓ 170 Changed 23 months 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

Changed 23 months 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.

follow-ups: ↓ 167 ↓ 171 Changed 23 months 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.

in reply to: ↑ 166 ; follow-ups: ↓ 168 ↓ 172 Changed 23 months 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.

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.

in reply to: ↑ 167 ; follow-up: ↓ 173 Changed 23 months 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

in reply to: ↑ 156 ; follow-up: ↓ 176 Changed 23 months 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).

in reply to: ↑ 163 Changed 23 months ago by deryni

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

in reply to: ↑ 166 ; follow-up: ↓ 177 Changed 23 months 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).

in reply to: ↑ 168 ; follow-ups: ↓ 174 ↓ 175 Changed 23 months 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.

in reply to: ↑ 173 Changed 23 months 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

in reply to: ↑ 173 ; follow-up: ↓ 182 Changed 23 months 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.

in reply to: ↑ 169 ; follow-up: ↓ 183 Changed 23 months 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.

in reply to: ↑ 171 ; follow-up: ↓ 184 Changed 23 months 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?

follow-up: ↓ 185 Changed 23 months 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).

Changed 23 months 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

in reply to: ↑ 175 ; follow-up: ↓ 209 Changed 23 months 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).

in reply to: ↑ 176 ; follow-up: ↓ 189 Changed 23 months 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).

in reply to: ↑ 177 ; follow-ups: ↓ 190 ↓ 193 ↓ 194 ↓ 208 ↓ 214 Changed 23 months 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?

in reply to: ↑ 178 ; follow-up: ↓ 188 Changed 23 months 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.

in reply to: ↑ 185 Changed 23 months 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.

in reply to: ↑ 183 Changed 23 months 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.

in reply to: ↑ 184 Changed 23 months 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.

follow-up: ↓ 192 Changed 23 months 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.

in reply to: ↑ 184 Changed 23 months 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)

in reply to: ↑ 184 Changed 23 months 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.

in reply to: ↑ 192 Changed 23 months 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.

follow-up: ↓ 200 Changed 23 months 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.

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?

in reply to: ↑ 197 Changed 23 months 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?

in reply to: ↑ 198 Changed 23 months 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

follow-up: ↓ 205 Changed 23 months 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.

in reply to: ↑ 204 Changed 23 months 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.

Changed 23 months 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.

in reply to: ↑ 184 ; follow-up: ↓ 216 Changed 23 months 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...

in reply to: ↑ 182 Changed 23 months 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.

Changed 23 months 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.)

follow-up: ↓ 213 Changed 23 months 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.

2. I said that I often have cause to compose largish messages

3. 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...

in reply to: ↑ 212 Changed 23 months 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.

in reply to: ↑ 184 Changed 23 months 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.

Changed 23 months 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.

in reply to: ↑ 208 ; follow-up: ↓ 220 Changed 23 months 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.

Changed 23 months 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!

in reply to: ↑ description ; follow-up: ↓ 226 Changed 23 months 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.

follow-ups: ↓ 223 ↓ 231 Changed 23 months 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.

2. 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.

3. 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?

in reply to: ↑ 222 ; follow-up: ↓ 224 Changed 23 months ago by kdorff

Replying to Sim-on:

3. 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.

in reply to: ↑ 223 Changed 23 months 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.

Changed 23 months 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/

in reply to: ↑ 221 Changed 23 months 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.

in reply to: ↑ 116 Changed 23 months 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.

Changed 23 months 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.

in reply to: ↑ 222 Changed 22 months 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?

2. 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

Changed 22 months 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

Changed 22 months 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.

Changed 22 months 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]must/b 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 own/b 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]any/b 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

follow-up: ↓ 247 Changed 22 months 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

in reply to: ↑ 247 ; follow-up: ↓ 251 Changed 22 months 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.

in reply to: ↑ 247 ; follow-up: ↓ 255 Changed 22 months 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.

in reply to: ↑ 255 Changed 22 months 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.

in reply to: ↑ 253 Changed 22 months 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

follow-up: ↓ 261 Changed 22 months 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

Changed 22 months 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)

Changed 22 months 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!

in reply to: ↑ 266 Changed 22 months 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.

Changed 22 months 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.

follow-ups: ↓ 273 ↓ 275 Changed 22 months 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.

in reply to: ↑ 272 ; follow-ups: ↓ 276 ↓ 279 ↓ 286 Changed 22 months 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.

in reply to: ↑ 275 ; follow-up: ↓ 280 Changed 22 months 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.

Changed 22 months 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.

follow-up: ↓ 281 Changed 22 months 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.

in reply to: ↑ 275 ; follow-up: ↓ 282 Changed 22 months 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").

in reply to: ↑ 276 Changed 22 months 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.

in reply to: ↑ 279 ; follow-up: ↓ 284 Changed 22 months 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.

Changed 22 months 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.

in reply to: ↑ 282 Changed 22 months 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. :)

in reply to: ↑ 275 Changed 22 months 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.

follow-up: ↓ 288 Changed 22 months 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"

in reply to: ↑ 287 Changed 22 months 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.

Changed 22 months 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 no

Context Navigation

Ticket #4986 (closed enhancement: wontfix)

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

Description

Attachments

Change History

Changed 2 years ago by swbrown

Changed 2 years ago by tmetro

Changed 2 years ago by mlsterben

Changed 2 years ago by Gookey

Changed 2 years ago by roan

Changed 2 years ago by lu_zero

Changed 2 years ago by Tenchan

Changed 2 years ago by varchar255

Changed 2 years ago by Iyeru

Changed 2 years ago by tkl

Changed 2 years ago by dave314159

Changed 2 years ago by kdorff

Changed 2 years ago by jason0x21

Changed 2 years ago by plmayer

Changed 2 years ago by kepplah

Changed 2 years ago by posix40

in reply to: ↑ description Changed 2 years ago by Gookey

Changed 2 years ago by hbons

Changed 2 years ago by plmayer

follow-up: ↓ 21 Changed 2 years ago by hbons

follow-up: ↓ 22 Changed 2 years ago by plmayer

in reply to: ↑ 19 Changed 2 years ago by lu_zero

in reply to: ↑ 20 ; follow-up: ↓ 23 Changed 2 years ago by hbons

in reply to: ↑ 22 Changed 2 years ago by Iyeru

Changed 2 years ago by segfault

Changed 2 years ago by mlsterben

Changed 2 years ago by Oktoplus

Changed 2 years ago by seanegan

follow-up: ↓ 30 Changed 2 years ago by plmayer

Changed 2 years ago by Oktoplus

follow-up: ↓ 36 Changed 2 years ago by kdorff

in reply to: ↑ 27 ; follow-up: ↓ 33 Changed 2 years ago by seanegan

follow-up: ↓ 38 Changed 2 years ago by plmayer

Changed 2 years ago by tmetro

in reply to: ↑ 30 Changed 2 years ago by jason0x21

Changed 2 years ago by wheerdam

Changed 2 years ago by Oktoplus

in reply to: ↑ 29 ; follow-ups: ↓ 43 ↓ 73 Changed 2 years ago by seanegan

Changed 2 years ago by EvilJohn

in reply to: ↑ 31 Changed 2 years ago by seanegan

follow-up: ↓ 40 Changed 2 years ago by Oktoplus

in reply to: ↑ 39 Changed 2 years ago by seanegan

Changed 2 years ago by kdorff

follow-ups: ↓ 44 ↓ 47 Changed 2 years ago by deryni

in reply to: ↑ 36 Changed 2 years ago by Oktoplus

in reply to: ↑ 42 Changed 2 years ago by segfault

Changed 2 years ago by deryni

Changed 2 years ago by deryni

in reply to: ↑ 42 Changed 2 years ago by jason0x21

Changed 2 years ago by deryni

follow-up: ↓ 50 Changed 2 years ago by deryni

in reply to: ↑ 49 Changed 2 years ago by jason0x21

follow-up: ↓ 52 Changed 2 years ago by swbrown

in reply to: ↑ 51 Changed 2 years ago by Oktoplus

follow-up: ↓ 56 Changed 2 years ago by tkl

Changed 2 years ago by Tenchan

follow-up: ↓ 72 Changed 2 years ago by kepplah

in reply to: ↑ 53 Changed 2 years ago by seanegan

follow-up: ↓ 58 Changed 2 years ago by deryni

in reply to: ↑ 57 Changed 2 years ago by kepplah

Changed 2 years ago by deryni

Changed 2 years ago by thwarted

Changed 2 years ago by kepplah

Changed 2 years ago by kepplah

Changed 2 years ago by swbrown

Changed 2 years ago by Tenchan

follow-ups: ↓ 75 ↓ 104 Changed 2 years ago by deryni

Changed 2 years ago by deryni

Changed 2 years ago by swbrown

Changed 2 years ago by mlsterben

Changed 2 years ago by deryni

in reply to: ↑ description Changed 2 years ago by dave314159

Changed 2 years ago by kdorff

Changed 2 years ago by deryni