Re: shift=and-close-the-current-folder?

[Gregory Merchan <merchan phys lsu edu>]

On Mon, Nov 10, 2003 at 12:26:13PM +0100, Murray Cumming Comneon com wrote:
> > From: Alexander Larsson [mailto:alexl redhat com] 
> > You're missing one thing: shift-click is extend selection in 
> > the list view (and we want to extend this to the icon view 
> > too), so shift-double-click doesn't work well (it can unselect items).
> 
> I didn't realise that it would have that effect. Isn't it OK if the item is
> reselected afer the 2nd click of the shift-double-click? That's actually
> what happens now.

Does double-clicking with multiple files selected open all of those files?
If not, (de)selecting isn't a problem here; the window is going to be closed.
If so, it is a problem because a range of files may be selected and
opened when the user only intends to Shift-DoubleClick open one.

(Modified double clicks only act as separate clicks in the version I have.)


> > Personally I think Ctrl-Alt-up/down + Ctrl-double click would 
> > be a better combo.
> 
> Yes, I'm willing to push that option instead if this one hits a wall. The
> only obstacle to Ctrl-Alt-Up/Down that I know of now is the use of
> Ctrl-Up/Down for accessibility focus moving.

Application-level triple-key combos are quite pointless. They make sense
for environmental operations because there's no global unique menubar.
Most menu operations should be three keys away:
  Alt+MenuAccessKey ItemAccessKey
E.g., Alt+F A for _File -> Save _As....

Alt+arrow combos aren't really appropriate for spatial mode, as they are
either irrelevant or redundant. Alt+Left and Alt+Right are irrelevant.
Alt+Down is redundant with just pressing Enter. Only Alt+Up for opening
the parent folder would be relevant and not redundant. That can be
relegated to the menus. 


> > Ctrl-click means "select without 
> > unselecting rest", so if we make sure the behaviour of this 
> > selection mode is right (like the current icon view) 
> > ctrl-double-click is non-destructive, and we can use that. 
> > 
> > Of course, ctrl-alt-up/down conflicts with metacity again. 
> > However, I think this it is ok to remove this binding in 
> > metacity because:
> > * I consider this form of workspace switching quite 
> > inefficient, and I think heavy users of workspaces already 
> > mapped up Ctrl-Fn or similar to immediately go to the right workspace.
> > * Causual users can use the workspace switcher
> > * Other applications are bound to want the alt-ctrl-arrow 
> > keys also, they are very useful
> > 
> > Of course, this is the defaults. We still allow users to map 
> > <whatever>-arrow to switch workspaces.
> 
> I don't think the majority of people are going to change the defaults.
> Actually, I couldn't even find how to do it in Red Hat 9.

Ctrl+F1 toggles tooltips. Other Ctrl+Fn combos are reserved for application
use or are standard for things I can't recall. Alt+Fn combos are reserved
for window management. Ctrl+Alt+Fn switches VT's on Linux, but we should
be able to steal that back and provide some other way to switch VT's.


> > And maybe we should 
> > change alt-shift to do workspace switching instead of 
> > move-window-to-workspace, since that operation is in the 
> > window menu, so you can already use the keyboard with: 
> > alt-space <number>.

As I recall, that's going away. We should take advantage of the existing
keyboard grab in move-window mode (Alt+F7) to provide keyboard access
to this. E.g.  Alt+F7 (Move window) F1 (to workspace 1).


Cheers,
Greg