'Startup Application' added to settings?

I think it would be great to have the ‘Startup Application’ feature (currently offered in Tweaks) baked into the desktop environment. And I suppose settings would then be the most logical place.

How do you think about this?

This post is focused on feeling the waters on the philosophical side, rather than ways of implementation. Since such topics tend to come with some strife.

2 Likes

I think most users would like it, If not, at least I will like it.

This is pursued through the Background portal; apps can use that to request to start automatically in the background. See comment from Allan Day on a feature request for the same: Add program to startup on Applications menu (#1400) · Issues · GNOME / Settings · GitLab

So that’s agreeing with the need to have an option for apps to start automatically. Background portal support is implemented in GNOME and many other desktop environments. Apps need to use the portal though.

Note: @jakedane Thank you for your insightful message.

Present perspective

The following argument is the basis for the current situation, as I understand it. Correct me if I go wrong in the following:
Each app should (when applicable) offer the autostart feature to the user, through the available (XDG) interface offered by the OS. Therefore, it is considered a redundancy for the OS to also offer this functionality.

This makes sense, but I think there is an alternative way to look at this, see as follows.

Alternative perspective

The current approach seems to incorporate the notion that this feature is primarily used to start apps that run continuously in the background, such as VPN and cloud apps. But I use this option for ‘foreground’ apps too. For example: a webbrowser, note-taking app, and IDE. I think this influences the way we perceive this feature conceptually.

As follows a two-part example to point out, what I think is, the difference.

Example part 1. With a VPN app, 90% of the interactions are about setting up the app. The GUI is basically a settings page. Once set, we hit the ‘launch at login’ toggle and we are done. The same is true for about all background apps.
It seems reasonable to think that providing the autostart feature of XDC’s background portal sufficiently covers this use case.

Example part 2. Deciding to start several ‘foreground’ applications at login, looks more like: setting up a second display, or deciding about if and how I want to receive notifications for any given app. It influences my everyday workflow and interaction with the desktop environment.
It is not unreasonable to think that the user will encounter some edge-case scenario’s that justify the implementation of some additional controls.

What?

As follows the options I would like:

  • Timing of the autostart
    • Absolute: time based
    • Relative: app A starts after app B
    • The first would help me solve all the the issues for which I would like such a feature. The second would address some of the cases more directly, and in a more elegant way.
  • Auto-move-to-window. This may be a contentious one, as it can be used with or without the autostart function. I make no suggestions about implementation at this point, but here is how I see it conceptually:
    • I think this feature makes no sense when I manually start an app, since I always want the app to open on the workspace I am looking at.
    • I think this feature makes a lot of sense when I autostart an app at boot. Because then I no longer have to move the apps to the appropriate workspaces every morning.

Note: I had started another post (see discourse.gnome. org/t/feature-s-request-tweaks-startup-application/24375) to cover this topic because I thought it should be dealt separately. But I incorporated these idea’s here because the other post didn’t get any attention, and it seems fitting now.

Why?

So, why should we want this to be part of the desktop environment?

  1. It checks GNOME’s KPI’s
    • Choosing our preferences. The ability to autostart applications with no additional options constitutes “Too few knobs”. Starting many applications with the OS will invariably lead to edge-cases
    • As a user I don’t want to start the same couple of apps at every boot-up (and redistribute them among the same set of workspaces).
    • Achieving consistency and reliability by taking responsibility for the user’s experience (principle 6) and high-quality engineering (principle 4) (blogs.gnome. org/aday/2017/08/08/the-gnome-way/). Thought the proposed features seem simple in theory, I expect the practice of implementation to be complex. Due to the many situations that might happen. The app dependency is tricky because what if app A (before B) fails? We don’t want to offer the user as many controls as systemd offers for such situations. The automove should work consistent for one display, two, three, etc. It may need to act different for a ‘known’ display (in my office) versus an ‘unknown’ display (at my customer’s office). This is more than a simple tweak / extension / hack, like to get an ever present dash, or a clipboard manager. At present I am using tweaks to control the autostart, and an extension for the auto-move option. I can say from experience that these leave much to desire. Even when only considering the functions that they are designed to do, the experience is flaky. I don’t think these features are addressed properly within the extension space.
  2. Circle of concern & circle of influence. By relegating the implementation of the autostart toggle to the app we created a thin veneer of ambiguity about who could and should do what. At present this situation is considered within the circle of concern of the app. Hence, the desktop environment takes no concern. Yet, everything about the starting and stopping, including all means for improving the user experience, lies outside the control of the app, and firmly within the control of the OS. Much of the flakiness I experience is because of the gray that is created by this mismatch.
  3. It is a natural extension to the path GNOME is taking
    I started using GNOME-based Linux as a daily driver about a year ago; after being a life-long MS Windows user (since the XP days) with a brief interim period of MacOS. I forced myself to go GNOME all the way, that means:
    • I no longer minimize applications - there is no such thing, right?
    • My desktop is distraction free
      • I no longer see a dock on the screen, unless I decide to
      • Apps no longer give birth to tray icons
    • I use multiple workspaces
      • 4 by default, applied in GNOME settings. All though, one might say 8, since I use a second screen most of the time
      • I never used workspaces on MS Windows and absolutely had to on MacOS
        I feel like the management of application windows takes me a little more effort and conscious thinking compared to both Windows and MacOS. Though I am fairly new to GNOME, I don’t think this offers a sufficient explanation after a year of fulltime use. By eliminating all the noise we gained peace and simplicity. But we also lost some accessibility (or flexibility, I don’t know exactly how to pinpoint to this issue yet). Would it therefore not be nice to offer a little extra (optional) automation to smoothen the experience?
        I certainly think so. And I think the suggested options would be a great (GNOME-isch) way to do that - especially in a time when the rest of the world tries to cram AI in every nook and cranny of their UI.

Note 1: I excluded example use-cases of the timing options for the sake of brevity. But feel free to ask me about it, I have several.

Note 2: notice that I did not mention once the need to offer a single place for the controls in this message. It is more or less implied. I simply think it makes the most sense within this train of thought. That is not to say that I don’t appreciate the overview that such an approach brings, because I do

Questions

  • What is your overall perspective after reading the foregoing?

    • Does my thesis make sense? Any corrections?
    • Do you like / dislike the idea? Why?
    • For those who like the idea, any additional suggestions?
  • Suppose we would implement these suggested features. What would it take on a technological level?
    From a systemd perspective, adding a delay is not a problem. But it seems to me that the XDG Background portal doesn’t offer a direct means for this out of the box. This is where my knowledge stops, hence the following questions.

    • Does the current XDG protocol allow for implementing a delay either by time or dependency? Or does it need to be extended to offer these features?
    • Do these features have to be implemented through XDG? or could they also be implemented separately - leaving XDG out of the equation?
    • Suppose, we have a magic wand, what would be the most ideal way to implement these? (purely technology-wise and in regard of XDG)
      • Should we should we implement this in XDG or not?
      • Considering a time delay and the most simple app dependency
      • Disregarding unhappy flows
      • Disregarding the front-end, what we would want from a usability perspective.
      • The auto-move-to-window option is not as natural an extension to the autostart option as the delays are. I don’t know how to conceptualize this, even in technological terms. So, I leave this an open question.
  • Suppose these suggestion would be implemented through XDG. Does this imply that each app should be able to offer controls for these as well?

    • I don’t know what it would look like if these controls are handled by the apps. But on first sight, it seems quite tricky to me.
  • I would like to understand GNOME’s architecture better. In particular regarding settings, XDG and systemd. Does anyone have recommendations for good resources?

I don’t know if auto starting apps that don’t run in the background is a common use case for GNOME, if it’s a goal for the design team. Sounds similar to session restore: being able to save which apps are running and where their windows are. Related issue: Feature Request: restore session (#703) · Issues · GNOME / gnome-shell · GitLab

Apps opening in the same place as before (restore window size & location) is a Wayland protocol being worked on, if I read that correctly: staging: Add xdg-session-management protocol (!18) · Merge requests · wayland / wayland-protocols · GitLab. Related issue: Remember the last position of the application on the next startup (#3655) · Issues · GNOME / gnome-shell · GitLab

The background portal currently only supports yes/no for auto start, no delay. Why would a delay be needed? Isn’t it sufficient to start apps after the desktop has fully loaded?

Auto-move vs session restore

My understanding of session restore
A new app-window session gets the same size, workspace, display, and position on the workspace as the last session.

What I mean with auto-move
The user tells the OS that App X should always open on workspace Y when auto-started at login.

  • Regardless of the location (that is: which workspace) during the last session
    • At this point I have no answer to the question of what to do with the size and position for a non-full-screen window. A question that seems primary to the current work on session-restore.
  • Not applicable when it is manually started, presuming the user would then want the app to appear on the workspace in view.

This grows more complex quickly when considering all the possible variables. Let’s consider a laptop with a second display attached: the user tells the OS that App X should always auto-move to workspace Y on the second display.

  • The difficulty lies in the fact that the user may not wish the app to open on any second display that gets attached. For example:
    • the attached display at the office: yes
    • the attached display at the customer’s office: no
    • the attached display at home: yes
    • how about office buildings with flex-workspaces?
  • This complexity is one of the main reasons I think this should be done by the OS, rather than an extension.

I think auto-move and session restore are different concepts from the user’s perspective. But I can imagine there might be quite some overlap on the technology side.

Autostart Delay

My motivation for posing this feature is not about solving a particular use-case. Rather it is a small element in the result of a particular way of thinking. I will expound on this in my next message. First, I offer some practical example-cases, as requested. These are all edge cases, and objections can be made for each of them.

Example 1. My cloud app gets confused during autostart when it starts parallel to my VPN app. Delaying the start of the cloud app would have resolved this issue.

Example 2. Delayed startup of large applications because of system slow down and increased waiting time.
Many years ago, I created a batch file on Windows to startup an application with a 5 minute delay (XP / Vista days). Back then, the computer would take a considerable time to boot. Starting the application directly at login would slow everything down because the system was still in the process of booting up. By delaying the autostart it could be done at a time when it didn’t impact the system as much, and thereby also not interfere with the tasks of the user.

Example 3. Recently I developed an application for an embedded-like device (it ran Debian on a Raspberry Pi, not really embedded) with a touch screen. The app consisted of two parts: a GUI part and a background daemon.
The whole thing needed to autostart at once with the GUI open and ready to go. The GUI needed to start after the background daemon was fully alive. I solved this with systemd, which was fine for the occasion, but it would have been useful to have the delay available in the GUI.

Theoretically speaking, this feature may apply to a subset of the use-cases for which the same feature in systemd is used.

A hypothesis

I imagine that the suggestions I make are, in their own right, perceived as inconsequential. Yet I think otherwise. Therefore I presume these suggestions require a certain frame of thought (or paradigm) to be properly understood. As follows I offer three fundamental idea’s that govern my thinking. I hope this will help the reader to see what I am getting at.

Three fundamental precepts

  • The OS should ‘facilitate’ and ‘enable’
    • I start from the point of view that the OS should fundamentally have a facilitating and enabling role. Ideally the OS facilitates the user with as much freedom (or liberty) for doing things as possible, and enables the user with as much power (or control) to do these things as possible.
  • (further) Reevaluating apps
    • It seems that apps are viewed (in part) from a old paradigm that no longer fits very well. For example:
      • We started with the concept of a single large desktop and windows placed on top. Today we have multiple workspaces, and much more. The new paradigm is more sophisticated, but also more complex. Which, at times, requires more effort to manage.
      • Apps were much more single defined entities, with a hand full of varieties. These days the lines have blurred, concepts among apps overlap, and the environment apps inhabit has become more complex.
    • Note: of course Gnome has done much in terms of reevaluating existing concepts. Hence the mention of ‘further’ reevaluating.
  • New recipe new problems
    • Switching from Windows to Gnome offered me: a decrease in visual clutter (great), but also a decrease in effectiveness with which I get to control app-windows (not so great).
      • Contrary to Gnome, I never used more than a single workspace when working on a Windows computer.
      • Two displays, keyboard shortcut to move windows between displays (like Gnome, unlike MacOS), split screen, everything at hand all the time, effective means to deal with multiple app-instances, and alt-tap - together this makes for an effective way to move apps around and switch between them. To such a degree that I couldn’t be bothered adding virtual workspaces.
      • This approach doesn’t work with Gnome. Much of the value in Gnome’s way of working comes from the use of multiple workspaces. But workspaces require more effort to manage. I feel like I dispense significant energy in managing windows.
      • I would not survive Gnome-world without ‘shift-super-arrow’ and ‘alt-shift-super-arrow’.

Proposed features in light of these precepts
(this covers no features I have not mentioned in my previous messages, just stated differently)

  • Consistent Window-placing. Specific and reliable placing of app-windows across workspaces and displays
    • The bedrock for everything that follows. Without this foundation extensions can offer a flaky experience at best.
    • To relegate this to ‘extension-world’ is to reject the value of the concepts below which eliminates the motive for building this foundation.
    • Example. At present I use the startup applications tweak and an the auto move window extension. This works but not without occasional shenanigans. Most days all 4 apps start on their designated workspaces, some days they all start at the first. Some days a particular app starts a single instance, sometimes two (two is what I want). Some days they appear on the first display, some days on the second.
  • Ability to control how / when / where app-windows are placed
    • More specifically: the ability to control the autostart at login from the OS side (that which got this topic started) and to designate these to a certain workspace and display.
    • After acknowledging the diversity in forms and shapes apps come in these days.
      • Foreground and background are less distinct and the binary view can be limiting for present day apps
      • Apps can have multiple instances. Two instances can be similar (like a file manager) or distinct (like the concept of ‘vaults’ in the Obsidian note-taking app; each vault gets its own app-instance and represents a distinct ‘environment’, like ‘work’ vs ‘private’).
    • After acknowledging the increased complexity of the environment that apps operate in.
      • Apps are evermore interconnected with its surroundings (internet, Bluetooth, online accounts, etc.)
      • Apps are evermore interconnected with other apps
      • And at the same time more boundaries are created (moving from root access to sand-boxing and privacy controls).
  • Ability to automate (certain repeating) window-management tasks in order to decrease the overall amount of manual window management tasks
    • More specifically: the ability to control on which workspace and display the app should appear when auto-started at login.
    • A partial remedy for the drawback of Gnome’s workspace based workflow.
  • Some basic tools to cover for (inevitable) anomalies
    • Given the previously mentioned complexities. If many apps get auto-started at boot it is not inconceivable that this could cause for unwanted situations. Most (if not all) of these anomalies are based on timing at the most fundamental level. These could therefore be most effectively addressed on that level.

This is my hypothesis: any single element applied to a single situation may not purvey the notion that the additional controls I propose are significant. But put together this may offer something worth considering.