#3639 NORM First D: Text view should be focused on click, not on mouse-enter

[Zarro Boogs per Child]

#3639: Text view should be focused on click, not on mouse-enter
---------------------------------------+------------------------------------
  Reporter:  Eben                      |       Owner:  uwog                  
      Type:  defect                    |      Status:  new                   
  Priority:  normal                    |   Milestone:  First Deployment, V1.0
 Component:  write-activity (abiword)  |     Version:                        
Resolution:                            |    Keywords:                        
  Verified:  0                         |  
---------------------------------------+------------------------------------

Comment(by Eben):

 I agree with you fully on point (1).  I think hiding the mouse when typing
 is a fantastic idea, and I'd be thrilled to get it implemented across the
 board.  This goes hand -in-hand with my earlier design to simply hide the
 mouse after some short period without mouse activity (regardless of
 keyboard activity) in order to get the cursor out of the way in an
 inherently fullscreen interface.  This would be useful in most
 applications, especially media activities and "consumption" activities
 such as Read and Browse where the cursor is infrequently needed.  We could
 simply modify this behavior to hide the mouse without delay when typing.

 With regards to (2), I also agree.  I'm a heavily shortcut-dependent user,
 but I also don't want to make the mistake of thinking that everyone will
 be naturally.  This doesn't even take into account the current brokenness
 of the keyboard focus algorithms within Sugar, which often get stuck in
 black holes and can't return to previously focused widgets. We need to
 make these interactions simple and intuitive without any kind of hints or
 training.  Clicking within the text obviously focuses the text area
 because it places the cursor at the location of the click.

 Even with both of these considerations, I still maintain that adjusting
 focus without explicit interaction is potentially confusing.  The two
 points above make it such that I wouldn't ''need'' to move the mouse out
 of the way, or click in the canvas to focus it, but they don't rid us of
 the unpredictability problem for any who don't happen to understand both
 principles.

-- 
Ticket URL: <https://dev.laptop.org/ticket/3639#comment:3>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system