OSNews

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.