[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 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

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