Please change the 2.4.0 input field's resize behaviour

Festival.Star festival.star at googlemail.com
Mon Mar 3 17:13:07 EST 2008


Etan Reisner schrieb:
> On Mon, Mar 03, 2008 at 06:57:52PM +0000, Mark Scott wrote:
> <snip>
>   
>>> Do you really regularly send IMs that are longer than four full lines?
>>>       
>> Yes, very often.  I've got several years of logs I can analyze if you'd
>> like hard stats.  There will be a mixture of paragraphs that flow,
>> unbroken, to more than four full lines and messages containing anywhere
>> from several to many explicit linefeeds.
>>
>>     
>>> Are
>>> these IMs something other than normal text (i.e. code snippets)? Are these
>>> longer IMs routinely five lines, six lines, some larger number, unbounded?
>>>       
>> Messages I exchange with colleagues run from one character to, I expect,
>> a dozen lines.  Code snippets, exception stacktraces, lists of
>> instructions, XML, problem descriptions etc..
>>
>> They're ultimately bounded by the MSN protocol's limit on message size.
>>  I don't know what that limit might be but do hit it occasionally.
>>     
>
> Yes, the current mechanism is most certainly tailored to IM usage which is
> the sending of short-to-middling sentential data, and very much not to the
> IM usage whereby large bits of multi-line data are sent back and forth.
> I'm not sure I think that is a bad thing, I feel reasonably comfortable
> stating that the overwhelming usage of IM is in fact the case we are
> tailored for currently.
>
> That being said, I do fully appreciate the other usage and would like to
> make it as painless as possible. If you could analyze your logs and
> determine what in fact your average message length (in lines) is and what
> your 'routine' maximum length is, I would find that incredibly interesting
> to know, and quite possibly very valuable (assuming your usage mirrors
> others with similar patterns).
>
>   
>> Looking at my current Pidgin 2.3.1 window I can see I have 12 lines
>> visible in the input field and 40 lines of conversation visible (with,
>> as it happens, 132 chars per line).
>>     
>
> I think, as Kevin indicated in his email, that IM windows of this size are
> rare, and that, as he also indicated, much of the design here was to allow
> for smaller yet functional windows.
>
> As above however I really don't want to penalize those that keep large IM
> windows, so suggestions for what could be done (other than adding the
> manual sizing back as an option, at least for the moment) are welcomed.
> Would a larger maximimum line allowance be acceptable? Would that resizing
> be too annoying?
>
>   
>>> Were you really happier having to either constantly resize the input area
>>> to accomodate these larger messages and then back down again to a normal
>>> size, or happier with an average of wasted space?
>>>       
>> Really much happier with what you consider "wasted space".  I wouldn't
>> have filed a report otherwise ;-)
>>
>> We clearly have different ideas on what's "normal".  I never found
>> myself constantly resizing anything.  Hardly ever, in fact.  I guess
>> that suggests 10 to 12 lines is, for me, enough to give sufficient
>> context to whatever I'm currently typing.
>>     
>
> I'm assuming given these statements that you in fact left your input area
> at 12 lines at all times and did not shrink it after your large messages.
> Which I believe is likely because of the large size of your IM window and
> the fact that even at 12 lines your history area was large enough to be
> useful. For many IM users 12 lines is not an input area size they could
> tolerate as their windows are notably smaller than yours.
>
> For example my conversation windows here at work contain ~20 lines of
> history with the default 2 line input area. (For full disclosure, or
> something. My window at home has a significantly larger history area but
> that is an artifact of the window management layout I use at home and not
> because I actively chose to make it that large.)
>
>   
>>> Is there some middle ground that would serve your purpose and yet provide
>>> the benefits of the cureent automatically resizing input area.
>>>       
>> IMHO your premise is flawed.  I don't see any benefit at all in an
>> auto-resizing area.  To me, it's too small and the auto-resizing is
>> distracting and irritating.  YMMV.
>>     
>
> Given your window size and your acceptance of a large input area even for
> messages which don't require it you don't see any of the benefits, but
> that doesn't mean they don't exist. The benefits are exactly for people
> for whom the normal two lines is sufficient greater than 90% of the time,
> but who for some part of the rest of the time need a larger input area to
> fit their message. The auto-resizing allows them to not have wasted space
> for the majority of their messages but to cleanly and automatically size
> up to accomodate double length messages, which returning immediately to
> the default size upon message sending.
>
> Do you not see the benefit to that (assuming the usage model I laid out)?
>
>   
>> Regards.
>>
>> --
>> Mark Scott
>> mark at codebrewer.com
>>     
>
> It is beginning to appear to me that there may very well be a usage case,
> like yours, for which the auto-resizing is just not a viable option. I'm
> assuming even if the widget sized itself to 12 lines on demand you
> wouldn't like the size changing. If that is in fact the case I'm not sure
> what option there really is other than to allow for disabling the
> auto-resizing entirely and switching back to manual resizing. But I
> haven't quite gotten there yet.
>
>     -Etan
>
> _______________________________________________
> Support mailing list
> Support at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/support
>   
I agree with your aggregation. If there is no possibility to have both
features. I can only see two options.

1) Having an option to make auto resizing available or not (would change
to manual resizing)
2) Letting the user decide which amount of default lines he woud like

I would prefer option number one.

Regards!




More information about the Support mailing list