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 274410
To view parent comment, click here.
To read all comments associated with this story, please click here.
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

kelvin Member since:
2005-07-06

Why can't they just embed the view from Nautilus in there...


It's a matter of not having GTK+ depend on Nautilus. The GTK+ filechooser needs to function regardless of whether Nautilus is installed or not.

Reply Parent Score: 4

Hiev Member since:
2005-09-27

well, lucky for us your book is not the last word.

Even Trolltech is providing Qt bindings for Mono, that would mean KDE apps. based on Mono, you like it or not.

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

dagw Member since:
2005-07-06

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

The answer was in the sentence: the HIG.


That's a bad excuse for not doing something. Just having a HIG doesn't magically make your apps of DE more user friendly. Bindly following a bad HIG is a lot worse than having no HIG at all. A HIG should be a set of guidelines not a set of commandments. You should refuse to implement a feature because you can show it's a bad idea, not just because it goes against some arbitrary set of rules set down by some arbitrary groupd of people.

Even the much worshiped Apple knows when to ignore their own HIG.

Reply Parent Score: 8