[Pidgin] #4986: automatic chat input field resizing should be optional, regression from 2.3

[Pidgin]

#4986: automatic chat input field resizing should be optional, regression from 2.3
---------------------------+------------------------------------------------
  Reporter:  swbrown       |       Owner:                   
      Type:  enhancement   |      Status:  reopened         
  Priority:  minor         |   Milestone:                   
 Component:  pidgin (gtk)  |     Version:  2.4.0            
Resolution:                |    Keywords:  chat input resize
   Pending:  0             |  
---------------------------+------------------------------------------------
Comment (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!

-- 
Ticket URL: <http://developer.pidgin.im/ticket/4986#comment:218>
Pidgin <http://pidgin.im>
Pidgin