The Inbox: Morphic-kfr.722.mcz

Ah, I see now.  That's surprising; I'm suprised no one complained
about that before..

On Mon, Jun 23, 2014 at 12:15 PM, karl ramberg <[hidden email]> 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.
>
> Karl
>
>
> On Mon, Jun 23, 2014 at 5:18 PM, Chris Muller <[hidden email]> 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,  <[hidden email]> 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]
>> >   "!
>> >
>> >
>>
>
>
>
>

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 <[hidden email]> wrote:
> Hi Karl,
>
> On Mon, Jun 23, 2014 at 10:15 AM, karl ramberg <[hidden email]>
> 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 <[hidden email]> 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,  <[hidden email]> 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
>
>
>

On 24/06/2014, at 19:27, Javier Diaz-Reinoso <[hidden email]> wrote:

> On 24/06/2014, at 01:19, Marcel Taeumel <[hidden email]> wrote:
>
>> Well, I think it basically is a good idea to respect that preference
>> "mouseOverForKeyboardFocus". However, you cannot simply access this
>> preference in ScrollPane>>handlesMouseOver: because scroll panes may handle
>> mouse over in other cases than keyboard focus change. In
>> PluggableListMorph>>mouseUp:, this seems to be more appropriate because here
>> you have the code that can actually set the keyboard focus.
>>
>> Please, adapt your modification and check for the preference in, e.g.,
>> PluggableListMorph>>mouseUp:. #mouseEnter: should grab the keyboard if this
>> preference is true. #mouseUp: could ensure it if that preference is false.
>>
>> Best,
>> Marcel
>
> What about this modification of PluggableTextMorph>>mouseEnter: ?

> <PluggableTextMorph-mouseEnter.st.gz>

Sorry, the condition is reversed:

Well, I think it basically is a good idea to respect that preference
"mouseOverForKeyboardFocus". However, you cannot simply access this
preference in ScrollPane>>handlesMouseOver: because scroll panes may handle
mouse over in other cases than keyboard focus change. In
PluggableListMorph>>mouseUp:, this seems to be more appropriate because here
you have the code that can actually set the keyboard focus.

Please, adapt your modification and check for the preference in, e.g.,
PluggableListMorph>>mouseUp:. #mouseEnter: should grab the keyboard if this
preference is true. #mouseUp: could ensure it if that preference is false.

Best,
Marcel



--
View this message in context: http://forum.world.st/The-Inbox-Morphic-kfr-722-mcz-tp4764223p4764449.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.