Since Nautilus 3.6, this option has been disabled and somewhat confusing. It is important for new users and not too tech savvy since most don’t know how to create one other than opening the application and creating it from there. I am aware that this can be fixed by creating a new templates folder but this should be done by default. Not to mention that the templates folder is almost a hidden feature.
This could be implemented in different ways:
The templates folder would have default entries for the most used extensions, such as .txt. Other apps like LibreOffice would create new entries when installed, like .odt, to have a more complete list.
No drop down menu to create a new document (an empty entry). The user would have to type the extension himself but that’s already better than having nothing at all.
A “create new file here” button, which would let the user pick applications to create the file with.
Of course these are just my ideas (and antonio[m]'s from IRC). This topic is intended to create a discussion about this feature.
The New Document menu is not shown by default because the Templates folder is empty by default in major distributions.
But if it was not to be empty by default, what should be placed there? I guess it would depend on which applications the distribution ships by default ─ it doesn’t make sense to offer to create a new .odt file if there is no word processing application ─ as well as the expected needs of its main target audience.
But I think the design of this feature should be reconsidered as a whole.
This templates folder system was designed way back in 2003 Template system
But I think this 2003 design doesn’t meet 2019’s standards.
It seems to be optimized for very advanced use cases, expecting users who manually craft their own templates, yet it fails to provide a simple and effortless solution for the simplest cases.
Also, it’s disconnected from the application’s own templates system. If I open LibreOffice Writer and create a new file from there, it let’s me use a set of templates which is totally unrelated from the set of templates I may have placed in the ~/Templates folder.
The main difference between Google Drive and Nautilus is that Google Drive is part of a suite of document-driven applications; it lets you create templates from other applications in the Google apps suite, and it knows how to find those templates because they all reside on the same server as Drive.
We tried for a long time to have apps to ship their own templates, but:
templates are stored in the user’s home directory, so applications cannot copy files there when they get installed
there’s no system level Templates directory
even if there was a system level Templates directory, it would not be accessible by sandboxed applications
All these issues make it really hard for applications to ship their own templates, and for Nautilus (or any other application, really) to find them and present them to the user.
For me it’s very annoying that in each distribution that ships GNOME I have to create empty file called “Empty file” in templates directory to be able to graphically create empty file in any directory using Nautilus. This case should be reconsidered too.
Once you created an empty file, how do you open it? Unless you mean you create an empty LibreOffice writer file, an empty .txt file, and empty XCF file, etc. etc.
As @jtojnar said, no extension is needed to open file in text editor. It’s not Windows. ;))))))))))
Also, it seems to me if Nautilus would have built-in* ability to create new empty file in directory, it should initially call it just “empty file” but immediately after creating, rename popover would be opened to allow user to rename that file to whatever user needs.
* – in “built-in” I think “if Nautilus have built-in menu item in context menu, without need to create empty file template in xdg templates directory”
There is no such thing as “an empty plain text file”.
Empty files have a application/x-zerosize MIME type—if you have a recent version of GLib and the shared-mime database—which is usually tied to the text editor. If I create a “empty-document.ods” file, I want LibreOffice Calc to open it. What I really don’t want to happen is gedit getting launched, of course, because that would make zero sense.
The current MIME type system has two tiers of operation:
if you pass the file name, and either the file does not exist or you explicit asked for a guess because you’re not really accessing a file on a local storage, the XDG shared-mime database will use its glob rules (which include the extension, because we are like Windows, regardless of what you may think) to determine the closest MIME type applicable
if you pass the file name and the file exist, or you pass a bunch of bytes from the file, the XDG shared-mime database will use its “magic” content matching rules, and return the MIME type of the file
Now, “empty-calc-file.ods” exists, but it’s empty. This means that the shared MIME database will return application/x-zerosize to Nautilus, which will launch the application that is registered for opening empty files—typically gedit, on a GNOME system. If the file didn’t exist, ironically, the MIME database would use the extension of .ods, and launch LibreOffice Calc.
Nautilus can detect the case of an empty file, and then decide to ignore it, but it needs to be modified to do so, and it’s kind of backwards to what the expected API model favours (first guess to avoid hitting the disk/network, then try to get an exact match) and it ends up in interesting edge cases like:
create empty-file
GIO opens empty-file and returns application/x-zerosize
Nautilus queries the MIME type again, using only the file name to guess
GIO does not open empty-file and returns application/octet-stream because there’s no extension
And application/octet-stream is either an executable binary or something that doesn’t have a default MIME handler.
Nautilus needs to remember that the file is empty, because if it doesn’t, it’ll need to check if the file has the execution bit set, and try and launch it as a binary. This is even less fun when dealing with volumes on NTFS/FAT file systems, because the x bit depends on the mount options.
it would be good to have: a) system-wide templates (for example Windows provides them) (/etc/xdg/templates?), b) translatable names of those system-wide templates, maybe by using .desktop files to describe them.
They cannot do this, unless they create a home directory skeleton template, which would not apply to existing users, and would not do anything to applications installed after the user creation. Additionally, if applications are sandboxed, they won’t have access to the user’s Templates directory anyway. In any case, Linux distributions have abundantly made clear over the past 10+ years that they are not interested in this.
Applications will want to install their own templates, and system administrators will want that too; this means a more complex layout, for instance the one used by systemd for service files:
/usr/share/xdg/templates — distro/app packaging
/etc/xdg/templates — site customisation
$HOME/Templates — user customisation
In any case, this would require a standardisation effort to ensure that applications can find those templates; right now, they only have one directory to check, which means they’d need additional API and logic to go through all the additional template directories.
I guess if we had a system-wide templates folder like /usr/share/xdg/templates as you suggest, then upon installing an application Flatpak could export the ones from the apps like it exports desktop files, icons, …
We could also add ${XDG_DATA_HOME}/templates (soft-deprecating ~/Templates), and then the relevant API would search for templates in all ${XDG_DATA_DIRS}/templates and what am I saying of course I’m not volonteering to implement any of this.
Why not just bringing back the “New document” feature as it was in the past? …just like the “New folder” option:
Right click into Nautilus
Select “New document”
Type the name of the file
Press [Enter]
That’s it
Pros:
This is the way it works in almost every file manager and I presume this is the behaviour users expect.
This allow users to create the “first” file into the Templates folder, fixing the problem that Nautilus can’t create any file till you create a file into the template folder using an external software (terminal, text editors, etc…).
It’s actually better when you can immediately write the name of the file you are creating instead of rename it later.
