Re: Re: What I think spatial nautilus needs



>> That is why Emacs and Vi have their keyboard-shortcut
>> tools, and so on...

>And all the time I thought it's because they're console apps ...
No, then they could have used the normal arrows, which they do not,
because it's inefficient to move between arrows and letters on the
keyboard. Not to mention mouse. I'm not proposing such an extreme
solution, but rather that it should be possible to do everything using
either a) mouse or b) keyboard and not both.



>> 1) Mouse gestures. 
>> After having opened ca 10-15 folders, and not wanting to have to
>>switch
>> to the keyboard to use CTRL-SHIFT-W I have to close each window by
>> clicking the X in the top right corner... not that smooth... A mouse
>> gesture to close the current folder, and one to close ALL folders
>>would
>> be nice.
>> Same thing with moving to some different location. There should be a
>>way
>> to activate the CTRL-L feature (more about that in point 2) with the
>> mouse.
>> Of course, stuff like opening the parent folder and such should also
>>be
>> accessible with the mouse. 
>> Now - for the not-so-power users, the most common mouse gestures
>>could
>> appear as a small panel of some sort somewhere (other suggestions
>> welcome)

>It's all in the menu (accessible per mouse).

>Closing a window is easy enough with the mouse. Closing parent windows 
>is more of an advanced option, so I don't think it should be exposed 
>in front row.

That's just not efficient. Personally, I find it hard to click the close
button in the corner, it's ok if it's one or two windows, but not if
there are like 10.
Closing parent windows may be an advanced option, but closing ALL
windows is not. 
Also, IIRC, spatial nautilus was designed to be efficient for both power
and regular users.

>>Mouse gestures are not discoverable and not exactly simple to do
>>right.

And keyboard shortcuts are? And maybe gestures isn't the way to go...
maybe it should be something like pressing down all three buttons to
close the window. something like that.

>Spatial Nautilus windows must be kept simple and clean, because their 
>content is the important thing, and they shouldn't take too much space 
>since the user will have mayn of them open at once at times. Therefor 
>are toolbar would be problematic. Icons could be placed in the menu 
>row, but I guess that would be rather confusing and might look crowded.
>Learning the shortcuts is better anyway, and they can all be done with 
>one hand (while the other stays on the mouse).

There has to be a middle way... that is what I'm looking for.
 
>> 2) Make CTRL-L use the file selector
>> This would be good for all users as such a feature would allow easier
>> browsing to far away locations, not require knowing exact location
>>fof
>> different folders, not require using the keyboard and allow for the
>>use
>> of the GTK bookmarks (see point 3)


>The file selector is so big and complicated compared to the Open
>Location 
>dialog. And personaly, I have to say it feels terrible slow, while 
>Open Location is simple, fast and beautyful.
>If you want to access 'far away locations' and don't know about exact 
>locations, just use Nautilus itself!

That is my problem. There is no real way for me to get to /var/www/html/
from /home/sigge/ I don't want to use ALT-UP three times, and I don't
want to minimize all windows to view my desktop. I want an easy way to
"teleport" between locations. 

>For reusing bookmarks from file selector they should be rather found 
>in a folder that might be on the destop or find a place in the panel.

Why not both? 

>> 3) Bookmarks, bookmarks, bookmarks

>Bookmarks have no place in the spatial Nautilus menu, because there's 
>no relation to the represented folder. (Having Places there is a
>mistake, 
>IMHO).
>Having shortcuts and the ability to put arbitrary folders into the
>panel 
>would make for nice bookmark functionality.

Nothing in the menu bar has any relation to the folder. Still there is a
need to put stuff there.  I understand your opinion, and respectfully
disagree.

//Sigge Kotliar




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