[squeak-dev] The Inbox: Morphic-kfr.722.mcz
karl ramberg
karlramberg at gmail.com
Mon Jun 23 20:06:56 UTC 2014
I think there have been complaints but not much have been done to it.
I'm not sure yet if this change breaks any other functionality.These
widgets have quite complex behavior .
Karl
On Mon, Jun 23, 2014 at 9:34 PM, Chris Muller <asqueaker at gmail.com> wrote:
> 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 <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.
> >
> > 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]
> >> > "!
> >> >
> >> >
> >>
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140623/9b3ee00f/attachment.htm
More information about the Squeak-dev
mailing list
|