[BUG] TargetOffset needs a hand

Peace Jerome peace_the_dreamer at yahoo.com
Sun Jul 18 04:51:31 UTC 2004


How do you set the target on a slider or a button or a
...

There is an entry in the menu for setting the target
if it can find one.
Which uses:

(self world rootMorphsAt: aHandMorph targetOffset)
size > 1
		ifTrue: [aCustomMenu add: 'set target' translated
action: #setTarget:].
	target
		ifNotNil: [aCustomMenu add: 'clear target'
translated action: #clearTarget]
		
	Now rootMorphsAt: expects a relevant point in world
as its argument. What has been passed to it instead is
the dinky target offset. Which gives a irrelvant
location unless the hand position happens to be 0 at 0
anyway (on a 1024x786 screen what are your chances.)
So the only way to get the menu item to appear is to
place two copies of your target in the upper right
hand corner of your screen and bring up the red menu
on the slider.
	
	I don't think this is what anyone really intended.
This bug has been around so long its aquired viral
qualities.The phrase
	 (self world rootMorphsAt: aHandMorph targetOffset)
appears to have been adopted by most of the target
setters.
	
	This is probably one of the reasons Button porperties
is not working.
	
	MenuMorph
	SimpleButtonMorph
	SimpleSliderMorph
	and
	StringButtonMorph
	>>setTarget: all use this phrase
	the latter three use it in
	>>addCustomMenuItems:hand:  to test for a settable
target.
	
	as does MovieMorph: (also in >>insertIntoMovie:).
	
The correct argument is probably (hand pos - hand
targetOffset) but the whole shebang wants to be
factored into something like hasTarget and
aquireTarget. (Note: I later tried variations of
points but did not seem to be able to improve things.
I finally realized wanted the menu to work similar to
embed into and designed a fix along those lines.)
	
	I am trying to program my stuff and besides being
unsure of what the correction actually is I am a
little angry that the care takers of squeak have taken
so little care. Hopefully one of the responsible
parties for the perpetuation of this bug will take
responsibility for tracking down implementing and
testing the fix.  Please note that this is a stealth
bug that users can't see because the hasTarget test
will fail hiding the menu item that would cause the
bugged aquireTarget code to noisily fail. I wonder if
the tests were added as a "bug fix" in the first
place.  
	
	The meta on this is that squeak desprately needs code
reviewers to look at and run thru the code. Designate
what is good bad or ugly code and start fixing or
excising the ugliest.
	
	In theory squeak smalltalk is a dream to work with,
In practice I'm finding its a bug garden. Its not
really worth making a commitment to improving squeak
unless there is a commitment on the part of its
keepers to get rid of the bugs and to find ways of
preventing them from being introduced.

I wrote the above in the heat of frustration and
tiredness.  In a more curious spirit I later went back
and solved the problem for SimpleSliderMorph.

-----

'From Squeak3.7beta of ''1 April 2004'' [latest
update: #5967] on 17 July 2004 at 11:28:03 pm'!
"Change Set:		SetTargetsBugFix-wiz
Date:			17 July 2004
Author:			Jerome Peace (wiz)

For buttons and sliders #setTarget: is bizarrely
bugged. I've written about this elsewhere so I won't
document it here.

I believe this fixes target setting in
SimpleSliderMorph. If havesters agree then I hope they
will find someone to propagate the fix to buttons and
button properties.  And please reap out the bugged
setTarget methods from the image.  

Blind code copying has turned one bug into many. I
can't stress this enough bugged code was COPIED with
out ever being properly tested. Indeed it looks as if
tests containing the same bug were put into the menus
to hide the bug from being DETECTED. The result is
useless, unusable unused code being propogated as if
it were correct. 

Question for Harvesters: What should the Story for
targets of sliders and buttons be? For the fix I have
use the modified story for embed morph. I can also
imagine a story that says:

'to aquire a target for the button you drag the james
bond crosshair handle from the halo of the slider over
the object to be targeted and lift the mouse. If more
than on object is under the cross hair a menu is
given. If only the world paste up is under the cross
hair nothing is changed.'

Alternate to the menu idea the cross hair could pick
the topmost morph as target.

So harvesters what should the story be. Do you know
who would implement it?"!


!Morph methodsFor: 'meta-actions' stamp: 'wiz
7/17/2004 22:17'!
potentialTargets
	"Return the potential targets for the receiver.
	This is derived from
Morph>>potentialEmbeddingTargets."
	owner ifNil:[^#()].
	^owner morphsAt: self referencePosition behind: self
unlocked: true not! !

!Morph methodsFor: 'meta-actions' stamp: 'wiz
7/17/2004 23:27'!
targetWith: evt
	"Some other morph become target of the receiver"
	|  menu newTarget |
	menu _ CustomMenu new.
	self potentialTargets  do: [:m | 
		menu add: (m knownName ifNil:[m class name
asString]) action: m].
	newTarget _ menu startUpWithCaption: ( self
externalName, ' targets...').
	newTarget ifNil:[^self].
	self target: newTarget.! !


!SimpleSliderMorph methodsFor: 'menu' stamp: 'wiz
7/17/2004 22:34'!
addCustomMenuItems: aCustomMenu hand: aHandMorph

	super addCustomMenuItems: aCustomMenu hand:
aHandMorph.
	aCustomMenu addLine.
	aCustomMenu add: 'set action selector' translated
action: #setActionSelector.
	aCustomMenu add: 'change arguments' translated
action: #setArguments.
	aCustomMenu add: 'set minimum value' translated
action: #setMinVal.
	aCustomMenu add: 'set maximum value' translated
action: #setMaxVal.
	aCustomMenu addUpdating: #descendingString action:
#toggleDescending.
	aCustomMenu addUpdating: #truncateString action:
#toggleTruncate.
	aCustomMenu add: 'set target' translated action:
#targetWith: .
	target ifNotNil: [
		aCustomMenu add: 'clear target' translated action:
#clearTarget].
! !


!

The Gzipped changeSet is attached. 

Yours in service, -Jerome Peace

P.S. You should  remove the postscript.  Though here
it does not change anything the comment suggests it
changes the color of literals to orange. I removed the
changed code from the change set but forgot to delete
the Dialect stream reinitialzation. Thanx -Jer




	


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SetTargetsBugFix-wiz.2.cs.gz
Type: application/x-gzip
Size: 1422 bytes
Desc: SetTargetsBugFix-wiz.2.cs.gz
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20040717/2fde9ac5/SetTargetsBugFix-wiz.2.cs.bin


More information about the Squeak-dev mailing list