After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 150249 - Standard "Save As" dialog?
Standard "Save As" dialog?
Status: RESOLVED OBSOLETE
Product: gnome-devel-docs
Classification: Applications
Component: hig
unspecified
Other All
: Normal normal
: ---
Assigned To: HIG Maintainers
HIG Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-08-16 10:59 UTC by Calum Benson
Modified: 2020-12-04 18:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Calum Benson 2004-08-16 10:59:47 UTC
There's a need for a standard appearance/behaviour for Save As dialogs, as
reported here by Robert Staudinger:
http://mail.gnome.org/archives/usability/2004-August/msg00077.html

FWIW, my (very gut) feelings are that:

- Any extension the user types should over-ride the default file type selection,
and update the file type list accordingly.  The app would potentially need to
have a preferred format for each extension in this case, e.g. various flavours
of Word document all map on to ".doc".  (If the user pre-selected one
non-preferred .doc format though, e.g. Word 97, then typed .doc in the filename
field, the list/format *shouldn't* update to the preferred .doc format.)

- Haven't quite made up my mind what should happen if the user makes a manual
file type selection, and then types a different filename extension :/   My first
instinct would be to keep to the 'what you type over-rides what you select'
rule, but maybe since this is a corner case, an alert listing the possible
options (save using selected file type, save using filetype suggested by
extension, and a choice of whether to use either or both extensions in the
actual filename) would be acceptable here.

- There should be an option to add the correct extension automatically, which
would be added to (not replace) any extension the user typed.  (I can see
arguments for replacing it too, but they go somewhat against the usability
principle of least surprise).

- The user should be able to save a file as a particular type without an
extension if they so desire.  It would be very annoying to have to save a README
file as "README.txt", then rename it :)

So to satisfy all that, the relevant part of the file selector might look
something like:

Filename:  [MyReport             ]

File Type: [ MS Word 97        |v]  <-- includes a "Determine from
                                        Filename" item
[x] Add correct filename extension  <-- disabled if File Type =
                                        Determine from Filename)

As hinted at earlier, to have this work most transparently you'd probably need
the extension list to update dynamically based on the extension typed, and also
on whether you'd pre-selected a filetype or "Determine from Filename", to leave
the user in no doubt as to what format their file will actually be saved in. 
That could be a tricky little interaction to get just right; I haven't really
worked through all the scenarios.

Of course, ideally this would all be part of the file selector widget anyway, as
it's a common enough scenario that applications shouldn't all have to be
implementing the same (or worse, slightly different) behaviours :)
Comment 1 Calum Benson 2004-08-16 11:04:38 UTC
Of course, the new file selector doesn't have the filename at the bottom, so I
guess it would really look something more like:

Name:           [My Report     ]
Save in folder: [Documents   |v]

File Type:      [MS Word 97  |v]
[x] Add correct filename extension

> Browse for other folders

                  [Cancel][Save]
Comment 2 Rob Staudinger 2004-08-16 11:49:54 UTC
Maybe saving without extension should be restricted to "generic" formats like
plain text, i.e. which are understood by a wide range of applications. Can't
think of any other than plain text ATM though.

Maybe the need to distinguish between known file-types and random "." in the
filename will arise. Example: "test.rtf" vs. "test.draft" / "test.draft.rtf"
If the extension is "random" (not known by the app) we might want to default to
the selected extension and append it.
Comment 3 Seth Nickell 2004-08-16 20:35:19 UTC
http://www.gnome.org/~seth/designs/filechooser-spec/

This is "One of the things that never got finished"...
Comment 4 Bryan W Clark 2004-08-31 16:43:30 UTC
I would probably go against the 'what you type over-rides what you select'.  I
think we'll run into situations of people typing in "java and .net" for the file
name and perhaps ".net" is a recognized extension. We would end up saving as
".net" even though the person selected "Word 97" format before or after typing
in the file name.  It seems that if you manually select a format we should be
appending the appropriate extension no matter what you type so we don't run into
miscalculations based off the file name.

If a person hasn't selected a format I would like to see the file type change
dynamically if you type in ".doc" as your file extension and the default format
was "Rich Text", it would change the format to "Word 97" (whatever the most
appropriate one is).  This would give at leaset some feedback to the person that
we've just seen the extension they've typed and we're going to use it.
Comment 5 André Klapper 2018-09-12 18:23:40 UTC
This does not seem to be an issue anymore in 2018.