I have absolutely no idea what that link has to do with, well, anything.
Application software such as Nautilus do not (typically) make system calls. Instead they call C library functions. If the application is written in C, then it would call those library functions directly. If it were written in a higher-level language, it would call a library that "wraps" or "binds", and calls the C library functions. The following, for example, is the exact same way that Nautilus probably gets a directory listing:
https://www.gnu.org/software/libc/ma...ry-Lister.html
At that level, yes, you're always dealing with filenames. Except when you're dealing with file descriptors (numbers which represent open files), which, really, are at the same level of abstraction.
The implementations of the C libraries, in turn, would make system calls.
That way, the application code is portable, and can be built and run on other platforms. That would not be the case if the applications were making system calls directly.
As for the layers involved in converting a file path to the data containing the contents of the file: the OS, which is at a level beneath the C libraries, looks up the filename's
dentry, gets the
inode from the dentry, and uses the inode to find the
disk blocks. I recommend investing in a book on the Linux kernel and reading the chapters on the implementation of the filesystem, if you want a more detailed answer.
The blocks are the lowest level that software works at. Everything lower than that is implemented in hardware (in the disk controller).
And how would the OS communicate with the disk controller? Well, there's a link to the ATAPI interface spec here:
What kind of api does a sata hard drive expose?
