Feature request, add additional options and info such as hide in app grid in Application setting menu. Some examples seen below

Desktop
1

The current Applications tab in Gnome settings is not much useful. Additional info such as launch commands, working directory, and other toggles such as the option to hide/unhide it from the app menu would make it much more useful!

Below the application menu in Settings on PopOS20.10 using Gnome 3.38

App settings menu
App settings menu1032×920 55.1 KB

Below is my concept menu with additional options such as launch commands, working directory, and several other toggle options.

App settings menu Concept work
App settings menu Concept work1032×920 75.7 KB

I have additional options that could be helpful, such as launch on system startup, info on when and who installed the application from what repo/method.

What do you think of this?

2

The applications tab shows its usefulness for applications installed using Flatpak:

Screenshot from 2021-06-14 10-36-01
Screenshot from 2021-06-14 10-36-011017×851 82.1 KB

where the system has access to various controls that are simply not there with applications packaged for a distribution.

The keys in a desktop entry files are emphatically not settings. Allowing people to change the StartupNotify key in a desktop entry will result in breakage.

Just because it’s a text file, it does not mean it’s a configuration file.

If you want to have a tool that helps you write desktop entry files, I strongly encourage you to contribute to Alacarte.

3

I am not very good with my wording.

What I think I want to say is that having some info and toggles(install date, hide/unhide) would be much easier and user friendly than having to hunt the .desktop file down and edit a text file.

4

Sure: that’s why you want a specific tool to edit desktop entries, instead of exposing this as configuration—when it is very much not configuration.

5

So does that mean that it would be better to use a third party app rather than implementing this directly to Gnome?

P.S. the Gnome subreddit seems to like the idea. Some even pitched their own ideas! Most notably an option to set custom icons.

6

Yes. Not everything has to necessarily go into the System Settings.

I’m not entirely surprised: people on Reddit have a very skewed idea of what makes a good user experience.

7

Yes. Not everything has to necessarily go into the System Settings.

My only question then would be why? Why do you think some functions such as hide application, or launch command, available by default are a bad thing, especially when some of these options are considered start on other widely used operating systems?

8

First of all, because that’s not true; and secondly, because if you want to have the experience provided by other operating systems then you should use them, instead of using GNOME.

In any case, if the question is “what goes into the System Settings and what goes into a separate applications”, then the answer is: it’s decided on a case by case basis, depending on design goals and maintenance effort.

The System Settings is not a good place to shove a whole application launcher editor. The reason why that is the case is that a whole application launcher editor can be arbitrarily complex, more complex than what the System Settings UI can sustain. The system setting has a well defined structure, and a set of limitations of what panels inside it can look like, or how the controls are laid out; since the application page is already filled with additional functionality for applications that are not installed through your distribution’s package manager, your suggested UI would be added on top of that. How does that look and behave? As I said to you earlier, what kind of keys should be visible in that page? “Startup Notification” and “Run from terminal” are, of course, not going to be there because they are not settings: they are choices made by application developers that you have no business in changing; Redditors might think that changing icons is a good idea, when in reality is basically just a way for people to mess around with the identity of existing applications. What else? “Hide from applications launcher” may be useful, I concede that, but it’d be kind of lost in a bunch of entries and switches. Plus, are we talking about changing something that’s already installed, or are we talking about creating new application launchers? Your mock up has the ability to change the command line, which is terrifying to begin with, but it would make sense only if you allowed the creation of new application launchers with custom commands, environments, and settings.

Additionally, there’s the maintenance cost of designing, writing, and maintaining a whole new UI—a cost that you’re conveniently palming off to somebody else, while you ride into the sunset.

When you ask something, always start with the most basic question: what am I trying to solve?

It seems you’re trying to solve the problem of the applications page not having enough UI, which is not really a problem anybody has—and most certainly does not get solved by lobbying a grenade in a UI elements factory.

If you’re trying to solve the issue that you want to be able to conveniently hide launchers from the applications grid, then you could solve this a lot more elegantly by adding a simple switch.

If you’re trying to solve the issue that you want to be able to edit various fields in the desktop entry files without resorting to a text editor, then a launcher editor is a much more appropriate solution, and one that does not require designing a whole new set of interactions inside an existing System Settings panel.

9

I see. So you’re saying that it would fundamentally be difficult to maintain an entire .desktop file editor directly in settings menu, right?

10

Not just difficult to maintain, but also difficult to design within the constraints of the system settings UI.

11

An easy way to edit/view at least some of the fields in desktop entries is definitely something that’s missing in the default GNOME experience, but IMO it doesn’t belong in gnome-control-center.

Some of them probably belong in GNOME Shell, because—

  • That’s where the desktop entries are actually displayed and utilized; it is the main context of desktop entries.
  • It’s already possible to order the entries or categorize them in GNOME Shell (which traditionally is the job of menu editors like Alacarte). So it seems logical that there should be a way of hiding and unhiding apps there as well.

Exposing other desktop entry info in GNOME shell would make sense, too:

  • Showing the description of apps on hover would help conveying what the app does, which is not always clear from the name or icon.
  • Showing keywords, especially when searching, would be very helpful. (E.g., when one searches for “excel”, the LibreOffice Calc entry shows up, but it’s not clear why it shows up, which makes searching more difficult.)

All of the above are about making it easier to launch apps, which is what GNOME Shell is all about. This is completely different from the use case of editing desktop entries so that you can, e.g.

  • force some environment variable,
  • add some command line flag,
  • run apps in sandboxes (e.g. Firejail), etc.

Those, while technically determined by how the app is launched and thus exterior to it, in practice it actually changes the internal behavior of apps. So while these can belong to a settings app, because it will break apps, they should be considered unsupported tweaks and thus shouldn’t to be added to gnome-control-center.

TL;DR: the key is that a dekstop entry mixes at least two completely different things:

  1. Properties that determines when, how, or whether or not the app is displayed. Some of these should definitely be easily customizable by the user, similar to how you can arrange items in GNOME Shell, add them to favorites, etc.
  2. Properties that alter or interact with the internals of the app. These should definitely not be changed willy-nilly without the app “knowing” about it. Which is why things like theming or permissions require new, better-suited APIs.

Another problem is shown by the “Open in Software” (or “Open in Pop!_Shop”) button on the headerbar in gnome-control-center — it can be a bit unclear sometimes whether certain app setting or info should be put into the “app store”, system settings, or both, which is a separate issue from desktop entries.

For example, among things mentioned in the issue comment,

  • “installation info such as date, who, install location, install reason etc.” clearly (IMHO) belongs to an “app store” app like Software, not Settings.
  • “Used storage” is a bit ambiguous and might be beneficial to show it in both places, or perhaps Settings should show data usage, while Software the size of the app itself.

TL;DR: these “additional options” are all useful and related in some ways, but it’s important to consider each of them carefully to decide where, how, or whether or not to add them, because their natures and use cases differ significantly.

12

I don’t think editing the desktop file entry is something the end user has to deal with. You can either use an external app for that or a plain text editor. The desktop file is not a configuration…

13

Indeed, .desktop files provided by applications are more like a manifest than a configuration file. They enumerate properties of the application, and are not to be modified by end users.

If you want to have greater control over which applications get shown in the shell (for example), the solution for that is to store the configuration for that in the shell, not to modify the .desktop files for applications.

The reason for that (apart from the fact that changing some of the properties of a .desktop file will break assumptions in an application about how it’s going to be called or used) is that users can run multiple desktops, say GNOME and KDE, and changing the .desktop files to customise the experience on GNOME will potentially break it on KDE.

14

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.