|Anonymous | Login||08-09-2020 06:22 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Advanced Details [ Jump to Notes ]||[ View Simple ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0000503||[Squeak] Morphic||minor||always||11-07-04 22:37||02-15-06 21:08|
|ETA||none||Fixed in Version||3.9||Product Version|
|Summary||0000503: [FIX] target setting menu items for sliders and buttons have never worked|
A slider or simple button morph grabbed from the supply bin will have no target until the target is set.
If you look at the menu code you will see that there is an item to set the targets. The menu item is never displayed because the code is badly flawed.
|Steps To Reproduce|
I wrote this one up several seasons back and posted it to squeakdev in several parts. I wrote a fix for sighting targets and modified the menu for sliders to use it.
I got one review from karl who wasn't sure why it would be useful. The great new look of 3.9alpha inspired me to take it out again and spiff it up.
I've also created a play with me example so you can see how powerful a tool this is.
The cs should work in any recent squeak and so should the project. The project was created in sq3.9a-6404. So I know it should work there.
Only the slider menu has been modified. If this fix gets into the squeak stream it should be easy to extend it to buttons.
TargetSighter-wiz.005.pr [^] (94,330 bytes) 11-07-04 22:37
TargetSighter-wiz.8.cs [^] (9,089 bytes) 11-07-04 22:40
PopupThumbnails-wiz.4.cs [^] (12,946 bytes) 12-13-05 04:25
PlainTargetSighting-wiz.1.cs [^] (7,784 bytes) 01-02-06 16:13
(0000684 - 3171 - 4134 - 4134 - 4134 - 4134 - 4134)
Here is a slightly edited and updated version of the original bug report:
[BUG] SetTarget misses
a version of this appear in sqeuakdev under the tiltle
[BUG] TargetOffset needs a hand.
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.
(self world rootMorphsAt: aHandMorph targetOffset) size > 1
ifTrue: [aCustomMenu add: 'set target' translated action: #setTarget:].
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@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.
>>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 i wanted the menu to work similar to “embed into” and designed a fix along those lines.)
Meta criticism sidebar:
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 by creating the target sighter.
Yours in service, -Jerome Peace
(0003305 - 56 - 56 - 56 - 56 - 56 - 56)
|Needs to be evaluated by the Morphic team for inclusion.|
(0003311 - 804 - 888 - 888 - 888 - 888 - 888)
edited on: 12-13-05 04:28
Thanks for your attention to this.
Since I wrote this I've discovered that this is an IMPORTANT fix and extention to Morphic. Here I have just used it to help one class. SliderMorphs. But I have found that targetsighting can be added as a menu item to anything that has a target. You then have the ability to take any widget be it slider or button or PopupImageMorph and find it a new target. Think about duplicating a widget from one morph and sighting the target of that widget onto another morph.
To see where TargetSighting is useful try this for evaluation purposes.
Get a sample instance of ThumbnailImageMorph or PopupThumbnailMorph.
Go to the red halo handle menu and select sight target and see how it works.
Yours in service, --wiz
(0003381 - 91 - 91 - 91 - 91 - 91 - 91)
|Hi, Rather than leaving this assigned to nil would someone please return the status to new?|
(0003419 - 372 - 402 - 402 - 402 - 402 - 402)
I've uploaded PlainTargetSighting-wiz.1.cs which now contains only morphic
Classes and *extentions. so it should be publishable without seeking further permissions.
This is essentially TargetSighter-wiz with a crosshair cursor instead of the fancier one I created. And renamed catagories for the extentions to the methods in the other non-morphic classes.
(0003873 - 762 - 876 - 876 - 876 - 876 - 876)
according to the changelogs, this is already in 3.9a:
Time: 12 January 2006, 1:33:41 pm
This version includes stuff from one or more of:
Mantis-1092-MorphDropFix, fix by Edgar De Cleene (edc) and Scott Wallace (sw)
Mantis-0503-TargetSighting, fix by Jerome Peace (wiz)
Mantis-1015-SnapView, fix by Jerome Peace (wiz)
Mantis-1771-ClickExerciser, fix by Jerome Peace (wiz)
Mantis-1625-Thumbnails, fix by Jerome Peace (wiz)
Mantis-1484-TrashHalo, fix by Jerome Peace (wiz)
Mantis-1454-ArrowPrototypeFix, fix by Jerome Peace (wiz)
Mantis-1347-ListDoubleClick, fix by Jerome Peace (wiz)
Reviewed by Juan Vuletich (jmv)
can you check?
(0003875 - 46 - 46 - 46 - 46 - 46 - 46)
|I checked with Juan: can be closed. Is in 3.9a|
|11-07-04 22:37||wiz||New Issue|
|11-07-04 22:37||wiz||File Added: TargetSighter-wiz.005.pr|
|11-07-04 22:40||wiz||File Added: TargetSighter-wiz.8.cs|
|11-14-04 03:06||wiz||Note Added: 0000684|
|12-12-05 16:17||cdegroot||Status||new => assigned|
|12-12-05 16:17||cdegroot||Assigned To||=> cdegroot|
|12-12-05 23:38||cdegroot||Note Added: 0003305|
|12-12-05 23:38||cdegroot||Assigned To||cdegroot =>|
|12-13-05 04:25||wiz||Note Added: 0003311|
|12-13-05 04:25||wiz||File Added: PopupThumbnails-wiz.4.cs|
|12-13-05 04:28||wiz||Note Edited: 0003311|
|12-27-05 06:23||wiz||Note Added: 0003381|
|01-02-06 16:13||wiz||File Added: PlainTargetSighting-wiz.1.cs|
|01-02-06 16:19||wiz||Note Added: 0003419|
|02-15-06 19:05||MarcusDenker||Note Added: 0003873|
|02-15-06 21:08||MarcusDenker||Status||assigned => closed|
|02-15-06 21:08||MarcusDenker||Note Added: 0003875|
|02-15-06 21:08||MarcusDenker||Resolution||open => fixed|
|02-15-06 21:08||MarcusDenker||Fixed in Version||=> 3.9|
|06-06-07 02:36||wiz||Relationship added||child of 0006530|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
90 total queries executed.|
57 unique queries executed.