Re: [Usability] Efficient navigation in nautilus

What exactly do you mean by "navigate with the open folder". Do you
mean with the mouse or keyboard?

I mean that if you have a folder (/foo/bar) open and need to navigate down on that
path (to /foo/bar/baz/nilli), why on earth you should open the location dialog to
do it? At least that was what I understood you were doing...
It is one thing you should be able to do. It is usefull in a directory with many subdirectories or if you are just faster with the keyboard than the mouse. And of course you could also select a file this way.

I've always thought that moving my hand to the mouse from the
keyboard is something like "mildly annoying", but to say that the cursor
pad (a part of the keyboard, I presume) is too far to be usable...
Words escape me :)
Hehe I was just comparing to bash ... and bash is more effective here.

Of course. But I don't think nautilus needs to mimic bash in its behavior.
Use the real thing if you really want to navigate with typing the path
(which actually sounds like a silly thing to do in graphical environment
now that I think about it.)
Why do you think this is silly? For a novice user ease of use counts, for a pro user speed counts. So as we have it now the pro user can only switch to bash if he wants speed. If he can type in the graphical interface he doesnīt need to switch to bash in most cases. While I absolutely think that gnome should be very user friendly and apealing to novice users we should bever forget the pro users.

btw. I also canīt think of anyone who would need the tab key for switching input elements inside the dialog.
-o/ Me!
Do you really use this? Tab is ok inside a larger dialog when no mouse is at hand but when there is only an input field and cancel and ok button the keys esc and enter do a much better job.

Well, as I have said, it should work the same way in every dialog to be
consitent. You can't have such widespread keys doing different things
in a similar context. You just can't, no matter how much it would help
one particular use-case.

In a dialog it would be problematic but in a panel applet I see not much of a problem. The Tab key is not used there.

btw. I have one other idea for a keyboard shortcut in nautilus. What about using something like Ctrl-t to open the userīs default terminal app with the path set to the current folder.

...And lets adapt all the other "nifty" features from konquer!

I think we should not adapt features that crowd the interface. But keyboard shortcuts donīt crowd it. A novice user will just not know about the feature and it will not tamper with his experience of the system. The only thing is that each shortcut takes away a key. So of course we should not give any silly function a shortcut.

This is surely very
easy to implement and every admin will thank you ;-)
It would also be nice to have a shortcut in gnome-terminal to open
a nautilus folder for the current path.

alias nw='nautilus [some options perhaps] $CWD'
and then a little script to the nautilus-scripts directory to open
a terminal (though this probably isn't doable yet, IIRC).

Very nice. I have checked for the correct alias:
alias nw='nautilus $PWD&'
This one works for me. No further need for a shortcut in the terminal then ;-)

But the shortcut in nautilus to open a shell would still be nice.

We really need to find a way to end this old debate about command line vs graphical interfaces. As an admin I would like to be able to use
both and switch between them very easily.

Keep a terminal open minimized and alt-tab there when in need. That's
what I do (until I have mastered the ability to not use the terminal, still
in training...).

Thatīs also what I do. But the problem with this is that the terminal does not know about your folder context. The normal behavior is that you nvaigate with the mouse to a certain folder. Then there is a task where the cli is needed. Now you have to navigate a second time in the cli to the same location. I donīt think the ability to work without a shell is really needed. There are some cases that will never be possible in a grahpical environment. I would rather like to have an interface that gives me the freedom to use both interfaces.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]