On Sep 30, 2005, at 10:27 PM, Hernan Tylim wrote:

> Hi,
>
> I am with Tim here. Clicking and double-clicking inside a text  
> field is a today de-facto standard for positioning and selecting text.
>
> This might not be a good standard (to me it is) but is a standard  
> nonetheless. So changing it will only frustrate every user who  
> don't know, or remember, that squeak has such distinct behaviour.
>
> I also don't think that making things clickable while they don't  
> give visual feedback of clickability will help avoid user confusion.
>
> What do you think about using CTRL+ALT. I read that you couldn´t  
> use ctrl and alt separately, but what about both keys?.  If  
> possible I would also underline all clickable words while CTRL+ALT  
> are being pressed. This would give the visual feedback I just  
> mentioned and will advertise to a user that something can be done  
> with that words.
>

     Well I have quite a few possibilities there ... I'll try some of  
these and see what is the best.
     I think the problem in this respect (using alt or ctrl) is that  
these events are swallowed by squeak
     so I'll need to do some treatments at a lower level probably.

     But I'll look into this.

         Romain

> Just my opinion.
>
> Regards,
> Hernán
>
> 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 -
>> a metakey with the click. shift is already used to extend the   
>> selection though and the others are implicitly used for single  
>> button  systems.
>> 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.
>> hotkey. we already have them and they work quite well.
>> menu. slower but the action needs to be there for completeness.
>> 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.
>> 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.
>> See? There's lots more exciting ways to improve code exploring  
>> than  ruining my editing experience.
>> tim
>>
>
>
>
>
>
>
> ___________________________________________________________ 1GB  
> gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del  
> mundo http://correo.yahoo.com.ar
>
>

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