Re: [Usability] File Open/Save dialog



Op zondag 03-01-2010 om 11:51 uur [tijdzone +0100], schreef SZABÓ
Gergely:

> A few thoughts on the file Open/Save dialogs. I've just had a quick look 
> in Bugzilla, there are about 200 related bugs, each dealing with some 
> minor aspect. I'd rather propose a more general solution.

I will try to give some short replies based on my knowledge of the
situation.

> 1. Layout
> 1.1. File name edit-box should be together with optional file-type or 
> encoding drop-downs.

Why? It might be obvious to you but if you think the current placement
is bad, you'll have to explain how you come to that conclusion.
 
> 1.2. "Places" should be deleted or optional, see below
> 1.3. Folder Button-bar should be deleted or optional, see below
> 1.4. Separate "Save in folder" and ""Browse for other folders" are an 
> unnecessary complication, just display the folder-browser

The designers of the dialog felt that the folder-browser was an
unnecessary complication, at least unnecessary to display by default.
Why do you think every user should be forced to think about folder
hierarchies when he just wants to save a file?

> 2. Folder Browser Behaviour
> 2.1. Hotkey Backspace for up-dir does not work as in Nautilus

Works for me (Gnome 2.28).

> 2.2. Even item up-dir ".." is missing

It's not missing. ".." is meaningless for anybody except people with
good knowledge of the command line and filesystems. The breadcrumb bar
is there to navigate a level up.

> 2.3. Items are not right-clickable as in Nautilus

That is because the filechooser is not a file manager.

> 3. Keyboard navigation
> 3.1. Tab-completion in file-name edit box is nice, but first I thought 
> it's broken keyboard navigation
> 3.2. Escape from file-name edit box by Ctrl-Tab is not intuitive, as Tab 
> works everywhere else

You have a point, but believe me when I say that hell would break loose
on the internets if the GTK+ developers were to change this.

> 3.3. Folder Browser unusable due to lack of up-dir hotkey, see above
> 3.4. "Places", folder button-bar etc are simply a huge bug as regards 
> keyboard navigation, see above

Then let's fix the navigation and not remove a useful feature.

> 4. (Dis)similarity to Nautilus
> To summarise things, the dialog's main problem is its dissimilarity to 
> Nautilus. It looks similar, but it behaves completely differently, which 
> users do not expect.

It looks similar to Nautilus' list view, but that's not even the default
view in Nautilus (that's icon view). So I don't think this point is
really valid.

>  I actually think Nautilus and these dialogs should 
> be the very same project. 

Technically impossible. The filechooser is a GTK+ widget which cannot
depend on the pile of Gnome libraries Nautilus depends on.

> 4.1.1. Take over layout config from Nautilus (presence of Places, 
> button-bar etc)

Actually I don't see many differences in the layout between the Nautilus
Places sidebar and the one in the filechooser.

> 4-1.2. Use the icons/list/column layout as configured in Nautilus for 
> the Folder browser

Note that this is per-folder setting. 

> 4.2. Take over Folder Browser's behaviour from Nautilus

Please specify what exact behaviour you refer to.

> 4.2.1. Backspace for up-dir
> 4.2.2. All items right-clickable with usual context-menu (e.g. remove 
> write-protection etc)

Read-only permissions are located in the Properties notebook of a
file/folder, not in its context menu. 
What's more, replicating a file manager within the filechooser would be
a waste of effort. If you want to manage files, use Nautilus. If you
just need to open or save a file, the filechooser does its job just
fine.

To conclude: certainly improvements to the GTK+ filechooser are
possible, but not all of the points you mention are actual bugs. Reading
up on the history of the filechooser may explain you better why things
are as they are.

regards,

-- 
Reinout van Schouwen




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