(In reply to comment #0)
On Mac the ".txt" extension is added if not included in the Save As name box.

> Not really an issue on Ubuntu as only the file name and not the extension is
> selected in the export window 
Nonetheless (unlike with audio file export) if you provide no extension, it is not added.

Created attachment 458 [details]
Add .txt extension if not provided by user

Patch excludes Mac OS X as #c1.

Tested on Windows, using names with and without extension and with period in name. Seems fine.

Patch is not ready, so I changed the keyword back to 'patch'. It's two local hacks to fix a bug that's apparently in FileSelector(). 

Even though it's getting the right args (see the many other calls to FileSelector()), there's some underlying issue that's causing FileSelector() to not use its defaultExtension and 'filter' params. 

Given that, I think this is likely happening in more cases than these 2 dialogs. So with this approach, we'd need the same local hack in more places.  The correct approach is to drill down into FileSelector() and figure out the underlying problem.

(In reply to Vaughan Johnson from comment #5)
> Patch is not ready, so I changed the keyword back to 'patch'. It's two local
> hacks to fix a bug that's apparently in FileSelector(). 
> 
> Even though it's getting the right args (see the many other calls to
> FileSelector()), there's some underlying issue that's causing FileSelector()
> to not use its defaultExtension and 'filter' params. 
> 
> Given that, I think this is likely happening in more cases than these 2
> dialogs. So with this approach, we'd need the same local hack in more
> places.  The correct approach is to drill down into FileSelector() and
> figure out the underlying problem.

http://audacity.cvs.sourceforge.net/viewvc/audacity/lib-src/FileDialog/win/FileDialogPrivate.cpp?revision=1.2&view=markup

Well, I've gone back an re-read all of the emails for that time period and I can't figure out why I disabled the code that appends the file extension.  And, I only disabled it for Windows...Linux and OSX still appended it.

So, I'm going to re-enable as appending the extension is expected behavior.  If we identify the reason for removing it, then we'll make changes for that specific exception.

Committed in g4d0de66.

The original filedialog code didn't actually append extensions on Linux or OSX.  But, to be consistent, I've now added it.

I wonder though if that is actually correct for OSX and Linux?  Even so, our code will be easier if we can expect consistent behavior among the 3 plats.

The .txt extension is still added to the filename in OS X 10.9.5 when the extension is not explicitly added in the Save As dialog.

(In reply to Leland Lucius from comment #8)
> I wonder though if that is actually correct for OSX and Linux?

I think that it is still peculiar that in the export dialog we specify:
"Files (*.txt)"
but then we allow the use to add a different extension (for example, you can export as "spectrum.wav")

On Linux, most applications seem to either:

a) Not offer a file extension and allow the user to use any legal file name (typical in text editors)

b) Offer a file extension based on the selected file type and add that extension if missing and/or complain if the standard extension is not used.

c) Select the file type based on the file extension provided by the user, and fall back on the default format + default file extension if no valid file extension is provided.

I think that on  Linux we should either:

1) Have the File type selector (as now) and 'force' the stated file extension (*.txt) [like (b) above]

or

2) Remove the File type selector and allow the user to use any valid file name (with any extension). [like (a) above]

Option (c) is not applicable because these effects only support plain text format.

Of the two remaining options, the second (1/b) would be more appropriate for consistency with Windows.

