Dots in filenames and automatic file extension completion

[Duncan]

Mirosław Zalewski posted on Wed, 25 Jul 2012 00:53:02 +0200 as excerpted:

> I decided to make experiment and check behaviour of different applications 
> for files with dots in names. I copied one file (text file, JPG image and PDF 
> document, depending on application) to two names: 1.2.3.4 and 1.2.3.4.
> {txt,jpg,pdf}. Then I opened each file in application, clicked "Save as" and 
> see what filename was proposed in save dialog.
> Results:
> program              file with ext   file without ext
> LibreOffice (kde)    1.2.3.odt       1.2.odt
> LibreOffice (gtk)    1.2.3.4         1.2.3
> LibreOffice (none)   1.2.3.4         1.2.3
> kwrite               1.2.3.4.txt     1.2.3.4
> leafpad              1.2.3.4.txt     1.2.3.4
> Okular               1.2.3.4.pdf     1.2.3.4
> Gwenview             1.2.3.4.jpg     1.2.3.jpeg
> KolourPaint          1.2.3.4.jpg     1.2.3.jpeg
> GIMP                 1.2.3.4.jpg     1.2.3.4


Wow.  I don't know a solution, unfortunately, tho I have an idea
for you to try, but that's a very interesting test you devised! =:^)


FWIW, I don't normally have a use for office suite type apps, plain
text files generally suit my needs for text-only, and if I were
to be doing mixed-media, I'd prefer something like HTML, not
an office suite format, proprietary or not.  So I don't believe
I've ever even had LO or its predecessor, OOo, installed at all,
tho IIRC I have had individual parts of koffice/caligra installed
at times to read specific documents.

So I don't have any personal experience with LO at all.  But what
I'm wondering based on my general kde experience, is this:

a) Does LO use native desktop file-save dialogs, kde's file-save
dialogs on kde, gtk's on gtk, and either gtk's or its own on
bare X11?

b) For kde apps, and thus LO too if it uses native kde file dialogs
on kde, does the suggested save-as name change, based on the
filetype filter and/or whether the "automatically select filename
extension" checkbox is selected in the save-as dialog?

Stimulated by your testing idea, I ran my own tests, tho only of
kde apps...

KDE's file dialog has an optional filetype filter.  For apps
such as okular and kwrite, this appears to be a combobox that's
preset to "all files" when save-as is invoked, and the automatic
extension checkbox appears to be unchecked by default.

For apps such as kolourpaint and gwenview that can do on-the-fly
format conversion, the filter selector seems to be a dropdown
with only presets available, no type-in possible.  Presumably
the presets are of the types it can convert to.  Meanwhile,
the automatic extension checkbox is checked by default so the
extension associated with that format is supplied by default.


Now, my results (for kde apps anyway) agree with yours, except
that I tried with and without the auto-select-extension checkbox
checked and tried different filetypes for the apps that do
conversions, and with a bit of thought, it's pretty clear what rules
kde follows:

1a) For apps that don't do format conversions (and thus have the
filter combobox in which one can type their own filter), the
suggested filename remains exactly what it was UNLESS one types
their own filter (for instance, *.txt when a jpeg is open in
kwrite, displaying mostly binary gibberish, of course) in place
of the default all files.

1b) The auto-select-extension checkbox is disabled as well, UNTIL
one types their own filter.

1c) If one DOES type their own filter, the checkbox is enabled,
and the suggested filename changes in accordance with the apps
with filetype/format conversion case described below.

2) kde apps that do format conversions (thus use the filter dropdown
box with no chance of typing your own filter):

2a) Auto-select extension checkbox state memory.

The auto-select-extension checkbox state is remembered across
application restarts.  HOWEVER, if you select save-as and change
the state, then cancel the save-as, how you cancel it MATTERS.
If you hit cancel (or escape on the keyboard, triggering the same
button), the change to save-as state is saved and you can close
and re-open the app, and it'll remember that change.  BUT, if
you use the window decoration close, thus closing the dialog
via the window manager instead of the cancel button in the
save-as dialog, the checkbox state change will NOT be recognized
by the app, so the default both on another save-as in the same
app session and across close and reopen will remain unchanged.

This small particular has me rewriting a bit of this, as I didn't
originally spot the difference in behavior based on dialog cancel
method...

2b) Behavior for unrecognized or wrong extensions

Gwenview actually refuses to open files of the wrong extension
(jpeg renamed to png, for instance) or of an unrecognized extension
(your 1.2.3.4 example won't even open as *.4 isn't recognized), here.
Kolourpaint apparently looks at the extension if supported, but looks
at the actual file data if it doesn't recognized the extension, as it
refuses to open a jpeg renamed to *.png, but will open the same jpeg
with your 1.2.3.4 name correctly.  FWIW, that's running kde 4.9-rc2,
but with semantic desktop not only run-time disabled but the option
hard-disabled at build-time so no support built-in.  It may be that
gwenview would use nepomuk's semantic-desktop metadata and open the
1.2.3.4 file just fine if that were on.  Or maybe it's a kde version
behavior difference, especially since I'm running a pre-release.  So
with the caveat that the file does actually open...

