Launching programs that never open a window (UX)

Desktop
1

Hi,

I think there needs to be a discussion around user expectations for programs launched from the GUI but have no GUI of there own.
One example is ‘Caffeine’, but I know there are others.

I discussed this with he Caffeine developer - he has a .desktop link because it’s the best way to let a user having something run at startup, which he had legitimate use case for.

But this is really a terrible UI pattern that will confuse new users. They launch a program and nothing happens! Has it failed to load? Has it loaded behind other windows? Is it just being slow? And then they maybe launch it twice and end up with 2 (or more) instances.

There is a related issue around programs that open a window but truly are just very slow to do it. Some implement splash screens, but it’s not a universal thing, and I think GNOME should provide some kind of default experience for it. I can’t remember off-hand how Windows does this, but I know I’ve never been as confused on Windows when/if things are launching - I think at least it makes sure an hour glass icon will show while an application launches.

I know this is a very tricky thing. If a program is not guaranteed to open a window or tray icon, how can you display a cursor until it does? After all, this is not Windows, the GUI is a frontend to a proper Unix system, not necessarily the primary interface.

What if there was a convention that a launching program could send signals to some part of GNOME saying what it is expecting to do and what is happening… like “I will open a window soon”, “I have no window but am still starting up”, “I have finished starting up”.

GNOME could then show appropriate automatic splash screens, hour-glass cursors, activated in background alerts, or whatever, appropriate based on how the program was launched by the user (e.g. startup program vs manually launched).

And if something loads but exits with a failure exit code, does GNOME handle this currently with UI feedback?

2

That’s gnome’s issue. Caffeine works (adds an icon in indicators, unity dash) on other desktops like mate, unity. You may want to open a bug on gnome’s issue tracker.

3

Well, my intent here is to have higher level discussions just as a first step. I think if I go to an issue tracker I’m likely to get be accused of posting something that doesn’t fit the exact package I am posting for, or at least get shot down due to it requiring coordination with other packages. And I think if I go straight to a GNOME community mailing list I am likely to get pulled into a discussion focusing on low-level details with lots of references to past decisions and discussions, and people will be a bit too close to everything to want to criticise it or revisit it. Probably.
I think it’s good to have a bit more of a neutral discussion at the distro first to get a broad view of what the situation is, and then bring that to GNOME in a clearer way that doesn’t seem ignorant.

I am very cognizant wherever I post I’m going to get push back from people with the view that as long as things are possible to achieve, and possible to understand with small effort (from their perspective), that’s good enough. I think that’s an attitude all too common in our community, and we need to approach things from the perspective of the average user who doesn’t want or need to learn anything - if things aren’t as simple as they can be, they’ll just stick on Windows or Mac OS. Besides, if we aggressively make things simpler, it allows people to focus themselves on achieving bigger and better things.

Regarding Caffeine in particular - they have Caffeine-indicator and also Caffeine. The later has a .desktop entry but no UI whatsoever. I don’t want to get stuck in the specifics of Caffeine, it’s a generalized problem.

4

As far as slow to open apps (i have none here), they should support Startup notification
https://developer.gnome.org/integration-guide/stable/startup-notification.html.en

As far as caffiene, it installs .desktop to /etc/xdg/autostart and for some reason one to /usr/share/applications.
The one in /usr/share/applications should have NoDisplay=true line…

1 Like
5

Oh, that’s really cool, so there is a feature for it! Thanks for bringing that up, now I can make informed bug reports :sunglasses:.
I’ll look into Caffeine again and get back to the developer about it.

6

Ah, unfortunately not.

The “Desktop Entry Specification” defines NoDisplay as “this application exists, but don’t display it in the menus”.
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

GIO defines the g_app_info_should_show() function, which “Checks if the application info should be shown in menus that list available applications”. This includes a NoDisplay check, but also other checks.
https://developer.gnome.org/gio/stable/GAppInfo.html#g-app-info-should-show

gnome-tweaks is using this to select what programs may be selected for startup.
(Correct me if I’m wrong, but gnome-tweaks currently has the most user-friendly way of choosing GNOME startup applications.)

So I think we need to:

  1. Agree that it is reasonable NoDisplay should be ignored for choosing applications available for startup.
  2. Get GIO to provide more granularity to g_app_info_should_show().
  3. Get gnome-tweaks to take advantage of this.
  4. Get Caffeine and other apps patched.

Suddenly this is getting a bit more complex.

Am I on track?