On Mon, 18 Dec 2000 16:01:32 -0800 Duane Maxwell dmaxwell@exobox.com wrote:
Personally, I find the current behavior annoying, but I'm too polite to say so.
(Oh, was that out loud?)
Duane & all,
Loud enough ;-) Here is another candidate for making life a little smoother. Open a new browser (whatever) after filing in to get the full effect. If anyone has strong feeling on this, let's hear about it.
Cheers, Bob
=====code follows===== 'From Squeak2.9alpha of 17 July 2000 [latest update: #3187] on 18 December 2000 at 7:53:30 pm'! "Change Set: lessDelay Date: 18 December 2000 Author: Bob Arning
make pluggable lists a little more responsive:
- do not highlight the mouseDown state unless dragging is enabled. - do not gratuitously enable the double-click handler"!
!PluggableListMorph methodsFor: 'events' stamp: 'RAA 12/18/2000 19:51'! mouseDown: event onItem: aMorph
event yellowButtonPressed ifTrue: [^ self yellowButtonActivity: event shiftPressed]. aMorph ifNotNil: [ self dragEnabled ifTrue: [aMorph highlightForMouseDown] ]! !
!PluggableListMorph methodsFor: 'drag and drop' stamp: 'RAA 12/18/2000 19:51'! installEventHandlerOn: morphList
| handler |
handler _ EventHandler new. handler on: #mouseDown send: #mouseDown:onItem: to: self; on: #mouseUp send: #mouseUp:onItem: to: self. doubleClickSelector ifNotNil: [ handler on: #doubleClick send: #doubleClick:onItem: to: self. ]. self dragEnabled ifTrue: [handler on: #startDrag send: #startDrag:onItem: to: self]. self dropEnabled ifTrue: [handler on: #mouseEnterDragging send: #mouseEnterDragging:onItem: to: self. handler on: #mouseLeaveDragging send: #mouseLeaveDragging:onItem: to: self].
morphList do: [:m | m eventHandler: handler]. ! !
Bob Arning wrote:
Duane & all,
Loud enough ;-) Here is another candidate for making life a little smoother. Open a new browser (whatever) after filing in to get the full effect. If anyone has strong feeling on this, let's hear about it.
This looks like a worthwhile change.
I noticed that the pluggable lists in most browsers (change lists, etc.) are improved with this changeset, but the System Browser is unaffected. I assume this is because double-clicking is enabled in the System Browser? Double-clicking on any of the list morphs in the System Browser doesn't seem to do anything, though. (I may be missing something.)
(Or is it because dragging is enabled in the System Browser? 2.8 allowed both dragging and no-delay selection in the System Browser without a problem, though.)
In general, allowing both single-clicking and double-clicking of an item can be problematic, if the double-click event needs to prevent the single-click event from happening. The only way to prevent the single-click/mouseUp event (when a double-click is intended) is to delay it until it reaches the double-click threshold. (which I assume is why the 280ms delay is in the System Browser?) Most UI's avoid adding this delay by making sure that a single-click event followed by a double-click doesn't cause any problems. E.g., double-clicking an icon on the Macintosh (or Windows) will actually select the icon on the first click, but this is harmless. In Squeak, if you wanted the ability to double-click a method in a browser method list pane to, say, open a new special window, but *without* selecting the method in the list, then you have a conflict and you have to insert the delay.
Anyway, my point is that we should be careful about adding double-click functionality, preferably so that double-click events also cause single-click events which are harmless.
- Doug Way dway@riskmetrics.com
squeak-dev@lists.squeakfoundation.org