[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 eddyp):

 Replying to [comment:124 seanegan]:
 > Replying to [comment:122 eddyp]:
 > > I will not get into any bashing or complaining, I'll just propose a
 strategy for a fix.
 > >
 > > '''Proposal for the fix:'''
 > >
 > > '''Just grow when needed and let me set the minimum; I must also be
 able to set a fixed input area, if I want to, just as it was before.'''
 >
 > This is what I originally tried doing (every version of Pidgin attempts
 to do this, but people don't realize because it's so broken), but it turns
 out to be near impossible. GTK+ doesn't like to let you programatically
 resize things after the user has manually sized it.

 Maybe there is a good reason for that: '''an application must not decide
 for the user about preferences, ''especially'' after he/she made some
 manual tweaks'''.

 I'd call that a feature of GTK :-) (but still, I understand why this can
 be an issue, being a programmer myself).

 > These new 2.4.0 changes started as trying to fix it, realizing how hard
 it was, asking "hey, does anyone care if manual-resizing just goes away
 altogether, getting a general consensus, and working on it together until
 we had it behaving as we thought was best"

 Which, still, doesn't make it a good decision, judging from the huge
 number of replies to this BR. Heck, many people think reverting would be
 an improvement now (and that wouldn't mean that it can't be reintroduced
 after is reworked to work well for everybody).

 > > '''Description:'''
 > > Because nobody complained it was too big before.
 >
 > I think you mean "I didn't complain it was too big before." Unless you
 follow devel at pidgin.im (the mailing list and the XMPP conference), our IRC
 channel, all the Trac tickets, and personal IMs and E-mails to developers,
 you can't really speak for nobody. And I know that you don't, because they
 did complain. I'm *still* complaining it's too big.

 I stand corrected, "nobody I knew of".

 Still, I think the people that commented vehemently against the change
 this ticket wants to address, are probably, in majority, in favour of
 rather keeping the old big-sized default, rather than having the 2-liner
 autosized input box (unless they can change the default).

 > > '''* by default, when the text in the input area imposes a scroll bar,
 grow automatically; after sending the message, the input area should
 restore its size to the default'''
 > >
 > > Because, if someone found the energy to implement this, probably he
 likes this behaviour.
 >
 > And as I mentioned above, this **has** been the behavior for some time.

 And since nobody complained about the auto-growing until now, they, most
 likely, didn't felt the feature '''impeded''' the way they used pidgin, it
 was transparent to them. Thus I, with all due modesty, say that the
 implementation was on the right track at that time. Which, clearly, can't
 be said now, since so many people complained.

 About the impeding part and relative to the current state of affairs, it
 can't be said the same; '''now people ''are'' impeded by the way the UI
 works''' . Read below to understand why.

 > > '''* add a small icon with a lock and an up-down arrow - will show if
 input's size is locked ; this should be a tri-state: resize (setting
 stored globally)/lock this dialog (will not be stored)/lock all dialogs
 (stored and globally true)'''
 > >
 > > Because some people will disable automatic resizing for a conversation
 or even globally.
 >
 > Nobody ever asked to before, (and that's an **actual** nobody), so I
 doubt we need this complication.


 I think you're missing the point of this. This is would actually make all
 camps happy: autoresizers, fixed-input fans, developers and all the ones
 that complained here (I really want some person to prove me wrong by
 providing a realistic scenario that wouldn't be addressed correctly by the
 proposal I made).

 To expand why this is necessary and why people would be happy:
  * autosizers get their desired behaviour by default
  * the occasional cases when a user needs a bigger input area for a
 conversation (while generally being happy with autosizing) can do that,
 but without risking to have fixed size until the end of  days
  * the large amount of people that commented here that always want a fixed
 input area get that with the third option; to reiterate, this group
 includes:
    * people that are distracted and/or annoyed  by the dynamic UI
    * space-happy people
    * the large majority of people that just don't know that the entire
 window is a typing area (not focus input area, since the cursor is placed
 in the conversation area)
    * people that often use large message areas
    * people that want to decide for themselves the size of the input area
    * people feeling that the maximum line count of 4 is not enough
  * '''developers''' : this would allow you, developers:
    * fix the regression introduced: the ability to manually resize the
 input area was lost
    * not to over-complicate things in the code by saving in the
 configuration file things "conversations with johnny always use a fixed
 size window, but in general the input area should be as indicated by the
 config
    * leave the decision of the correct behaviour to the user, where it
 belongs - is obvious that some people like autogrowing, others hate it and
 their views range so widely that you simply can't please everybody with
 one default option (without allowing a way out)
    * close this bug properly

 This would also be good UI design because it puts really upfront the
 method to obtain the desired behaviour, no matter which that is (the
 visual hint of a lock with an up-down arrow, I think is suggestive).


 > Thanks for your comment; it's more constructive than most :)

 I hope you'll feel the same about this one, too :-) .

 > The main problem is getting GTK+ to play nice with auto-resising and
 user-resizing. If anyone wants to submit a patch that gets it all right, I
 would gladly accept it.

 With the risk of sounding like a troll, until such a patch appears,
 please, please, please revert the change, or at least, offer a way to
 allow the user to choose the input area minimum size (which is, I think,
 the most annoying thing, since, as you said, auto-growing was already
 present
 but nobody saw such a big problem with it to such a level to send tons and
 tons of comments about it).


 '''As a conclusion, the problem with this change is that it has multiple
 flaws and this is why people are unhappy now:'''
  * introduces a regression - always bad - (no way to resize, which was
 possible before)
  * people loose control over application's behaviour (no manual override)
  * changes dramatically a default UI appearance (a lot smaller input area
 than before)
  * changes dramatically the default UI behaviour (the input area grows
 now, while before it was static)
  * changes the way people expect the UI to work (can't manually override
 the default input)
  * changes the way people expect the UI to work(2) (the autogrow is
 counterintuitive, at least for some people)
  * even when the autogrow works, it is broken (since it has a too small
 max limit of visible lines)
  * even when the autogrow works, it is broken(2) (the 4 lines max is
 arbitrary, something like "as big as possible, but not more than the size
 that would allow displaying at least the last line of the conversation"
 would be more sane)
  * people are not aware that the whole window is a typing focus area

 While some points might overlap partly, this is not that relevant since
 the whole mix is the reason for the HUGE wave of unhappy people commenting
 to the ticket. OTOH the various angles from which people justify the
 reason NOT to like the autogrowing-initially-small-input-area-but-with-
 small-max feature ;-) is justified in one of these cases.


 My proposal tries to fix all of the ones that can be technically fixed
 (the last one can't be fixed through coding) and also allow the new
 behaviour to enter the application in a way that doesn't make people
 unhappy.

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