[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:  new              
  Priority:  minor         |   Milestone:                   
 Component:  pidgin (gtk)  |     Version:  2.4.0            
Resolution:                |    Keywords:  chat input resize
   Pending:  0             |  
---------------------------+------------------------------------------------
Comment (by Gookey):

 Replying to [comment:76 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.

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