Hi Daniel

I agree. This is why keymapping will be an important package in the  
future.
I always found strange that there was only one shortcut table shared  
by all the system objects.
This is also why services are important.

Stef


> This is a funny thing about these subjective things like what the  
> event bindings should be, and alternative looks.
>
> On the one hand, these things are intrusive, and people notice  
> them, so there's lots of feedback and argument. On the other hand,  
> they're fragile, so they don't get very well maintained outside the  
> image. On the third hand, since we are eventually incorporating  
> various changes by different people from different periods, we end  
> up having this weird collage of things that don't really quite fit  
> together.
>
> When, oh when, will we have people working on the infrastructure to  
> make all these themable, easily definable by a single UI oriented  
> person, and so forth with half the enthusiasm that people have for  
> yet another tweak...
>
> I will note that services really is exactly such a thing, but the  
> infrastructure aspects (we could define keymapping from a UI,  
> instead of hardcoding them! you could choose your own, and let no  
> one ever change it!) get completely ignored in favor of the "triple- 
> click vs. three-key sequence" arguments. Now this is just my  
> opinion, but I say Blech.
>
> </rant>
>
> Daniel
>
> 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.
>> 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
>>
>
>