Linked by Thom Holwerda on Tue 25th Sep 2007 18:40 UTC
Gnome Ars has reviewed GNOME 2.20. "GNOME 2.20 was officially released last week after six months of development. The new version includes strong incremental improvements that contribute to a better user experience and provide more flexibility and integration opportunities for third-party software developers."
Thread beginning with comment 274325
To view parent comment, click here.
To read all comments associated with this story, please click here.
RenatoRam
Member since:
2005-11-14

Well, I for one think that having file managing functions inside the file selector is bad and wrong.

I've seen so many times people screw up their files making non undoable changes inside a file selector.

Besides, it's contrary to the principles of the gnome hig: a selection dialog should not be able to influence things outside of its scope.

Having a way to quickly open nautilus on the current directory, I think, would be a good compromise.

Reply Parent Score: 23

mezz Member since:
2005-06-29

I've seen so many times people screw up their files making non undoable changes inside a file selector.

I don't think it is a good reason. It is no difference with the file manager. Any users can screw up in file manager either.

Besides, it's contrary to the principles of the gnome hig: a selection dialog should not be able to influence things outside of its scope.

What is the difference with 'Create Folder'? Isn't it influence outside? or something that I don't understand?

Having a way to quickly open nautilus on the current directory

Not all users (include me) are using Nauitlus or file manager. When he creates a new file and somehow he wants to rename old file and use that old name for new file. It is wasting time to open and jump in file manager.

Reply Parent Score: 11

haldir Member since:
2007-09-24

I know I have borked my system before using a terminal and forgetting where I was in the file hierarchy and deleting a file that I didn't mean to. No matter what the system, some of us can still screw it up.

Reply Parent Score: 4

J.R. Member since:
2007-07-25

It could be an hidden option tho...in GConf or something like that.

Reply Parent Score: 2

segedunum Member since:
2005-07-06

Well, I for one think that having file managing functions inside the file selector is bad and wrong.

Oh please. What on earth do you think you're doing when you open or save a file? This is just silly.

I've seen so many times people screw up their files making non undoable changes inside a file selector.

Like what? This is just sensationalist, 'users are stupid', BS. If you have reusable components in your integrated desktop then you're going to be able to get consistent and familiar file operations wherever you are.

It's certainly not uncommon for someone to try and save a file, open the save dialogue and think "Oh dear, I want to put this in a separate folder" or open an open dialogue and think "Oh dear, I made a typo saving the file, so I'll change it". You shouldn't need to open another application to do what you want. If your main file manager is able to do that then you should get that functionality for free without anyone needing to code it in or complain about it. It should just happen.

Same for thumbnail support. If your file managers do it then your file dialogues should get it for free.

Besides, it's contrary to the principles of the gnome hig: a selection dialog should not be able to influence things outside of its scope.

What says that this sort of functionality is out of the scope of a file dialogue?

Having a way to quickly open nautilus on the current directory, I think, would be a good compromise.

How on Earth would having an extra step and having to deal with another application make things any better?

I'm sorry, but this is just lunacy.

Edited 2007-09-25 22:15

Reply Parent Score: 16

superstoned Member since:
2005-07-07

I don't get it either. Why can't they just embed the view from Nautilus in there... It just makes sense. It would have file previews etc, and as such improve usability.

Or is it that they just CAN'T do that?

Reply Parent Score: 1

Ookaze Member since:
2005-11-14

Oh please. What on earth do you think you're doing when you open or save a file? This is just silly.

When you open or save a file, you're not renaming or deleting a file.
An open or save dialog is not a dialog for doing all kinds of file managing operations, which is what the original poster intended to say I think. Stop playing dumb.
And this is not a "user is stupid" problem, this is a user hazard that can happen to anyone, stupid or not.

Like what? This is just sensationalist, 'users are stupid', BS. If you have reusable components in your integrated desktop then you're going to be able to get consistent and familiar file operations wherever you are.

Exactly, but "being able to" doesn't mean "have to". There's an HIG for that. This is a power against usability problem again.

It's certainly not uncommon for someone to try and save a file, open the save dialogue and think "Oh dear, I want to put this in a separate folder" or open an open dialogue and think "Oh dear, I made a typo saving the file, so I'll change it". You shouldn't need to open another application to do what you want.

And why you shouldn't?
Why shouldn't you run a file managing application to manage your files?
Why should a "file open dialog" or a "file save dialog" transform into a "file renaming dialog" or "file deleting dialog" (with all the user error this will create)? Just because you can?
Now that's silly!
For years, you could do everything with everything in FOSS desktops, and they were deemed unusable and bashed for that.
Now Gnome tries to go away from that, has even a HIG, and you bash it again? Besides, I'm pretty sure you're aware of the reasons behind that design decision, but it's just a case of you not agreeing with it.
But if you want it to change, I agree your best way to change this behaviour is to bash the current one.

If your main file manager is able to do that then you should get that functionality for free without anyone needing to code it in or complain about it. It should just happen.

That's nonsense. Why it should? And that is no justification for it to happen.

Same for thumbnail support. If your file managers do it then your file dialogues should get it for free.

This I agree more with, but that still doesn't mean it's a desirable behaviour. I can see the point in a image manipulation application, I can't see the point when you're dealing with text documents. IIRC, recent GTK+ filechooser API allows you to implement it in your app if you want, but doesn't force it.
Which is much better than your resource hogging solution. If you mean they should implement it in Nautilus and put a checkbox configuration to have this or not in your file dialogs, then I agree it would be a good thing.

What says that this sort of functionality is out of the scope of a file dialogue?

The answer was in the sentence: the HIG.

How on Earth would having an extra step and having to deal with another application make things any better?

Because it's a validation step that you really know what you're doing, as renaming a file in a open or save dialog should be a hidden functionality, right?
These are file operation dialogs, not file managers.

Reply Parent Score: 2

unoengborg Member since:
2005-07-06

I agree with you as long as we are talking about file selection dialogs. But not if you are talking about save dialogs, here it is already possible to create new folders. If you can create them you certainly should be able to rename them, e.g. if you make a typo.

If you can rename folders, why shouldn't you be able to rename files. E.g imagine you are downloading an image from the net, you name it house.jpg, then you find a similar image and want to give both images descriptive names. E.g. house-south-side.jpg and house-west-side.jpg or you may want to create a folder named house, and move the images into it. You shouldn't need to open Nautilus for this.

As for messing things up, opening Nautilus gives the user even more possibilities to mess things up.

Reply Parent Score: 7