Hi Emilio,

     I don't quite understand what you mean ... the behavior I have  
for now
     is to both select the word and attempt to navigate, which  
deselects the word sometimes.

     Just by reading your mail, I was thinking of doing navigation by  
triple-clicking
     (was that what you meant btw?), which could maybe be doable. Would
     everyone (Tim?) find that ok. I don't think Squeak can do triple- 
click to select
     a line or paragraph (and can't check because my double-click is  
modified ;-) ).

     Cheers,
             Romain

On Sep 30, 2005, at 2:52 PM, Emilio Oca wrote:

> Hi Romain,
>
> I'd like to keep the behaviour of double-click to select a word.
> But the behaviour you propose is handy. Is it difficult to make it  
> work over
> a selected text?
> In that case we could keep both behaviours.
> Cheers.
>
>     Emilio
>
>
>> -----Mensaje original-----
>> De: squeak-dev-bounces at lists.squeakfoundation.org
>> [mailto:squeak-dev-bounces at lists.squeakfoundation.org]En nombre de
>> Romain Robbes
>> Enviado el: Viernes, 30 de Septiembre de 2005 06:48
>> Para: The general-purpose Squeak developers list
>> Asunto: Re: [ANN] new version of services available for preview
>>
>>
>>
>> On Sep 30, 2005, at 1:57 AM, tim Rowledge wrote:
>>
>>
>>>
>>> On 29-Sep-05, at 4:22 PM, Romain Robbes wrote:
>>>
>>>
>>>
>>>> On Sep 29, 2005, at 10:02 PM, tim Rowledge wrote:
>>>>
>>>>
>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> The obvious question here is how this affects the traditional
>>>>> usage of double-click on a word to select that word for cut/cop/
>>>>> paste/etc. Is there some extra gesture you missed out?
>>>>>
>>>>>
>>>>>
>>>>
>>>> Well ... that's kind of a problem now ;-)
>>>>
>>>>
>>>
>>> Ah. This ought to be sorted out pretty quickly then.
>>> Introducing modes is a good way to become the subtract of a number
>>> of voodoo practices so I'd avoid it if I were you. What is the
>>> problem with simply leaving the selection behaviour alone and using
>>> the same ctl-m/n hotkeys that we already have as ways of getting
>>> the implementors and senders? There isn't much point in making a
>>> simpler UI for getting to them at the cost of completely ruining
>>> the normal editing actions.
>>>
>>
>> For me, navigating in the code is more "normal" than copy/pasting, ie
>> I use it way more often. Then I recognize than I can get
>> bitten by it from time to time. But I think using the mouse for this
>> really help in quickening the navigation. I'd really like to have
>> something like alt-clicking for this, but most of these keys are
>> taken already. Since I never use the halo (even if I trigger it
>> all the time ...), I was also thinking of including a 'mode' there
>> (as some people still need it).  I'd really like to remove the mode,
>> but finding a good keystroke+clicking combination is tough. The same
>> thing applies to keyboard shortcuts by the way.
>>
>>
>>> If you're original impetus for the change was to get to senders/
>>> implementors faster it would probably be more widely useful if you
>>> could make the building and opening of the dratted message set
>>> browsers faster.
>>>
>>>
>>
>> Well the idea is to have the smalltalk browser behaving like a web
>> browser: click on something and go there in the same window
>> (senders, implementors, references to class and instance variables).
>> then you can go back and forward in your history, all of this without
>> opening a new window (and not being bugged when
>> you have some code you were editing still not accepted).
>>
>> Romain
>>
>>
>>> tim
>>> --
>>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>>>
>>>
>>>
>>>
>>>
>>
>> --
>>      Romain Robbes
>>      http://www.inf.unisi.ch/~robbes/
>>
>>
>>
>>
>>
>
>

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