[ANN] new version of services available for preview

Romain Robbes romain.robbes at lu.unisi.ch
Fri Sep 30 20:13:20 UTC 2005


On Sep 30, 2005, at 8:58 PM, tim Rowledge wrote:

> Please don't do this mangling of click behaviour. It can only  
> confuse most users, especially those of us with a long history. It  
> will slow down editing. It won't really speed up finding senders/ 
> implementors since the time to ask for the list is small by  
> comparison to the time for the list to be built and presented.
>
> How would it work with the other uses of d-click? i.e the d-click  
> at the beginning of the line/view/quote-delimited area/etc ? I  
> think you are inappropriately overloading a gesture so common it  
> can only cause problems.
>
> Consider some alternatives -

Well that's pretty much what I've been doing ... so I'm summing up  
each proposition here

> a metakey with the click. shift is already used to extend the  
> selection though and the others are implicitly used for single  
> button systems.

for this, I was thinking of using the halo or morph menu (the morph  
menu is accessible through the halo).
still it removes some functionality

> triple-clicking. I've used systems with t-click and they tend to be  
> a pain; d-click is pretty much a trivial reflex finger action. t-  
> or quad- click requires you to count and slows you down.

this ones seemed to me to be the most reasonable

> hotkey. we already have them and they work quite well.

but they are slower when you have to explore deeply (5-10 senders/ 
implementors)

> menu. slower but the action needs to be there for completeness.

yes it can be in both.

> toolbar button. reasonable - after a d-click one pretty much has to  
> have the mouse in-hand and so a small motion to a reasonably sized  
> button not too far away will take very little time and negligable  
> cognitive effort.

I could try that too ...

> drag-to tool. slightly off the wall but consider being able to drag  
> the selection to a tool that will do the action. such a tool would  
> be a 'senders browser' and anytime you drop a selection on it  it  
> would display the senders. It could be a stacking browser so that  
> all/some/many recent sets of senders would be available. Similar  
> tools would show implementors, references, class refs, variable  
> usages, commentary, spelling and thesaurus info, etc etc. Instead  
> of adding loads of function to a plain browser you just add the  
> drag/drop and then have new specialised browsers.
>

could be interesting, but much more long-term ;-)

> See? There's lots more exciting ways to improve code exploring than  
> ruining my editing experience.

Well I was not satisfied with the controls, now at least we move forward

Romain

> tim
> -- 
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>
>
>
>

--
     Romain Robbes
     http://www.inf.unisi.ch/~robbes/





More information about the Squeak-dev mailing list