Re: [lmi] File extension not added--common "save" dialog in msw11

[Greg Chicares]

On 2/8/23 21:45, Vadim Zeitlin wrote:
> On Wed, 8 Feb 2023 19:38:58 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> Let's first see whether we agree what expectations are reasonable.
> GC> When I save some work in application "A", and then close "A" and
> GC> reload it later, I expect that the file that I just saved...
> GC>  - is offered as a candidate in the "File | Open" dialog; and
> GC>  - appears prominently in the MRU list.
> GC> Aren't those both behaviors that end users would normally expect?
> 
>  Yes, they are. However there is another expectation which conflicts them,
> namely that if I save a file as "name.ext", it is saved with the specified
> extension.
> 
>  Now lmi users probably don't care about the extensions of the files they
> save, although I'm not even completely sure about this, knowing how many
> kinds of files it deals with, but in general it's a legitimate expectation
> and failure to satisfy it is quite annoying, as when you save a file as
> "README.md" in notepad and then can't find a file with this name anywhere
> because it actually ends up being saved as "README.md.txt".

Perhaps there are really two type of applications, and if I were
Nikolai Bezroukov I might name them...

 - "sectarian" applications like lmi, which load and save only files
     designed for its own use, and cannot do anything useful with any
     other kinds of files; and

 - "ecumenical" applications like notepad, which can manipulate any
     kind of file (whether usefully or not).

Or perhaps it's the file formats themselves that are divided between
these two categories. Thus, lmi's input files are all XML, and can be
manipulated in lmi, an XML editor, or any text editor, though any
modification outside lmi may introduce an error that renders them
unloadable in lmi--so lmi and its files are "microcosmic", and lmi
should exert complete control over those files' extensions; while
formats such as plain text, csv, and markdown can be edited with
a wide variety of tools, with which they form a "macrocosm" with
no preference for any application, and therefore file extensions
(if any) are under the user's complete control (and it is thus
rude of notepad to impose a '.txt' extension on the user).

>  After thinking about it for some time, I don't see any serious drawbacks
> to adding some wxFD_ALWAYS_APPEND_EXTENSION flag and I guess it could make
> a number of people if not happy, then less unhappy than they currently are.
> 
>  One problem is that lmi doesn't actually use wxFileDialog directly, but
> only via wxDocument, so it would have no way of specifying it. But knowing
> that docview applications are very much extension-oriented, as per above, I
> think it wouldn't be a big stretch to start using the new wxFileDialog flag
> in wxDocument::SaveAs() unconditionally.

Thanks. Would that flag affect the wxString argument that the wx
doc/view framework passes to DoSaveDocument(), which lmi overrides?

> GC> lmi already overrides wxDocument::DoSaveDocument(). If I can't
> GC> persuade you either to change the default wx behavior or to add
> GC> a wxALWAYS_APPEND_EXTENSION flag, then I can presumably handle
> GC> this in the six lmi overrides.
> 
>  This would work, because currently lmi always use exactly one (and never
> more) extensions for each document type

Correct.

> but it's rather ugly and, again, I
> agree that always appending an extension makes sense for the applications
> based on docview framework.

Okay.

>  Please let me add this flag and also test this under Windows 11 and I'll
> get back to you on this a.s.a.p.

This is not yet urgent for us: as far as we know, only one end
user has windows-11, and the rest have windows-10. But eventually
all will have windows-11. It makes sense for us to upgrade wx in
a "testing" chroot (while continuing to release from our "stable"
chroot). We'll be able to complete acceptance testing on the
"testing" chroot, and promote it to "stable", before windows-11
spreads much further. Meanwhile, we can let our affected end user
know that a change is in development, and suggest workarounds for
the interim.