Re: [PATCH] Change list-view rename-behaviour

[Darryl Rees <rees netnam vn>]

While I can see both points of view on this, just add 2c worth:

1) right-click menu option selection is extremely fatiguing to do 
several times in a row (find yourself falling back to shell to do lots 
of renaming? of course you do...), especially if you then need to click 
2 or 3 times with left mousebutton to overwrite the filename.

2) windows, afai remember has both options. (hope i got that right). 
seems like basically nobody uses the right-click option. there must be a 
reason for this (discoverability? the aforementioned fatique factor?).

Personally I really like the double-click rename, wish it were available 
under both views, even though i can see the 'theoretical' pitfalls.

Maybe there is some other way? Keyboard shortcut? (would be less 
fatiguing, but harder to discover...) Other? (Crack idea, imagine 
selecting a whole directory, clicking 'rename' and being able to tab or 
arrow up/down between files to be renamed...).

On a related note, is it just me or is it suboptimal to have the cursor 
pointing to the start of the filename after a rename. Seems like adding 
a prefix to a name is about the least likely thing I'd want to do in a 
rename operation.

Cheers,
Darryl Rees.

> Dave Bordoley wrote:
> > On Sun, 2003-01-12 at 12:24, Roberto Rosselli Del Turco wrote:
> >
> >>I would have patched it the other way round: what's more intuitive than
> >>clicking and changing an icon's name? If you click on the *icon* you
> >>won't be annoyed by the rename option.
> >>
> >>Ciao
> >>
> >
> >
> > Well direct manipulation is good, however I believe that real world
> > experience generally has proven that click to rename causes more
> > problems than it is worth. Particularly in the list view, the file name
> > is the most obvious target for users to click on in order to launch the
> > file (mostly due to the fact that it is the defining attribute of the
> > file). In the icon view click to rename has the disadvantage that we
> > create different specialized behavior depending on where you click an
> > object, basically reducing the target size a user has for
> > opening/launching a file. This leads users to erroneously enter rename
> > mode, which is potentially dangerous and can cause data loss in the
> > worst case. Renaming isn't all that common of an operation so requiring
> > a user to use keyboard shortcut or context menu entry seems reasonable
> > to me at least.