I'd gotten tired of having to hit the little button at the top of the scroll-bar in order to bring up menus for the SystemWindows in Morphic. I thought I'd try to make the menus work with the "yellow" mouse button, as they do in MVC. After browsing related senders and implementors for a while, I realized that I was getting thoroughly lost. I can't seem to see the forest for the trees.
Where should I be looking to get a perspective on how input events, particularly the mouse, are handled with Morphic?
I did all this as part of the update: '061MorphicPaneMenus-di.
One thing that I noticed: it looks like any mouse button will act like the "yellow" one if the "Option" key is pressed. Trouble is, I don't have an option key. As I recall, that's something that's on the Mac? Does the Mac still sport a single button mouse? Sorry, I'm culturally deprived ;-)
Unfortunately I was confused about how we work the Mac option key and the "yellow" button. Here is a QUICK FIX, that we will issue later as an update with probably some changes that make it clear that optionKey can only be tested on the Mac.
!PluggableListMorph methodsFor: 'events' stamp: 'di 5/29/1998 11:13'! mouseDown: event onItem: aMorph event yellowButtonPressed ifTrue: [event shiftPressed ifTrue: [^ self shiftedYellowButtonActivity] ifFalse: [^ self yellowButtonActivity]]. model okToChange ifFalse: [^ self]. "No change if model is locked" ((autoDeselect == nil or: [autoDeselect]) and: [aMorph == selectedMorph]) ifTrue: [self setSelectedMorph: nil] ifFalse: [self setSelectedMorph: aMorph]! !
!TextMorphForEditView methodsFor: 'all' stamp: 'di 5/29/1998 11:14'! mouseDown: event event yellowButtonPressed ifTrue: [event shiftPressed ifTrue: [^ editView shiftedYellowButtonActivity] ifFalse: [^ editView yellowButtonActivity]]. ^ super mouseDown: event! !
Dan Ingalls wrote:
Unfortunately I was confused about how we work the Mac option key and the "yellow" button. Here is a QUICK FIX, that we will issue later as an update with probably some changes that make it clear that optionKey can only be tested on the Mac.
!PluggableListMorph methodsFor: 'events' stamp: 'di 5/29/1998 11:13'! mouseDown: event onItem: aMorph [snip]
!TextMorphForEditView methodsFor: 'all' stamp: 'di 5/29/1998 11:14'! mouseDown: event [snip]
These allow the menu to pop up with the yellow mouse button, but I found two further problems that keep it from working.
The first was getting 'does not understand' from the PluggableListView for messages that should have gone ot the Browser. The following is my correction for that:
'From Squeak 2.0 of May 22, 1998 on 29 May 1998 at 6:13:54 pm'!
!StringHolder methodsFor: 'code pane menu' stamp: 'wod 5/29/1998 16:35'!
perform: selector orSendTo: otherTarget "Selector was just chosen from a menu by a user. If can respond, then perform it on myself. If not, send it to otherTarget, presumably the editPane from which the menu was invoked."
(self respondsTo: selector) ifTrue: [^ self perform: selector] ifFalse: [^ otherTarget perform: selector]! !
The second problem manifests itself as this: When selecting an item from the menu by releasing the yellow button, sometimes it is acted upon and sometimes it is ignored. This seems to be quasi-random. Certain list menus seem to work all the time, some seem never to work and the Browser text pane seems to work/not work at random.
What I've managed to track down is this:
MenuItemMorph>>mouseUp: evt is ignoring the event because mouseInMe := self bounds containsPoint: evt cursorPoint. is evaluating to false. When this is working (like from the scroll-bar menu button), both 'bounds' and 'cursorPoint' are in display coordinates. The event "evt" is passed in from HandMorph>>handleMouseUp: which does oldFocus mouseUp: (self transformEvent: evt) The problem comes from the 'eventTransform' of the HandMorph. In the case I investigated, the transform has negative offset equal to the display coordinates of the PluggableListMorph's origin.
Why this is so, or how to fix it, has me baffled. Any Morpher out there with an easy answer?
------------------------------------------- Bill Dargel wdargel@shoshana.com Shoshana Technologies 100 West Joy Road, Ann Arbor, MI 48105 USA
Bill Dargel wrote...
The second problem manifests itself as this: When selecting an item from the menu by releasing the yellow button, sometimes it is acted upon and sometimes it is ignored. This seems to be quasi-random. Certain list menus seem to work all the time, some seem never to work and the Browser text pane seems to work/not work at random.
What I've managed to track down is this:
MenuItemMorph>>mouseUp: evt is ignoring the event because mouseInMe := self bounds containsPoint: evt cursorPoint. is evaluating to false. When this is working (like from the scroll-bar menu button), both 'bounds' and 'cursorPoint' are in display coordinates. The event "evt" is passed in from HandMorph>>handleMouseUp: which does oldFocus mouseUp: (self transformEvent: evt) The problem comes from the 'eventTransform' of the HandMorph. In the case I investigated, the transform has negative offset equal to the display coordinates of the PluggableListMorph's origin.
Why this is so, or how to fix it, has me baffled. Any Morpher out there with an easy answer?
Yes. Here's the explanation... The problem is that the yellowButton path to pane menus runs through some compatibility code that loses the proper event trail. In the process, the Hand, which was caching the coordinate transform (roughly = scrolling offset) for the text or list in focus, suddenly gets told to direct its events at a menu that is at the top level, and thus in screen coordinates.
....and here's the fix... in HandMorph>>newMouseFocus:, add the following statement at the end:
self updateMouseDownTransform
Thanks for your other sleuthing. We'll get a new update for this out anon.
- Dan
squeak-dev@lists.squeakfoundation.org