[Pidgin] #5630: Create Whitespace boundary for the new input box

[Pidgin]

#5630: Create Whitespace boundary for the new input box
---------------------------+------------------------------------------------
  Reporter:  arnabdotorg   |       Owner:        
      Type:  enhancement   |      Status:  closed
  Priority:  minor         |   Milestone:        
 Component:  pidgin (gtk)  |     Version:  2.4.1 
Resolution:  wontfix       |    Keywords:        
   Pending:  0             |  
---------------------------+------------------------------------------------
Comment (by arnabdotorg):

 Thanks for taking the time to reply to my ticket.

 ''First, the fact that more places don't let you click with more freedom
 is a problem, the fact that pidgin does is good. Yes, it means teaching
 people about it, and we do when it comes up. This has no real bearing on
 anything else here.

 Second, you can't "fix" the "except the tab" behaviour because that isn't
 broken. Clicking in the tab has a real usage and keyboard focus has reason
 to be there. There are tab-specific keybindings that work there and/or
 which can be added there. So fixing that exception would break other
 things.''

 I agree on your two points. re: tab behavior, I was trying to exhibit that
 each UI item has a predetermined purpose, which you corroborate; I should
 have done a better job with my sarcasm there.

 ''The typing area can't be made "more visible" it can only be made larger.
 Given that the entire window is a click target we see little reason to
 make it larger (not to mention that part of the resizing idea was to let
 it be smaller in the first place).''

 The entire window is usually composed of (a) the chat transcript, (b) the
 input window, (c) the formatting bar, and (d) the OTR button(last one is
 not common, i think).

 ''If you are seeing only a single pixel of input area behind your
 formatting toolbar that is a *bug* that is largely fixed in 2.4.1''

 As mentioned in the original text, I am running Ubuntu 8.04. I have
 confirmed it looks the same as what it does on my Windows install.

 My pain points, which you have brushed away with subjective comments like
 "I dont think", without giving any real logic or evidence:

 1. The metaphor for clicking on the transcript is to SELECT IT, for
 purposes of copy/pasting text. (I will use Firefox as a comparison, since
 it targets the same demographic / platforms). Double click is select-all,
 click > shift + cursor is caret select. Click + drag is select, for copy.
 This is what I would consider as "accepted standard". You are implying
 that you are hijacking this metaphor for your own purpose.

 2. The toolbar occupies almost as much space as the input box. The toolbar
 is intense, with lots of icons and lines. The input box is plain white. If
 you run an eye-tracking experiment, you will have evidence that the
 toolbar will have at least 2X the amount of attention as compared to the
 text box, even though the toolbar is a contextual assistant to the text
 box.

 3. The whitespace will add weight (in terms of attention) to the text
 entry box, and seemed like a viable compromise as you will be using up 5-6
 more pixels height / width, in comparison to the 16 or so you will be with
 a 3-line box.

 I use both Adium and Pidgin; and there are subtle behaviors that are
 expected to be different because of the environments they are installed
 into. Claiming that your behaviors and UI paradigms outweigh those of the
 native environment is good when you have a logical, evidence-based
 rationale. I tried reading up on this, and my searches failed to find
 anything put out by the developers that give a sound reasoning, except for
 "we think we are right" and "we are staying the course", and "there's no
 pulling out now".

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