|Anonymous | Login||01-28-2020 22:56 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0001347||[Squeak] Morphic||minor||always||06-15-05 03:32||02-15-06 19:00|
|Summary||0001347: Doubleclick on list entries not working properly|
|Description||Easy way to demostrate - inspect #(1 2 3) and select 1. Then try to doubleclick it. Doubleclick should open a new inspector, but it's very difficult to do, because the first click usually deselects the list entry. Primary victims are inspectors and debugger.|
Inspector3.8DClickFix-wiz.2.cs [^] (3,234 bytes) 06-20-05 02:21
Inspector3.8DClickFix-wiz.3.cs [^] (3,344 bytes) 07-04-05 04:58
Browser-buildClassList-wiz.st [^] (732 bytes) 07-20-05 06:55
IB3-8DClickFix-wiz.5.cs.gz [^] (1,770 bytes) 07-20-05 18:25
SYSTEM WARNING: Creating default object from empty value
(0001653 - 1995 - 2149 - 2149 - 2149 - 2149 - 2149)
edited on: 07-04-05 05:05
inspectors do not disable the autoDeselect Boolean. So the mouse up action on a selected item deselects it before the double click action can take place.
I am uploading a fix that has Inspector use a PluggableListMorph (PLM) with the autoSelect deselected. That solves the problem for inspectors.
As I was examining this bug I found that the PLM>mouseup logic was somewhat tortured.
So I fixed that as well. Now the index is looked at to see if it needs changing first. If it does it is. Only if it doesn't will autoDeselect be checked to see if it needs deselecting. This corrected logic is needed to make things work properly for Inspectors.
It turns out that the setIndexSelector for Inspectors was #toggleIndex and that action would deselect anything already selected. The old tortured logic didn't work well with that action.
This streamlines things because no furthur action is taken when an item is selected twice. (when autoDeselect is disabled). The caveat is if any model wishes to take an action when an item is selected twice in a row that model will have to be fixed or use a PLM that autoDeselects.
There are only two methods that are changed. The Inspector method in the upload is specific to 3.8-6665 (and later?) because that method was changed since 3.7-final full. In back patching previous versions the important thing is to send the "autoDeselect: false" phrase at the appropriate point.
Conclusion: These two patches will fix doubleclicking for Inspectors at the trade off of having something always selected in the PLM of instance vars.
It may have an affect on any other morphs that use PLMs if they were written to work around the faulty PLM>mouseUp: logic.
Putting this cs into the update stream is recommended.
Uploaded (Inspector3.8DClickFix-wiz.3.cs) a further refinement to the PLM>>mouseUp: fix. Now the logic is elegant with all tests being performed exactly when they should be. This will make the method faster as well.
(0001731 - 168 - 184 - 227 - 227 - 227 - 227)
|This also affects opening a Hierarchy Browser on a class by double-clicking on it in the class list in a browser. Reported by "Adrian Lienhard" <firstname.lastname@example.org>|
(0001768 - 374 - 374 - 374 - 374 - 374 - 374)
|The fix Inspector3.8DClickFix-wiz.3.cs does not solve the problem in the code browser which is the following: in a code browser select a class and double-click the selected item in the list. This should open a hierarchy-browser but it just deselects the currently selected class. If the class in the list is not selected, double-clicking correctly opens a hierarchy browser.|
(0001844 - 773 - 837 - 837 - 837 - 837 - 837)
Each pluggable list has an autoDeselect boolean. This has to be set to false or else the deselection action will interfere with the double click action.
The default for the boolean (i.e nil) is the equivalent of true.
To disable this feature means finding the relevant plm and setting its "autoDeselect: false".
I haven't found the code for heirarchy browsers where this is done yet. (I ran into a forest of code on this.) But I have haloed in on a HBmorph until I could inspect the PLM with the classes in it. Once autoDeselect is set to false the rest of the fix makes the double click action work as you wish it to.
Lets get this fix into the stream first and do the other fix ups as they are found. The real problem was the brokenness of PLM>>mouseup .
(0001846 - 539 - 587 - 587 - 587 - 587 - 587)
Found the method Browser>>buildMorphicClassList .
I've added the autoDeselect: false just after the doubleClick code action is defined. This will affect all the browsers that build their class list with this method.
The desire to use doubleClick implies the need to turn off deselect.
So I think we are on solid ground in putting the fix here.
The uploaded Browser-buildClassList-wiz.st file should be loaded with the Inspector3.8DClickFix-wiz.3.cs file for the browsers to work too. I didn't have the time to combine the fixes.
(0001847 - 91 - 91 - 91 - 91 - 91 - 91)
|Browser-buildClassList-wiz.st fixes the problem with opening the hierarchy browser. Thanks!|
(0001849 - 142 - 166 - 166 - 166 - 166 - 166)
edited on: 07-20-05 18:32
The last update IB3-8DClickFix-wiz.5.cs.gz is just everything in one place for the convenience of the committers.
Cheers and joy, -- wiz
(0002760 - 181 - 211 - 211 - 211 - 211 - 211)
edited on: 10-03-05 09:59
A naive question:
What about having every PluggableListMorph having autoDeselect: set to false as default?
Is there an example where it is really useful to have such behavior?
(0002762 - 854 - 890 - 890 - 890 - 890 - 890)
A good question and one that I asked myself as I looked at this. I am a newbie learning squeak by bug fixing so I limited myself to what I needed to know to do the fix. When autodeselect is nil the access method returns true. So everything wanting it to be false must take proactive action.
Why the default is true I don't know and did not want to study enough to find out. I assume the original implementor had a reason and limited my fixes to the places where I could be sure the default confilicted with what was needed. That was the fastest way to fix it.
I think your question deserves a good answer. I've got full plates in several other quarters and this issue here is settled for me now. But I look forward to the original designer or an ambitious newcomer who can come up with an answer and maybe an even more elegant fix.
(0003869 - 570 - 660 - 660 - 660 - 660 - 660)
Time: 12 January 2006, 1:33:41 pm
This version includes stuff from one or more of:
Mantis-0503-TargetSighting, 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)
|06-15-05 03:32||rh||New Issue|
|06-20-05 00:13||wiz||Note Added: 0001653|
|06-20-05 00:17||wiz||Note Edited: 0001653|
|06-20-05 02:21||wiz||File Added: Inspector3.8DClickFix-wiz.2.cs|
|06-20-05 02:29||wiz||Note Edited: 0001653|
|06-20-05 07:46||wiz||Note Edited: 0001653|
|07-04-05 04:58||wiz||File Added: Inspector3.8DClickFix-wiz.3.cs|
|07-04-05 05:03||wiz||Note Edited: 0001653|
|07-04-05 05:05||wiz||Note Edited: 0001653|
|07-12-05 00:29||KenCausey||Note Added: 0001731|
|07-13-05 09:31||al||Note Added: 0001768|
|07-20-05 05:21||wiz||Note Added: 0001844|
|07-20-05 06:55||wiz||File Added: Browser-buildClassList-wiz.st|
|07-20-05 07:07||wiz||Note Added: 0001846|
|07-20-05 09:33||al||Note Added: 0001847|
|07-20-05 18:25||wiz||File Added: IB3-8DClickFix-wiz.5.cs.gz|
|07-20-05 18:27||wiz||Note Added: 0001849|
|07-20-05 18:32||wiz||Note Edited: 0001849|
|10-03-05 09:57||rr||Note Added: 0002760|
|10-03-05 09:59||rr||Note Edited: 0002760|
|10-03-05 22:20||wiz||Note Added: 0002762|
|02-15-06 19:00||MarcusDenker||Status||new => closed|
|02-15-06 19:00||MarcusDenker||Note Added: 0003869|
|02-15-06 19:00||MarcusDenker||Resolution||open => fixed|
|02-15-06 19:00||MarcusDenker||Fixed in Version||=> 3.9|
|06-06-07 02:37||wiz||Relationship added||child of 0006530|
|06-17-08 23:54||wiz||Relationship added||related to 0007096|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
124 total queries executed.|
67 unique queries executed.