I’m NOT new to GNOME or Linux and I know that “GNOME Videos” is also called ‘totem’ but when I first started using Linux and wanted to uninstall a GNOME app in order to replace it with another app, I was very confused because I could not uninstall it with sudo apt remove gnome-videos. I had to search on the internet for ‘how to uninstall Videos app on Ubuntu?’ which I shouldn’t have to.
I do not see any reason to make things complex this way. So, I want to create an initiative to change internal names of GNOME projects to match their user-facing names.
For example, nautilus’ internal name could be changed to gnome-files with its repo url changing to https://gitlab.gnome.org/GNOME/Files. Its meson project name would be gnome-files and the shared library libnautilus-extension would be renamed to libgnome-files-extension with a libnautilus-extension.so -> libgnome-files-extension.so symlink for compatibility with legacy code.
But before I actually create the initiative, I wanted to know what GNOME devs think about it, what could be the negative effects of this (if any).
No, sorry. I understand it’s painful, but changing the repository name is going to make a mess for people building the software, both developers and downstreams.
You’re asking people who are already doing the work to do more work, without a proper justification, and no benefit. You should not be surprised that you’ll find pushback.
You are, basically, trying to reverse engineer a solution from a different problem.
What are the benefits? Users don’t care about where the git repository of a project is located, or how it’s called. People filing bugs should get to the application’s website using the About dialog.
Removing applications via CLI is not a use case: we have GUI applications for that, which present the appropriate application instead of using a name in a flat namespace. If your distribution doesn’t provide them, then take it up with your distribution.
Is adding a git remote a lot of work? That does not seem like a lot of work to me.
It does not have no benefit. The benefit is simplicity and the justification is saving new users from confusion.
Simplicity and avoidance of confusion.
Yes, people filing bugs can use AboutDialog to reach the application’s website.
I know users don’t care about location/name of the repository of the software they use directly but the new users wanting to know more about their system would like names of the apps to be consistent. As a user, I love simplicity of GNOME but this is the part where it lacks simplicity.
The problem here is that software centers are not reliable. Why do you think a new user (me in the beginning) instantly jumped to using apt instead of trying to use gnome-software? The thing is, I tried gnome-software first, it didn’t work.
Those are not suggestions from distros, are they? Those are simply the package names they use.
But the most important thing here is that GTK is not user-facing, at least not for a regular user but totem and nautilus are and their package names are exactly totem and nautilus respectively in almost every distro out there.
OK. If it seems too much work, can’t we, at least, add a guideline for devs to name new apps with matching user-facing and internal names?
Also, I do not want the devs to do the work they do not need to do. I do not have the authority or permission to rename/move repositories but I’d like to do all the code changes required for the initiative myself. Don’t GNOME initiatives work this way? I thought the people involved in the initiative do all the work required for the initiative and not the maintainers/devs of the projects.
Sometimes it will be possible, depending on the development history of the app. Sometimes it won’t be possible. Thing is, core apps are supposed to present generic user-visible names (“Files,” “Videos,” “Web”) and non-core apps are not supposed to use “gnome-” in their codenames. So as apps inevitably move around, there is going to be a mismatch.
With user-facing name ‘Image Viewer’, internal name ‘gnome-image-viewer’ is acceptable but ‘loupe’ is not.
So “Eye of GNOME”/eog should be renamed to gnome-image-viewer now.
And then when loupe becomes a core app, the app-formerly-known-as-eog must change its name again, and loupe takes the gnome-image-viewer name.
That is, the apparently same command (gnome-image-viewer) suddenly exposes a completely different CLI API (invocation convention, command line flags, …).
Really, for CLI users that is much more important than whether the command they use (and put in scripts) matches a user-facing string in a .desktop file.
“Saving new users from confusion” isn’t a justification. Why would users be confused?
So now the “Eye of GNOME” application is mapped to “gnome-image-viewer”, and the GNOME Image Viewer application is… what?
You cannot constantly change binary names, and you cannot have two applications with the same binary name, because that is not possible in a flat namespace like a Linux distribution—that’s why Flatpak uses a reverse-DNS naming, incidentally.
We also can’t keep moving repositories, binary names, and application identifiers.
We can simply change its user-facing name to ‘Eye of GNOME’.
That is the opposite of what you are suggesting. You are arguing that core apps like nautilus and eog should be renamed to match their generic names in the .desktop file.
I did pick eog as example because it is likely to be replaced in core apps in the near future. But the argument applies to any app. We cannot know whether totem or nautilus will be replaced in 5 years, just as we didn’t know that gedit and terminal would be 5 years ago.