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@rowledge.org; http://www.rowledge.org/tim
-- Romain Robbes http://www.inf.unisi.ch/~robbes/