[Pidgin] #4986: automatic chat input field resizing should be optional, regression from 2.3
Pidgin
trac at pidgin.im
Wed Mar 5 17:33:08 EST 2008
#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
More information about the Tracker
mailing list