Hi guille
I was cleaning the event and we were slow to integrate the refactoring
we did with igor. And now this is obsolete
because there is OSWindow coming.
We are about to integrate OSWindow code and soon or later we will have
probably to change the processEvent: code.
Stef
On 18/8/14 17:33, Guillermo Polito wrote:
Hi!
Most of you already know that in Mac, if you do cmd+click on a class
name or a selector, you get to browse the class or the implementors of
the method.
Now, most of you know that it does not work on linux :). So I was
digging today and I'll share a bit here what I found...
First, the navigation through cmd+click is managed by the
TextAttribute subclasses, in particular TextLink, TextClassLink and
TextMethodLink. And these are the important methods:
TextLink>>mayActOnEvent: anEvent
^ anEvent isMouseUp and: [ anEvent commandKeyPressed ]
TextClassLink>>actOnClick: anEvent for: target in: aParagraph editor:
anEditor
anEvent shiftPressed
ifFalse: [ anEditor browseClassFrom: self className ]
ifTrue: [ anEditor referencesTo: self className ].
^ true
And another similar in TextMethodLink.
Now, the first thing I tried was to add a "or: [ anEvent
controlKeyPressed ]" into the first method. Guess what? That did not work.
So I noticed a weird behavior.
- On mac: When you do cmd+click, the text morph, if it was not
selected, gets selected on mouse down, and on mouse up it gets
deselected and the class is browsed.
- On linux: when you do a ctrl+click, the text morph never gets
selected on the first place. And that's why it never handles the
mouseUp:. Just check:
Morph>>handleMouseUp: anEvent
"System level event handling."
anEvent wasHandled ifTrue: [^self]. "not interested"
*==> anEvent hand mouseFocus == self ifFalse: [^self]. "Not interested
in other parties"*
So... the question is, why is the text morph not getting the focus?
Well, it turns out that morphic decodes a Ctrl+click as a blueButton.
So in the method Morph>>handlerForMouseDown: the execution differs
between mac and linux.
And weirder, the event that arrives there, is modified by some strange
table that I hate. So the event has a SHIFT, which I didn't press!
That shift gets introduced in the event in here:
InputEventSensor>>processEvent: evt
...
...
type = EventTypeMouse
ifTrue: [
"Transmogrify the button state according to the platform's button map
definition"
*evt at: 5 put: (ButtonDecodeTable at: (evt at: 5) + 1).*
"Map the mouse buttons depending on modifiers"
*evt at: 5 put: (self mapButtons: (evt at: 5) modifiers: (evt at: 6)).*
So much FUN!
Well, so far I do not know how to solve it. But I know I do not like
the "One table to decode strangely bits that should work for all
platforms but it works just for one of them" approach :)
I'll try to follow this later, but if someone wants to help, I welcome
it :)
Guille
