I'm on Windows. But accidental mouse movement has more to do with the
working environment. I really don't like using the touch pad on my laptop
and I use a mouse when ever I can. So slouching on the couch, hacking
Squeak with a mouse is prone to accidental mouse movements. Thus this
change.

Karl


On Mon, Jun 23, 2014 at 10:13 PM, Chris Muller <asqueaker at gmail.com> wrote:

> LOL!!  Funny for Mac's to be considered so great on ergonomics for
> them to have such issues with accidental mouse movement..!  Better to
> use a system which, as a whole, provides the user with uniform and
> fluid interaction with the machine; e.g., only direct and deliberate,
> not accidental, (pointing) gestures.  I think pointing is one of the
> most under-appreciated and under-utilized gestures in UI design.
>
> This change would seem to be more consistent with standard
> click-for-focus.  I just wonder whether some folks will miss being
> able to scroll with the keyboard without having to click somewhere in
> the list first (e.g., to use the either the arrows, page-up/down or
> typing letters to scroll)..
>
>
> On Mon, Jun 23, 2014 at 2:26 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> > Hi Karl,
> >
> > On Mon, Jun 23, 2014 at 10:15 AM, karl ramberg <karlramberg at gmail.com>
> > wrote:
> >>
> >> Before this change, moving the mouse out of a text or list pane meant it
> >> lost keyboard focus.
> >> Even if the Preferences mouseOverForKeyboardFocus was false.
> >> With this change you have to click the pane you want tho have keyboard
> >> focus.
> >>
> >> I find working with this change is less aggravating since I very often
> >> bump the mouse out of small text boxes and panes.
> >>
> >>
> >> It also means the preference does what it say it will do.
> >
> >
> > This sounds like manna from heaven.  I vote for including this in trunk.
> >
> >> Karl
> >>
> >> On Mon, Jun 23, 2014 at 5:18 PM, Chris Muller <asqueaker at gmail.com>
> wrote:
> >>>
> >>> Can you explain what effect this has for regular interaction with an
> >>> image?  It's not obvious to me.
> >>>
> >>> On Sun, Jun 22, 2014 at 10:04 AM,  <commits at source.squeak.org> wrote:
> >>> > A new version of Morphic was added to project The Inbox:
> >>> > http://source.squeak.org/inbox/Morphic-kfr.722.mcz
> >>> >
> >>> > ==================== Summary ====================
> >>> >
> >>> > Name: Morphic-kfr.722
> >>> > Author: kfr
> >>> > Time: 22 June 2014, 4:59:39.758 pm
> >>> > UUID: fffb2b9e-3b71-f341-9042-4e35e7cc19fa
> >>> > Ancestors: Morphic-cmm.721
> >>> >
> >>> > Make keyboard focus respect Preferences mouseOverForKeyboardFocus.
> With
> >>> > this change one has to click for keyboard fokus.
> >>> >
> >>> > =============== Diff against Morphic-cmm.721 ===============
> >>> >
> >>> > Item was changed:
> >>> >   ----- Method: PluggableListMorph>>mouseUp: (in category 'events')
> >>> > -----
> >>> >   mouseUp: event
> >>> >         "The mouse came up within the list; take appropriate action"
> >>> >         | row |
> >>> >         row := self rowAtLocation: event position.
> >>> >         "aMorph ifNotNil: [aMorph highlightForMouseDown: false]."
> >>> >         model okToChange
> >>> >                 ifFalse: [^ self].
> >>> >         "No change if model is locked"
> >>> >         row = self selectionIndex
> >>> >                 ifTrue: [(autoDeselect ifNil: [true]) ifTrue:[row = 0
> >>> > ifFalse: [self changeModelSelection: 0] ]]
> >>> >                 ifFalse: [self changeModelSelection: (self
> >>> > modelIndexFor: row)].
> >>> > +       event hand newKeyboardFocus: self.
> >>> > +       hasFocus := true.
> >>> >         Cursor normal show!
> >>> >
> >>> > Item was changed:
> >>> >   ----- Method: ScrollPane>>handlesMouseOver: (in category 'event
> >>> > handling') -----
> >>> >   handlesMouseOver: evt
> >>> >         "Could just ^ true, but this ensures that scroll bars won't
> >>> > flop out
> >>> >         if you mouse-over appendages such as connecting pins."
> >>> >         self flag: #arNote. "I have no idea how the code below
> could've
> >>> > ever worked. If the receiver does not handle mouse over events then
> it
> >>> > should not receive any #mouseLeave if the mouse leaves the receiver
> for
> >>> > real. This is because 'evt cursorPoint' describes the *end* point of
> the
> >>> > movement and considering that the code would return false if the
> move ends
> >>> > outside the receiver the scroll bars should never pop back in again.
> Which
> >>> > is exactly what happens with the new event logic if you don't just
> ^true.
> >>> > I'm leaving the code in for reference - perhaps somebody can make
> sense from
> >>> > it; I sure cannot."
> >>> > +  ^Preferences mouseOverForKeyboardFocus
> >>> > -       ^true
> >>> >   "
> >>> >         | cp |
> >>> >         cp := evt cursorPoint.
> >>> >         (bounds containsPoint: cp)
> >>> >                 ifTrue: [^ true]
> >>> >                 ifFalse: [self submorphsDo:
> >>> >                                         [:m | (m containsPoint: cp)
> >>> > ifTrue:
> >>> >                                                         [m ==
> scrollBar
> >>> >
> ifTrue:
> >>> > [^ true]
> >>> >
> >>> > ifFalse: [^ false]]].
> >>> >                                 ^ false]
> >>> >   "!
> >>> >
> >>> >
> >>>
> >>
> >>
> >>
> >>
> >
> >
> >
> > --
> > best,
> > Eliot
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140624/4cf0cf46/attachment-0001.htm