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