GNOME Bugzilla – Bug 306729
A mapping from template extension to document extension should exist
Last modified: 2021-06-18 15:28:54 UTC
Many applications which support templates, have a specific extension for template files. For instance, OO.o Impress has the .sti extension for templates, and .sxi for presentations. I like to save a few templates into my ~/Templates folder to be able to quickly create new files from templates. However when I create a new document from an .sti file that resides in the templates folder, a new file is created with the .sti extension. The desired behaviour would be that a .sxi file is created. Therefore I propose an automagical mapping between template- and non-template extensions or mime types.
Thanks for your bug report! We'd have to special-case various template formats. Does OOo have any more of them?
oowriter: .stw; oocalc: .stc; ooimpress: .sti; oodraw: .std Of course, not only OOo templates should be supported, but gnome-office (.awt), ms office (.dot, .pot, ...), old staroffice (.vor), koffice (.???), OpenDocument (.ott, .oth, .otg, .otp, .ots), WordPerfect (.wpt) etc. templates as well.
Created attachment 48967 [details] [review] Proposed patch against HEAD. Maybe you could check the mapping and tell me if it lacks any common formats? I've ommitted word since according to some website I found doc doesn't match dot semantically.
let's see... KPresenter: .kpt => .kpr KSpread: .kst => .ksp KWord: .kwt => .kwd PowerPoint: .pot (or is that also semantically wrong? - note the conflict with gettext .pot templates, maybe we need some mime type magic here) One important addition would be the possibility for applications to register a template extension mapping with nautilus in some way. We can't possibly be exhaustive here.
While we're at it, we could optionally add providers which convert templates to documents, because - as we mentioned - they diverge semantically for some formats. Seriously, I think an application registry would really be overhead. The MIME check for .pot is in scope, though.
As a temporary solution this would be nice to have for 2.14. But I _do_ still think that such a registry is the Right Solution (TM). :-)
Christian, any chance you could get this in for 2.20?
Not to sound rude but This patch hasn't been looked at for 2 years. It would be nice to have this feature.
Comment on attachment 48967 [details] [review] Proposed patch against HEAD. $:andre\> patch --no-backup-if-mismatch -p0 < patch patching file libnautilus-private/nautilus-file-operations.c Hunk #1 succeeded at 6292 with fuzz 1 (offset 3917 lines). Hunk #2 FAILED at 2453. 1 out of 2 hunks FAILED -- saving rejects to file libnautilus-private/nautilus-file-operations.c.rej Hence setting 'needs-rework' as patch does not apply cleanly.
Comment on attachment 48967 [details] [review] Proposed patch against HEAD. $:andre\> patch --no-backup-if-mismatch -p0 < patch patching file libnautilus-private/nautilus-file-operations.c Hunk #1 succeeded at 6331 with fuzz 1 (offset 3956 lines). Hunk #2 FAILED at 2453. 1 out of 2 hunks FAILED -- saving rejects to file libnautilus-private/nautilus-file-operations.c.rej Hence setting 'needs-rework' as patch does not apply cleanly.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.