Initiative: matching user-facing and internal names of GNOME projects

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.

Can’t we just keep read-only mirrors with old repository names temporarily while downstream packagers migrate to new repositories?

As for devs, can’t they just add a new git remote with the new url?

1 Like

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.

2 Likes

This would indeed be very disruptive. A few applications have done it before. It’s a pain.

Another thing to note is that distros don’t agree on names, so who do we favour?

We have https://gitlab.gnome.org/GNOME/gtk

But Fedora suggests that should be: https://gitlab.gnome.org/GNOME/gtk4
Or Debian in its infinite wisdom: https://gitlab.gnome.org/GNOME/libgtk-4-1
Perhaps Alpine’s https://gitlab.gnome.org/GNOME/gtk4.0 is the way to go

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.

1 Like

I would be very grateful if you provided links to some discussions so that I also could understand their pain.

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.

@ebassi @mcatanzaro @zbrown

Where have you gone? What do you think about this?

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.

Having “gnome-” in the name is not that bad. My request is having names that are not completely different.

For example,

With user-facing name ‘Image Viewer’, internal name ‘gnome-image-viewer’ is acceptable but ‘loupe’ is not.

Why, though? As I said: you brought no justification for that, save the slight inconvenience when removing an application from the CLI.

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.

2 Likes

Didn’t I? Didn’t you read this?

We can simply change its user-facing name to ‘Eye of GNOME’.

“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.

OK.

Thank you very much for bearing with me. I really appreciate it.

1 Like