(In reply to Bill Wharrie from comment #9)
> The .txt extension is still added to the filename in OS X 10.9.5 when the
> extension is not explicitly added in the Save As dialog.

I may not be understanding what you mean exactly.  To me, it "seems" to be working the same way TextEdit works.  When the dialog opens, the "contrast.txt" name is in the "Save As" control, with the "contrast" part selected.

If I explicitly remove the ".txt" extension part in the "Save As" control, the dialog still adds it.

The one difference I do see is that if I type "contrast.try" in the "Save As" control, Audacity will produce "contrast.try.txt" as the filename without warning, whereas TextEdit throws up message asking if both extensions should be used or if the "required" extention should be used.

(In reply to Steve Daulton from comment #10)
> (In reply to Leland Lucius from comment #8)
> > I wonder though if that is actually correct for OSX and Linux?
> 
> I think that it is still peculiar that in the export dialog we specify:
> "Files (*.txt)"
> but then we allow the use to add a different extension (for example, you can
> export as "spectrum.wav")
> 
> On Linux, most applications seem to either:
> 
> a) Not offer a file extension and allow the user to use any legal file name
> (typical in text editors)
> 
> b) Offer a file extension based on the selected file type and add that
> extension if missing and/or complain if the standard extension is not used.
> 
We do sort of do this.  We do offer a ".txt" extension and if the user removes if from the filename, we automatically append the extension.

What we don't do is warn the user if they specify a different extension that the expected one.  We do that for "Export", but not for the rest of them.  Would be some easy to add if desired.

(In reply to Leland Lucius from comment #11)
> The one difference I do see is that if I type "contrast.try" in the "Save As"
> control, Audacity will produce "contrast.try.txt" as the filename without
> warning

I would be happy with that, but that is not what's happening here.

If I type "contrast.try" in the "Save As" control, it saves as "contrast.try".

The problem with what I'm seeing, is that if I then go to export again, because the file browser is filtering for .txt files, my "contrast.try" file is invisible (only .txt files are shown).

Thanks for your input, all. 

REOPENED for two reasons. 

* The extension is not appended on XP SP3 if none is provided. If there is a reason that should be a WONTFIX for XP, please say.

* Although a final .txt extension is appended on Mac if user provides an extension, this is not happening on Linux or Windows (7 or XP). 

Leland wrote:
> If I type "contrast.try" in the "Save As" control, Audacity will produce 
> "contrast.try.txt" as the filename without warning
That would be OK with me too if it was happening for Windows and Linux, and OK without warning if the filter name includes "(*.txt)". 

If we wanted to be more flexible could we add an "All Files (*)" filter that accepted whatever it was given without appending extension?

Okay...let's get clarification on the different possibilities.

We can provide an "All (*.*)" filter (and we should), but if it is selected we would just take what the user gave and not append an extension or complain about what was entered.  It's a verbatim choice.  The user is in control and doesn't need hand holding.

So, assume that a "Text Files (*.txt)" filter is selected at this point.

1)  User types "myfile", without extension...what should happen?

2)  User types "myfile.new"...what should happen?

3)  User types "myfile.txt"...what should happen? ;-)

I will defeat the default platform processing and make it consistent cross-platform following Audacity rules.

Testing on W10 with audacity-2.3.3-alpha-256-ac65d817acdc76466af9f49b1681e1abf2c39fc0

Exporting from either Plot Spectrum or Contrast where the filename specified has no extension - on export the ,txt filename is now properly added, as expected.

Should be teste on Linux too before closing this off.

(In reply to Peter Sampson from comment #16)
> Exporting from either Plot Spectrum or Contrast where the filename
> specified has no extension - on export the ,txt filename is now properly
> added, as expected.

This does not happen on Linux.

On Linux, I don't think it needs to happen, but I am concerned about why it doesn't happen. 

If the above behaviour is intended, then it would seem that there is still a bug. On the other hand, it could be due to platform differences in WxWidgets that do not implement the above behaviour for Linux.

On Linux, the current behaviour would be acceptable as long as the file type filter also included an "*" ("all" file types) option, but currently it doesn't.

Testin on macOS 10/14.5 with 2.3.2

If a file is specified for the text output with a filename with no extension then the file is indeed exported with no extension.

It could be argued (and I think I would) that that is just what the user intended.


It's actually harder to achieve this on Mac as when the filename is offerd the default is higlighted ready for change - nut the defailt supplied .txt extension has then to be removed separately = so much less likely to happen.

(In reply to Peter Sampson from comment #18)
Abd looking at the properties of those extensionless files - Mac still knows that they are "TextEdit.app Document".

Tested again on W10 with audacity-2.3.3-alpha-256-ac65d817acdc76466af9f49b1681e1abf2c39fc0

and I again confirm that the .txt extension is added if not suppled in the filename to be exported.

So, given the title of this bug, this works as expressed in the title for W10 - but does not for Mac and KLinux - so I shall change the title accordingly.


But I am far from convinced that the behavior (for Mac at least - I can't test on Linux) is perfectly correct and desired - albeit different from the correct and desired behavior on Windows.

Accordingly I shall mark this as OK on Mac and Win from my POV

Fixed in c5a1dad275a9805505846b310248c9447f2cb6e5

Mac and Linux (correctly) allow files to be saved with an arbitrary
file extension, or no file extension at all. For the exported file
to be visible in the export dialog, the dialog now includes an optional
wildcard for "All files".

(In reply to Steve Daulton from comment #21)
Testing on macOS 10.14.4 with 2.3.3 alpha jc002 30Jun19

This tests OK on Mac