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

[Vadim Zeitlin]

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".

GC> "lmi cannot load a file that lmi saved" is the problem from the
GC> end user's POV. The successfully-saved census file might even seem
GC> not to exist, from that lay POV, because attempting to open a
GC> "census" in the "Open File" dialog displays only files with a
GC> '.cns' extension. "File|Open" should open what "File|Save" saved,
GC> regardless of technical details (like embedded '.' characters)
GC> that the lay people see as irrelevant. And there's no way, AFAICT,
GC> for end users to load this saved file by working only within lmi;
GC> they must rename it first, using some other tool (with which they
GC> might be unfamiliar).

 In a normal program my advice is to always use a wildcard selector as one
of the possibilities in the file types combobox precisely in order to allow
the users to open any file, even those using an extension the program
doesn't expect. In wx docview architecture this is more difficult because
it uses the extension to determine a file type. IMHO it's a flaw in it, but
it's not something we're going to be able to change easily, unfortunately.

GC> Different preferences on binary issues can be accommodated by
GC> adding a flag. Adding flags willy-nilly can be a problem in
GC> itself, but in this case isn't a flag justified, as there
GC> seems to be a solid case on both sides of the discussion?

 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.

GC> >  However, there are still some questions and possible improvements:
GC> > 
GC> > GC> This seems to occur only with windows-11, not with windows-10, and 
not with
GC> > GC> 'wine'. File names that are "simpler" (e.g., "example.cns") do not 
seem to
GC> > GC> trigger the anomaly.
GC> > 
GC> >  First of all, I'm not sure at all why does this happen only under 11 and
GC> > not 10, the code I'm speaking about is in wxWidgets itself.
GC> 
GC> Yet it can be reproduced with GTK [above].

 Yes, this is expected precisely because the code appending (or not) the
extension is in wxWidgets itself. I.e. I'd expect it to work in the same
way under all platforms and I (still) don't understand why does it work
differently under Windows 10 and 11. I really need a Windows 11 VM to find
this out.

GC> >  Second, it's clearly stupid to think that "25M - PRELIMINARY" can be an
GC> > extension and we don't need to integrate an advanced AI in wxWidgets to
GC> > avoid it, we could just add for a space after the period, as spaces can
GC> > never be part of an extension. We could be a bit more aggressive and also
GC> > consider that anything longer than a few (5?) characters is not an
GC> > extension neither, although this might result in some false positives if
GC> > anybody uses e.g. ".census" as an extension. But we probably could live
GC> > with this.
GC> 
GC> lmi uses these two eight-character extensions:
GC>   /opt/lmi/data/sample.database
GC>   /opt/lmi/data/sample.rounding
GC> And it's not ideal to rely on any heuristics, because they can
GC> so easily go wrong. For example, census files depicting a couple
GC> of different scenarios might well be named thus:
GC>   Some Bank, $2M
GC>   Some Bank, $2.5M
GC> where ".5M" contains very few characters and no blanks, yet is
GC> not to be treated as a file extension.

 Yes, this heuristics is never going to cover 100% of the cases. But we
could still use it even if wxFD_ALWAYS_APPEND_EXTENSION is not specified to
avoid surprising people unnecessarily.

GC> >  I'll make these changes before the next wx update, and hopefully this
GC> > should help a lot in practice -- even if it's not going to solve the
GC> > problem completely. Please let me know if you disagree.
GC> 
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, but it's rather ugly and, again, I
agree that always appending an extension makes sense for the applications
based on docview framework.

 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.

 Regards,
VZ

pgpVv9X3PIjff.pgp
Description: PGP signature