Core App Presentation
Contents
The stock applications produced by GNOME and other Linux desktops have generic names and sometimes get their icons from the icon theme. This creates issues and the current situation is a bit messy.
On the GNOME side, there is uncertainty and inconsistency around application names, particularly if variations on the user visible name should be used in Software and in about dialogs.
Background
Currently, the identity of core apps is primarily exposed in:
- Software
- gnome-shell (launchers, app switcher)
- Application menus
- About dialogs
- Out in the world - on application wiki pages, in developer blogs, in online and offline discussions...
Issues with how app identity is currently presented:
- In Software some of the apps have "GNOME" added to their name, (example: "GNOME Software"). However, this is done inconsistently. It also results in the app name being inconsistent. For example, it is different from what's shown in GNOME Shell.
- The pattern of prefixing app names with the "GNOME" can be a bit confusing. In some cases it matches the program name; for example, "GNOME Software" maps on to the "gnome-software" program name. However, in some cases it doesn't - the program name of "GNOME Files" isn't "gnome-files" - it's "nautilus".
- App names in their about dialogs are often inconsistent, and sometimes use their "code name".
- Some of the stock apps from other desktops have the same name and icon as the GNOME core apps.
Some of these apps are hidden in Software, so you can't install them from there, although they can be installed from the command line. This leads to identical apps in the shell.
Stock app icons
A list of app icons that are currently used from the icon theme:
Calculator (accessories-calculator) 
Character Map (accessories-character-map) - Is this used any more? It's not used by Characters. 
Dictionary (accessories-dictionary) 
File Manager (system-file-manager) - the icon used by nautilus has diverged from the icon in the theme 
Help (help-browser) 
Settings (preferences-system) 
System Monitor (utilities-system-monitor) 
Terminal (utilities-terminal) 
Text Editor (accessories-text-editor) 
Web Browser (web-browser)
Goals
- Ensure that applications have stable and consistent identities.
- Ensure that applications are differentiated from one another - two applications should never have identical identities.
- Don't impose artificial barriers on what can be installed and run.
- Make it possible to find out more information about an application, get involved in development, report issues, get support.
Relevant Art
GNOME 3.24
- Core GNOME apps appear in Software.
- Some core apps from other desktops are hidden.
- Some core GNOME apps have "GNOME" added to the name.
Google Play Store / Android
- Core apps don't appear in the store.
- App names aren't unique - there are multiple "Calculator" and "Timer" apps.
- Application icons do appear to be unique.
- In the store, applications are differentiated using their icon and the developer, which is shown beneath the app name.
Discussion
Questions
- Is installing core apps from different distros either desirable or a priority?
- Do we need to differentiate between types of core apps? (Is Settings fundamentally different from Calculator, for example?)
- To what extent is changing icon themes expected to work for apps?
Background on current GNOME behavior
Reasons that core GNOME apps are currently visible in Software:
- Some have add-ons that can be installed
- To enable them to be put in GNOME Shell folders
- Users want to be able to review and rate them
It's worth noting that this is also a question of how GNOME apps might appear in other environments. We also can't stop people installing core apps from other environments using the command line.
There's an argument to be made that anything that conforms to the definition of an app should be installable and usable.
Flatpak and application icons
Flatpak apps are required to ship their icon as a part of the app, and this icon is installed as part of the hicolor icon theme. Selecting a different icon theme will result in some apps having their icons changed, since GNOME Shell looks up other icon themes first. Changing an app icon using an icon theme preference still only works if a) the app uses the icon specified by the icon theme and b) if the theme has been updated to follow the dbus naming scheme for apps, which some apps have adopted.
Core apps
In the future, systems will be increasingly image-based. In this scenario, some apps will be included as part of the OS image (particularly those that need unrestricted system access, such as Nautilus or the control-center), and will therefore not be removable. This is a potentially useful way of defining between different types of applications.
Combining core apps from different environments
On the one hand, the use of the icon theme fits with the generic nature of core apps - so they fit with the rest of the system and don't stand out with their own identities. On the other hand, it prevents core apps from other desktops from being installed - because they end up looking identical to one another (example: you end up with three identical calculator applicatons).
When core apps change
Something to consider - default apps sometimes change - for example, the default Music app might be switched to something else. In these cases it is desirable to have different identities for the new and old versions - users will want to know that the new app is different from the previous one.
However, ensuring unique identities over time is less of a priority for simple utilities (example: Calculator) and core parts of the system (examples: Settings, Help Viewer). This again is a potentially useful distinction.
Some rationale for the design
Core apps are intended to be generic. They are designed as part of the OS and not particularly intended to be redistributable outside of GNOME.
- This would imply that the application identity (name and icon) should follow the visual identity of the OS - in particular that the icon should follow the icon them.
- It would also imply that installing core apps from different desktops is out of scope.
And yet...
- The technical reality is that core apps *can* be mixed and matched. We currently have technical tricks in place that prevents it from happening if you just use Software, but that's an extra layer we've put in place, and it doesn't apply if someone installs their software using the command line.
- There is an argument to be made for not adding extra layers of complexity - for having a transparent user experience that reflects the workings of the underlying technical system. It is simpler and more elegant, for starters.
- In some ways the move to Flatpak improves the situation - an application that is distributed as a Flatpak is by definition intended to be installable as a standalone entity. Extra layers of logic which define which apps can and can't be installed shouldn't be required. At the same time, there probably isn't any reason why someone couldn't create Flatpaks for the core apps from other desktops, so it doesn't make the issues described on this page go away.
- There might be value in allowing some core apps from other environments/OSs to be used in GNOME, and vice versa. Maybe the calculator from another OS has a feature you need?
Tentative Design
Application names should be stable and consistent, and shouldn't change depending on the context. This helps to prevent confusion, to lower mental overhead, and creates a clear model for the system.
Where applications have a different technical name from their user visible name, it should be exposed in such a way that it isn't confused with the user visible name. One principle way to do this is through a program name field in about dialogs.
Where it is desirable to advertise an application's developer, this is best done in an explicit way with an obvious "developer" field, rather than prepending the developer name (the meaning of which may not be obvious). It is also better to expose the developer name as a link, so that users can get more information. This can be exposed as a part of details pages in Software and application about dialogs.
The most important thing to keep unique about application identity is their icon, as this is the most expressive and quick to recognise part of their identity. This will ensure that applications are differentiated when they have the same name (which hard to avoid).
App Icons Plan of Action
- Ship app icons with apps
- File Manager (done)
- System Monitor: FIXME (won't build for me)
- Move app icons in Adwaita to the 'obsolete' context
- Mention the plan to remove the obsolete context in the release notes /3.28/
- Remove icons
Comments
- I think having a unique app icon should be a review checklist item for flathub. We really shouldn't allow apps to use icons from the theme as their app icon. -- Matthias
As you know, I don't think the concept of core apps that are special makes much sense, and I think this is just another example of the problems caused by it. -- Matthias
It would be useful to know what aspects of the core apps shouldn't be special, in your view. Are you referring to how they are named, whether they can be uninstalled, their integration with online accounts...? As noted above, it's possibly worth thinking about whether there are sub-categories of core apps. For example, maybe it makes sense to treat Settings and Software differently in some cases, but not the other core apps. -- AllanDay
If there is a need for special applications (for example the user wants to launch a Calculator, but doesn't care how the application is called) maybe the "Default Applications" concept could be used? But this would mean there has to be a mime-type for each special app use case I guess? -- RetoKaiser