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

[Greg Chicares]

On 2/8/23 14:34, Vadim Zeitlin wrote:
> On Wed, 8 Feb 2023 03:25:47 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> To reproduce, load lmi, then:
> GC>   File | New | Census
> GC>   File | Save
> GC>     replace "unnamed1" with:
> GC>       '1st Sample Bank - Tier 1 - FUW - $1.25M - PRELIMINARY'
> GC>     omitting the single quotes
> GC>   OK
> GC> 
> GC> Result expected: '1st Sample Bank - Tier 1 - FUW - $1.25M - 
> PRELIMINARY.cns'
> GC> file created. Instead, the file that gets created has no '.cns' extension.
> 
>  I haven't checked this yet, but I'm almost sure that it's due to the
> period in the middle of "$1.25M" being interpreted as the start of an
> existing extension and the code intentionally doesn't add an extension if
> there is already one as many people, me including, find the alternative
> behaviour of always appending it pretty aggravating, as it would result in
> e.g. "README.md" being saved as "README.md.txt" if the default filter uses
> "*.txt" for example.

Let's first see whether we agree what expectations are reasonable.
When I save some work in application "A", and then close "A" and
reload it later, I expect that the file that I just saved...
 - is offered as a candidate in the "File | Open" dialog; and
 - appears prominently in the MRU list.
Aren't those both behaviors that end users would normally expect?

With "A" = ms excel version 2211, I save, entering this name:
  1st Sample Bank - Tier 1 - FUW - $1.25M - PRELIMINARY
and "A" adds its characteristic extension, resulting in
  1st Sample Bank - Tier 1 - FUW - $1.25M - PRELIMINARY.xslx
After I exit and then reload ms excel, I am able to open that
file it via "File | Open", and it's in the MRU list.

With "A" = ms word (also version 2211), the same behaviors are
observed (with extension '.docx').

But if "A" = lmi, neither behavior is respected, at least not
with windows-11--and also not with GTK: if I blank out the
entire "unnamed1.cns" string in GTK's save dialog and enter
  2nd Sample Bank - Tier 1 - FUW - $1.25M - PRELIMINARY
then it saves a file with that exact name, appending no '.cns'
extension.

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

If we could show end users that excel and word behave the same
way, then we could say lmi shouldn't do what ms is unwilling to do.
But that's not the case here: from our end users' POV, lmi is just
broken, and they want it fixed.

>  Of course, other people do think that the extension should always be
> appended, see the latest (but not the only) discussion of this in
> https://github.com/wxWidgets/wxWidgets/issues/23193

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

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

Yet it can be reproduced with GTK [above].

>  Second, it's clearly stupid to think that "25M - PRELIMINARY" can be an
> extension and we don't need to integrate an advanced AI in wxWidgets to
> avoid it, we could just add for a space after the period, as spaces can
> never be part of an extension. We could be a bit more aggressive and also
> consider that anything longer than a few (5?) characters is not an
> extension neither, although this might result in some false positives if
> anybody uses e.g. ".census" as an extension. But we probably could live
> with this.

lmi uses these two eight-character extensions:
  /opt/lmi/data/sample.database
  /opt/lmi/data/sample.rounding
And it's not ideal to rely on any heuristics, because they can
so easily go wrong. For example, census files depicting a couple
of different scenarios might well be named thus:
  Some Bank, $2M
  Some Bank, $2.5M
where ".5M" contains very few characters and no blanks, yet is
not to be treated as a file extension.

>  I'll make these changes before the next wx update, and hopefully this
> should help a lot in practice -- even if it's not going to solve the
> problem completely. Please let me know if you disagree.

lmi already overrides wxDocument::DoSaveDocument(). If I can't
persuade you either to change the default wx behavior or to add
a wxALWAYS_APPEND_EXTENSION flag, then I can presumably handle
this in the six lmi overrides. That's tedious, but it's better
than the other replies we could make to this problem report from
a real end user, viz.:
 - "type '.cns' yourself, when needed"
 - "don't write a decimal point in file names"