--On Wednesday, December 30, 2009 22:40:36 -0500 I wrote:

> OK, I have a solution, which works fine for me, though it isn't
> necessarily generic. The mouseovers I need to preserve on a touch screen
> are all in my own code. So, all I have to do is add
> handlesMouseOverDragging:, mouseEnterDragging:, and mouseLeaveDragging:
> to the appropriate classes and have it just send the non-dragging
> messages to self. This is so simple it's a bit embarrassing. I've tried
> it, and it works!

For the record, if someone else happens to be following down this path, I 
need to amplify this. There is some extra secret sauce you need besides 
using the *Dragging: methods. You *do* have to intervene in the normal 
mouseDown process to "turn it off" when a morph does not really need to 
handle it. I had implemented this in my test class, and it wasn't working 
until I implemented the *Dragging: methods, so I hadn't realized this was 
also necessary until I tried to get it all working in a "normal" 
PasteUpMorph.

Below is the hack I put in my subclass of PasteUpMorph. Any morph that 
would normally handle mouseDown that needs to ignore it when the screen is 
touched for the mere purpose of moving the mouse -- i.e. for an 
"exploratory drag" -- needs to "reset" mouse state as at the end of the 
method below.

*DISCLAIMER*: This all seems to be working for me, but I am still a newbie 
at the internals of hand and mouse event processing. There is a very good 
chance this method is not sufficiently general, and there's some subtlety 
somewhere I'm overlooking. It's pretty easy to think you've got things 
working, and then find there's a gap when the mouse is dragged over some 
morph you haven't thought of and then a new "exploratory drag" is started. 
This all is very much a cheap and dirty hack, and the problem really should 
be thought through at a fundamental level by someone who really knows the 
event processing code extremely well.

UI design is full of assumptions that are stood on their head on a touch 
screen. Mouse-down, dragging -- these are taken for granted in UI design as 
deeply *intentional* acts. You tend not to think about the implications of 
"exploratory drag" until you actually have a touch screen in your hands.

Ideally, there would be some central Squeak preference that governs how all 
this works.

----

mouseDown: anEvent
	"Touch screen behavior hack: if a submorph needs to respond to the event 
as a button,
	keep normal behavior. Otherwise reset hand for 'no mouse down' behavior"

	self submorphs do: [:m|
		(m containsPoint: anEvent cursorPoint event: anEvent) ifTrue: [
			(m respondsTo: #handlesMouseUp) ifTrue: [
				(m handlesMouseUp: anEvent) ifTrue: [
					^ super mouseDown: anEvent
				]
			]
		]
	].
	anEvent hand
		newMouseFocus: nil;
		resetClickState.


---
 Jim Rosenberg                      http://www.well.com/user/jer/
     Internet: jr at amanue.com