Replies: 1 comment 9 replies
-
|
WinUI implementation should be pretty straightforward thanks to this library: https://github.com/HavenDV/H.NotifyIcon/ How would the app be set to run in the background through GTK? What's the API for that? |
Beta Was this translation helpful? Give feedback.
-
|
Non-flatpak apps should still be able to report their background activity, they just will not show up in the background apps menu on their own when closing the window (and not reporting), so even that is not a problem |
Beta Was this translation helpful? Give feedback.
-
I just tried to run #110 outside of flatpak. No, there's no indication of background activity, and it's not the Shell, it's the background portal that doesn't know about TC running in the background (I used D-Spy to request the list of background apps from the portal). I'm not sure how all this works, so maybe if we'll explicitly request background permissions from portal then it will work everywhere, I will try later. |
Beta Was this translation helpful? Give feedback.
-
I also have kind of a same opinion. But I think the snapcrafters don't have the same one. https://forum.snapcraft.io/t/backhground-desktop-apps-and-snaps |
Beta Was this translation helpful? Give feedback.
-
And? It's obvious that this feature will not work anywhere outside GNOME 44. The goal is to use the feature when possible, and when it's not the user will decide whether they want to have the app running in background without any indication. The only thing that bothers me is this:
So in snap it's not possible to run a process without a window at all? |
Beta Was this translation helpful? Give feedback.
-
|
Not like that. The snap need to communicate with dbus... like I made a snap running in background as it communicated with |
Beta Was this translation helpful? Give feedback.
-
With the introduction of queue and playlist support, TC is now very comfortable to use for downloading long playlists. And one more feature that can improve user experience in such cases can be an ability to run the app in the background.
Due to major differences in Windows and GNOME as platforms, this should be implemented very differently for each version (but with some common controllers logic ofc).
Common
A new setting should be added. When it's disabled, the app will ask for confirmation when a user closes the window while there are downloads running, just like it does now. When enabled, the window will get hidden when user closes it and the rest that will happen depends on platform.
I'm not sure if this should be enabled by default for WinUI, probably yes if it will use system tray, I can't recall any app that has system tray functionality disabled by default. But for GNOME this setting should be disabled by default (explanation below).
The app will show stats when running in the background:
Where N is the sum of active and queued downloads, P is total progress in percent, S is total speed.
Because we don't use gettext, we can't use complex plural forms required for a lot of languages, and so something more natural like "Running N download"/"Running N downloads" can't be naturally translated to all languages. Another reason to use proposed string is because it better be as short as possible: in GNOME we will not be able to use string containing more than 96 characters.
WinUI
I don't know if there are any new patterns in Windows that can be used, so probably we should use the
goodold system tray icon. Its submenu can contain "Open", "Add Download" and "Quit", and it can show stats in the tooltip. But I'm not aware of all the possibilities in Windows tray, so maybe stats can be shown some better way.Setting title: "Use system tray"
Description: "Show system tray icon and hide the app when closing the window if there are downloads running."
I think if there are no downloads running, the app should quit on window closing even if the setting is enabled. When downloads are finished while running in the background, the app should stay in tray.
GNOME
GNOME 44 has background apps UI. It shows flatpak apps running without a visible window and such apps can set up to 96 characters message to display.
Setting title: "Allow running in the backgound"
Description: "Hide the window instead of quitting if there are downloads running. Showing background activity status requires GNOME 44+"
Background apps UI requires the app to be a flatpak, so the setting should be disabled by default (and GNOME 44+ requirement is one more reason for this). The setting should be hidden and the value in config should be ignored in it's not a flatpak installation, so only the default behavior will be available for non-flatpak. AFAIK we can't check GNOME Shell version in flatpak, so users will be able to make the app hide without any indication of background activity on older GNOME versions, but it's up to a user to decide if such behavior is acceptable for them, and the setting's description warns that GNOME 44+ is required to show background activity.
If while running in the background all downloads are finished and all of them are successful, the app should send notification and quit, background apps UI is not a tray and the app should not just sit in the background doing nothing and waiting for a user to quit it (and if a user enabled the setting when using the old version of GNOME then there would be no indication that it's still running pointlessly). But if some downloads are finished with an error, then the app should continue running, the message text should be changed to something like "Some downloads has failed" and also a notification should contain information about errors, so a user will be aware of them and will be able to open the app, look at logs and retry downloading if they want so.
Beta Was this translation helpful? Give feedback.
All reactions