I am in. Using linux and hating the current behavior. Phil Le 18 août 2014 19:30, "Guillermo Polito" <guillermopolito@gmail.com> a écrit :
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