I am in. Using linux and hating the current behavior. Phil Le 18 août 2014 19:30, "Guillermo Polito" <[email protected]> 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 >
