Mantis Bugtracker

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
Reporter rh View Status public  
Assigned To
Priority normal Resolution fixed  
Status closed   Product Version 3.8
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.
Additional Information
Attached Files  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 [^] (732 bytes) 07-20-05 06:55
 IB3-8DClickFix-wiz.5.cs.gz [^] (1,770 bytes) 07-20-05 18:25

- Relationships

SYSTEM WARNING: Creating default object from empty value

related to 0007096new  PluggableListMorph>>mouseUp: sets index to 0 
child of 0006530new  A mother for button, slider and menuItem targeting and argumenting related reports. 

- Notes
(0001653 - 1995 - 2149 - 2149 - 2149 - 2149 - 2149)
06-20-05 00:13
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)
07-12-05 00:29

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" <>
(0001768 - 374 - 374 - 374 - 374 - 374 - 374)
07-13-05 09:31

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)
07-20-05 05:21

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)
07-20-05 07:07

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 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)
07-20-05 09:33 fixes the problem with opening the hierarchy browser. Thanks!
(0001849 - 142 - 166 - 166 - 166 - 166 - 166)
07-20-05 18:27
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)
10-03-05 09:57
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)
10-03-05 22:20

Hi rr,

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)
02-15-06 19:00

In 3.9:

Name: MorphicExtras-jmv.9
Author: jmv
Time: 12 January 2006, 1:33:41 pm
UUID: 2720167c-765e-9541-8f14-dd3789d8fca8
Ancestors: MorphicExtras-CdG.7

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)

- Issue History
Date Modified Username Field Change
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:
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.
Powered by Mantis Bugtracker