PluggableListMorphs

Does anyone out there understand how PluggableListMorphs are supposed  
to work?

In the System Browser, if a Class Category is selected in the first  
pane, and you click it, it de-selects.  In the third pane, if a  
message protocol is selected and you click it, it de-selects.  In the  
fourth pane, if a method is selected and you click it, it deselects.

However, in the second pane, if a class name is selected and you  
click it, nothing happens.

Why is this.  Well  it turns out to be because an instance variable  
called "autoDeselect" is false.  (The default is true).

In Browser>>buildMorphicClassList it says:

        myClassList := PluggableListMorph new
        ...
        myClassList doubleClickSelector: #browseSelectionInPlace.
        "For doubleClick to work best disable autoDeselect"
        myClassList autoDeselect: false .
        ^myClassList

In PluggableListMorph>>mouseUp: evt it says:

mouseUp: event
        "The mouse came up within the list; take appropriate action"
        | row |
        row := self rowAtLocation: event position.
        ...
        row == self selectionIndex
                ifTrue: [(autoDeselect ifNil: [true]) ifTrue:[row == 0 ifFalse:  
[self changeModelSelection: 0] ]]
                ifFalse: [self changeModelSelection: row].
        Cursor normal show

Setting row to 0 leaves nothing selected in the list.  But self  
changeModelSelection: 0 seems not to change the selection at all.  
Strange.

I can't figure this out.  autoDeselect seems like it should be called  
isDeselectionPossible; there is nothing "auto" about manually  
clicking on a selection to deselect it.  But I see no reason why the  
ability to double-click a selection should have anything to do with  
whether deselection is possible. I do know that it used to be: when  
you tried to double-click a selected item (as in the inspector, to  
spawn another inspector) the selection would be cancelled.  I  
regarded this as a bug in the implementation of double-click, which  
(I think) sent a doubleClick event and then a mouseUp event.  Is the  
problem here that rather than fix the doubleClick bug, we have  
introduced a second bug (not being able to unselect the current  
selection in the class-list pane)?

Can anyone shed any light?

        Andrew

PluggableListMorphs

Hi Andrew,

You looked into this pretty deeply.  The current
behavior is a response to mantis reports:

0001347: Doubleclick on list entries not work...
http://bugs.impara.de/view.php?id=1347

0002452: For double clicking on entrys to wor...
http://bugs.impara.de/view.php?id=2452

0002494: Doubleclicking on inspector iv - Imp...
http://bugs.impara.de/view.php?id=2494


>I see no reason why the ability to double-click a
selection
>should have anything to do with whether deselection
is possible.

The general rule (across all platforms and programs
not just squeak) is that before you get a doubleclick
event you will see a click event.  It is the click
event that selects/deselects when "auto" deselect is
true.  So if you double click over an unselected item.
You get
click -> select
dblclick-> open inspector on selection.

But if the item is already in the selected state then
doubleclick fails unless auto deselect is set to
false. (Because the click deselects and doubleclick
cannot find the selection.)

With autodeselect false the deselection does not occur
and doubleclick succeeds.

I fixed up some tortured logic at the selection end of
things (PLM>>mouseup:) so that actions only happen
when the selection state changes.  And then I patched
anyplace in browser creation where I was sure there
was a conflict.  The red flag for this was when a PLM
was given a doubleclick action.  

>Is the  
>problem here that rather than fix the doubleClick
bug, we have  
>introduced a second bug (not being able to unselect
the current  
>selection in the class-list pane)?

Two part ans.  The doubleClick sequence may be buggy.
It is not fixed. Its fixing does not impact this
problem because it is the click behavior (which is
supposed to happen) that will deselect at the wrong
time. This leaves the remainder of the question:

>Have we introduced a second bug
>(not being able to unselect the current  
>selection in the class-list pane)?

In a word, yes. It was a tradeoff at the time and you
are the first one to notice and complain. (Sharp eyes
and good work.)  

It should be possible to write something that allows
deselection in a list. One of the things fixed in
PLM>>mouseup:   is the logic that made it dangerous to
send 0 when 0 was already the selection.  Now that can
be done safely, without causing a second activation.

People had coded a work around that never allowed
clicking outside the list (above or below) to send 0
(they always choose the first or last list item.) If
that is fixed then  mousing down on the list and
mousing up outside of it would be a logical way to
deselect all items by setting the selection to 0.

If you would write this up as a mantis report (with or
with out a fix and tests) that would be a good start
to getting this problem attended to.

Yours in service, -- Jerome Peace




>Andrew P. Black black at cs.pdx.edu
>Sat Dec 9 05:21:35 UTC 2006 wrote:
>
>
>Does anyone out there understand how
PluggableListMorphs are supposed  
>to work?
>
>In the System Browser, if a Class Category is
selected in the first  
>pane, and you click it, it de-selects.  In the third
pane, if a  
>message protocol is selected and you click it, it
de-selects.  In the  
>fourth pane, if a method is selected and you click
it, it deselects.
>
>However, in the second pane, if a class name is
selected and you  
>click it, nothing happens.
>
>Why is this.  Well  it turns out to be because an
instance variable  
>called "autoDeselect" is false.  (The default is
true).
>
>In Browser>>buildMorphicClassList it says:
>
> myClassList := PluggableListMorph new
> ...
> myClassList doubleClickSelector:
#browseSelectionInPlace.
> "For doubleClick to work best disable autoDeselect"
> myClassList autoDeselect: false .
> ^myClassList
>
>In PluggableListMorph>>mouseUp: evt it says:
>
>mouseUp: event
> "The mouse came up within the list; take appropriate
action"
> | row |
> row := self rowAtLocation: event position.
> ...
> row == self selectionIndex
> ifTrue: [(autoDeselect ifNil: [true]) ifTrue:[row
== 0 ifFalse:  
>[self changeModelSelection: 0] ]]
> ifFalse: [self changeModelSelection: row].
> Cursor normal show
>
>Setting row to 0 leaves nothing selected in the list.
 But self  
>changeModelSelection: 0 seems not to change the
selection at all.  
>Strange.
>
>I can't figure this out.  autoDeselect seems like it
should be called  
>isDeselectionPossible; there is nothing "auto" about
manually  
>clicking on a selection to deselect it.  But I see no
reason why the  
>ability to double-click a selection should have
anything to do with  
>whether deselection is possible.




I do know that it used to be: when  
>you tried to double-click a selected item (as in the
inspector, to  
>spawn another inspector) the selection would be
cancelled.  I  
>regarded this as a bug in the implementation of
double-click, which  
>(I think) sent a doubleClick event and then a mouseUp
event.  Is the  
>problem here that rather than fix the doubleClick
bug, we have  
>introduced a second bug (not being able to unselect
the current  
>selection in the class-list pane)?
>
>Can anyone shed any light?
>
> Andrew
>
>


 
____________________________________________________________________________________
Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited