[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
|