Re: [Nautilus-list] Inconsistencies and suggestions

On Sunday, June 10, 2001, at 12:51  PM, Gaute Lindkvist wrote:

1. The dialogs in Nautilus sometimes haven't got any "Ok" or
"Close"-buttons. Instead they apply changes immediately when changed,
and you just have to close the window using the sawfish-close-button.
This is not consistent with the normal Gnome-way of doing things, and I
think (without any proof of course), that people may have difficulties in
knowing what to do. If the dialog is directly in front of what they were
trying to change, they may not even know that it has changed, until they
close the window.

This is something the Nautilus developers did intentionally. The business about having to close the window with the window manager is something that' s simply an oversight. A lot of us were not used to Unix, where the controls in the window's title are not guaranteed to be there. In our designs for other platforms, the close box was the normal way to close windows.

So adding close buttons to dialogs that lack them would be great.

Changing dialogs so they don't have any effect until you say OK is something different. We need to discuss this on a window by window basis. In many cases, it's easier to understand controls that actually have effects. The OK system is fine for modal dialogs, but not so great for other windows.

Anyway, we could spend a lot of energy on this debate, but I'd rather not unless there's going to be a big benefit for Nautilus users. I have a limited amount of time to spend on the project and I want to avoid thrashing about if possible.

2. The bad inconsistency in Windows, were default action for drag n' drop
of files changes if you drag it across partitions, is copied in Nautilus.
I found it horribly annoying in Windows. Have there actually been
GUI-testing that suggested that this is the right way? For me, I would
think that users shouldn't have to worry about wether something is one the
same, or different partitions. Actually IMHO, users shouldn't have to know
that there is such things as partitions.

Perhaps we can change this. Both Windows and Macintosh share the "bad inconsistency" you cite, and there are some reasons for it, but I'm not sure I'm prepared to do the whole debate here on nautilus-list. A few thoughts.

1) Users don't have to know that there is such a thing as a partition if you don't create partitions for them. If you do, then you have to explain what is out of disk space, so you can't completely hide partitions.
2) On my computer there is no such thing as partitions (except for /boot).
3) Moving a file across partitions can result in running out of disk space.
 Moving a file within a partition can't.
4) Do we want the same moving/copying behavior when it's not just a separate partition, but a separate disk, like when moving from a hard disk to a Zip cartridge?

If someone made a complete recommendation of how to change things, I'd be happy to think it over. Having the default drag mean copy when I drag from my hard disk to a network disk or a Zip cartridge is a real convenience for me on my Macintosh, so you'll have to convince me that the requirements for Nautilus are somehow different.

3. The way of renaming files are different in icon-view and list-view.
To clarify: In icon-view you can choose rename from File or contect-menu.
In list view you have to go via file preferences. Isn't this just
confusing and inconsistent?

Yes, it's just a missing feature. It was hard to implement renaming in the list view, so we didn't do it, to save time. We'd prefer to have a list view that shared more implementation with the icon view. If someone wants to make a good renaming-in-place feature for list view, that would be great.

1. Sidebar-panel for devices. This has been suggested before, but IMHO it
is such a killer feature that it should definetly be a priority.

I don't exactly understand what the sidebar panel would have in it, but that's OK. Someone can just implement it to demonstrate. Doesn't need to be built in. A separate sidebar component can be developed, and if we like it, we can put it in by default.

2. A sidebar-panel for the clipboard. Show files that have been cut or
copied (vith different emblem), and the possiblity of using it as
temporary storage with drag and drop.

Sounds OK. Doesn't need to be built in. A separate sidebar component can be developed, and if we like it, we can put it in by default.

    -- Darin

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