2c) file's extension recognized, auto-select-extension on

2c1) By default the filetype filter is set to match the extension and
the filename remains the same.

2c2) If the filter/filetype is changed, *ONLY* the last dot-component
extension is changed, to match the one set in the filter.

2d) auto-select-extension on, extension unrecognized/unsupported

2d1) If the extension is NOT recognized (the 1.2.3.4 case),
for kolourpaint at least (gwenview refused to open the file,
see 2b), an apparently application-specific default type is
originally set.  Thus, a *.jpg file renamed to 1.2.3.4 does NOT
suggest the original actually jpeg file's associated *.jpg, but
instead, *.png, kolourpaint's apparent default.

2d2) In the unrecognized/unsupported extension case, Kolourpaint at
least appears to strip the last dot-component extension, replacing
it with the extension associated with whatever filetype is selected
in the filter, be that the default filtertype, or another selected
by the user.

2e) auto-select-extension off

With the auto-select-extension state set to off by default, the 
suggested filename remains the same, regardless of original
extension recognition or filter change.  It's worth noting, however,
that kde's still doing the logical split internally at the 
same last dot-component extension, as can be seen by default
selection in the filename textbox.  The last dot-component
remains unselected by default, and thus will not change if
the user simply starts typing, while the rest of the filename
is selected and thus will change.  Thus, if a user simply starts
typing, without bothering to change the selection in any way,
the last dot-component extension remains as it was.

3) Common two-component extension behavior

I decided to test a common two-component extension, *.tar.gz,
to see how kde handled it.  For kolourpaint at least (see 2b),
with auto-select-extension on, the same behavior held, only the
LAST dot-component (.gz) was changed, so the filename suggestion
became *.tar.png or *.tar.jpeg when I selected the corresponding
filetype filters.  With auto-select-extension off, the filename
suggestion remained the same (as in 2e), BUT the pre-selected
text behavior changed -- the last TWO dot-components were
unselected, so if a user were to simply start typing, the full
two-component *.tar.gz extension would be retained.


Examining the above rules, it's pretty clear that for kde apps at
least, a save-as (in an app that supports filetype conversion),
UNCHECKING the auto-select-extension box, and either completing
the save or canceling via cancel button, NOT by window decoration
close button (and thus not by wm, but by the app cancel).  Then
exit the app, and the state of the auto-select-extension box should
be remembered as unchecked.

That will change kde's behavior so it doesn't mess with the
filename including extension at all, for save-as dialogs.  (I'm
not sure if it's remembered per app or across all kde apps, tho.)

Alternatively, with auto-select-extension on, kde apps only appear
to mess with the last dot-component extension, even for common
two-dot-component extensions such as *.tar.gz


Based on your table above, that's NOT the behavior that
libreoffice demonstrated.  I'm not sure where their behavior
is coming from, but despite it being different for kde, it
doesn't appear to match kde's default behavior at all.  Instead,
it seems to strip the last TWO dot-component extension regardless
of whether the original was the generic 1.2.3.4 (stripped to
1.2) or the recognized pdf extension/filetype (1.2.3.4.pdf,
stripped to 1.2.3).  It then adds what is I guess its default
*.odt, creating 1.2.odt from the four-part generic and
1.2.3.odt from the five-part pdf.


....

THAT was all based on the issue as described in your post,
WITHOUT checking the bug.  Now I check the bug, and...

It's not the same LO behavior described in your post AT ALL!

Plus, you didn't mention in your post above that LO had a kde
file dialog option and that you were using it, as the bug
filing states.

=:^(

The behavior described in that bug is ENTIRELY consistent with
kde's standard file dialog behavior as both you and I tested
and described it.  The examples given in the
bug all consist of stripping just the last dot-component
extension, exactly the behavior both you and I found with
kde apps.  But I already described the LO/KDE behavior listed
in your table above, deleting TWO dot-component extensions
before adding the .odt, which really didn't make sense at all,
so would indeed be worth a bug.  BUT IT'S NOT AT ALL THE
BEHAVIOR YOU DESCRIBED IN THE LINKED BUG FILING!

Quite a difference, in fact.  So which is it?

Which of course might explain why you listed gwenview as
being able to handle a 1.2.3.4 filename and the results of
doing save-as on that file, while I found that gwenview
would refuse to open a file named 1.2.3.4 at all, so 
gwenview's save-as behavior with it couldn't be tested.
If you're sloppy enough with your reports that you considered
the bug report and this posting the same thing, then that
result is probably because you didn't actually test a literal
1.2.3.4 filename with gwenview, at all!


But be that as it may... given the additional information in
the bug, that you ARE using kde file dialogs, it would seem
that your problem should be solved by simply unchecking the
automatic extension management option (and ensuring that
state is saved as described in 2a, above), so kde doesn't
touch it and you can handle the full filename including
extension manually, without kde messing with it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.