Implement background app monitoring #394

leolost2605 · 2025-03-18T15:36:36Z

Implements background monitoring and allows to kill apps that are running in the background.

Fixes #99
Closes #395

The current UI:

wpkelso · 2025-03-18T17:28:02Z

That ghost is really cute. Your current implementation--with the ghost moved to between launchers and workspaces--is what I would go for; I think it strikes a good balance between space and availability.

~~I'm also partial to having a sketchy-looking dude in the corner there that opens his trench coat to show you all the background apps~~

danirabbit · 2025-03-18T18:17:06Z

I kinda don't love having this in the dock the more I think about it. I know that's what the survey results indicated, but it feels off to me.

I kinda feel like this would make more sense in the notifications center. At least that's the direction it seems iOS and Android have gone for apps communicating ongoing background tasks:

wpkelso · 2025-03-19T16:31:25Z

@danirabbit I agree that the dock is not the place to show detailed reports on actively running tasks or state internal to the app. Those should be notifications in the notification center like in your examples.

However, I think having a version of a widget like this in the dock, that simply lists running background apps, allows me to kill them and/or to access a right-click context menu, and badges for notifications, is a good idea. We already use the dock for managing what foreground apps are open, and what workspace they're on, so I think it's illogical to treat apps that are running in the background differently. I don't like tray apps, but I feel this is a suitable compromise.

leolost2605 · 2025-03-23T10:48:44Z

@danirabbit I think @wpkelso summarized it quite nicely. If I'm looking for apps running in the background I'd look where all the other running apps are and not where I can toggle the WIFI or see notifications.

I think there is a difference between showing status information about tasks or things happening in the background, and just a list of apps running in the background where I can kill them.
For example the android (and also IOS screenshot) shows the former. Actual status information with detailed progress info etc.. This will never be handled by the background apps list proposed here. Instead it should and will be handled by the new notifications portal.
On the other hand at least android (not sure about IOS) recently introduced a new background apps section:

This is what this should be and I think it fits very nicely in the dock.

leolost2605 · 2025-03-23T10:50:19Z

That ghost is really cute. Your current implementation--with the ghost moved to between launchers and workspaces--is what I would go for; I think it strikes a good balance between space and availability.

Yeah I agree that's probably the best. I wonder if there's something we could do to make the ghost look a bit different from the launchers? Maybe a different background like the icon groups or a separator or something?

wpkelso · 2025-03-23T13:10:46Z

I wonder if there's something we could do to make the ghost look a bit different from the launchers? Maybe a different background like the icon groups or a separator or something?

The simplest thing is probably to throw a separator between the ghost and the rest of the launchers. I think that effectively creates a "launch" cluster and a "manage" cluster.

leolost2605 · 2025-07-06T15:48:24Z

I've updated the UI with the suggestions (see screenshot in description) so this should be ready for review now

danirabbit

Clicking the quit button closes the popover. We should probably keep it open so you can see the spinner going etc right?
I also can't confirm that clicking the quit button actually quits the app

leolost2605 · 2025-07-07T22:19:01Z

Clicking the quit button closes the popover. We should probably keep it open so you can see the spinner going etc right?

That is really weird it shouldn't close the popover and it doesn't for me 😅 No clue what's going on there :/

I also can't confirm that clicking the quit button actually quits the app

I think it sometimes it doesn't immediately update. Though for me it now works almost always. When updating this PR only once it didn't work immediately but clicking again closed it right away 🤷
Also I've seen similar behavior with the GNOME Implementation. Does it just never work for you or does it work sometimes?

danirabbit · 2025-07-07T22:47:08Z

@leolost2605 okay so for me, in X11 the popover stays open, but in Wayland it closes

leolost2605 · 2025-07-08T15:41:29Z

I was playing with this idea of using an icon group style to make it more clear this is not an app:

But then I was thinking, why not just show this as an icon group completely? Like with smaller icons on it and everything?

Ohhh I love that idea! Then I guess separator between that icon group and the rest of the icon groups? Or do you have another idea to separate it?

@leolost2605 okay so for me, in X11 the popover stays open, but in Wayland it closes

That's still so weird it stays open for me both in X11 and in wayland. And also there is no code whatsoever that would connect the button press to menu close.

Also can you confirm that the kill now (at least most of the time) works? Or is there something still very wrong?

leolost2605 · 2025-07-08T16:15:05Z

It looks like this now (Ignore the weird header label, I think that comes from me fiddeling with granite gtk stylesheets, idk):

Let me know what u think (I think it looks much better :))

danirabbit · 2025-07-08T17:06:46Z

Ohhh I love that idea! Then I guess separator between that icon group and the rest of the icon groups? Or do you have another idea to separate it?

Yeah I think that works really well and makes it more glanceable! Very cool. I think I'm fine with the separator, but it needs a lighter highlight for the translucent style. I'll push a fix for it

That's still so weird it stays open for me both in X11 and in wayland. And also there is no code whatsoever that would connect the button press to menu close.

Maybe something weird with my install then! I'll see if I can reproduce on another computer

Ignore the weird header label, I think that comes from me fiddeling with granite gtk stylesheets, idk

Naw I was able to reproduce it. It's a stylesheet bug: elementary/stylesheet#1325

danirabbit

Found a really interesting bug. You can drag and drop a workspace and it can replace the background apps group 😅

leolost2605 · 2025-07-26T12:27:46Z

@danirabbit should be fixed now :)

danirabbit

I still think maybe we should remove the item when there are no background apps so it doesn't just take up space in the dock, but I won't block on that. I'm willing to try it in daily for a while if you feel strongly about it.

I have just a few requested changes, but mostly I think this is good to get in :)

data/dock.gresource.xml

src/AppSystem/Background/BackgroundApp.vala

src/AppSystem/Background/BackgroundAppRow.vala

src/Application.vala

danirabbit

Oh I guess one more problem, the item isn't added if building with workspace switcher is disabled 😅 You just get a separator at the end of the dock for no reason. We should probably make sure this does still build when the workspace switcher is disabled and we only add the separator when the workspace switcher is enabled

leolost2605 · 2025-07-29T13:27:04Z

The item is now only visible whenever it has background apps.

Also building with the workspace switcher disabled should be fixed now :)

danirabbit

Just a couple tiny little nitpicky things, otherwise this looks good!

src/AppSystem/Background/BackgroundItem.vala

danirabbit · 2025-07-29T17:21:58Z

src/AppSystem/Background/BackgroundAppRow.vala

+        Timeout.add_seconds (5, () => {
+            // Assume killing failed
+            button_stack.set_visible_child_name ("button");
+            return Source.REMOVE;
+        });


I think this needs to come before the try/catch or it'll never be used right? And then we need to cancel it in finally probably?

The thing is the kill is usually pretty quick (even if the action doesn't work and we have to do a flatpak kill no more than a few milliseconds) and pretty much never reports failure (I never saw flatpak kill return something other than success). But even if flatpak kill returns success the app sometimes continues running for some reason?

What really takes a while is for the freedesktop background apps monitor to pick up that the app was killed so even if we get a success we don't know if it has been actually killed and will now soon disappear or if it failed. So I did it like this that if something immediately fails (for example we fail to launch flatpak kill for some reason) we don't even start the timeout and only start it if everything in our power succeeded (which should pretty much always be the case on a correct install?)

That makes sense. Thanks for explaining!

danirabbit · 2025-07-29T17:26:11Z

src/AppSystem/Background/BackgroundApp.vala

+
+            var session_bus = yield Bus.get (SESSION, null);
+
+            yield session_bus.call (


I'm guessing it was done this way because DesktopAppInfo.launch_action doesn't return errors? If that's the case maybe a comment would be nice so someone doesn't try to refactor it later

DesktopAppInfo.launch_action only supports launching actions that are listed in the desktop file. But while a lot of application install a quit action they don't list it in their desktop file because you don't expect a quit if you right click the app in the application menu but we can still activate it remotely.

danirabbit

Thanks for your explanations! This is great. Let's get it in 🚀

leolost2605 requested a review from a team March 18, 2025 15:36

Implement background app monitoring

97aad50

leolost2605 force-pushed the leolost/background-apps branch from 95c387e to 97aad50 Compare July 6, 2025 15:43

leolost2605 marked this pull request as ready for review July 6, 2025 15:48

leolost2605 requested a review from a team July 6, 2025 15:48

danirabbit added this to OS 8.1.0 Jul 7, 2025

danirabbit moved this to Needs review in OS 8.1.0 Jul 7, 2025

danirabbit requested changes Jul 7, 2025

View reviewed changes

Use built-in styles, improve screenreader (#434)

af131bd

This comment was marked as resolved.

Sign in to view

Use IconGroup for background apps

683ce71

leolost2605 requested a review from danirabbit July 8, 2025 16:15

Make sep highlight less intense, fix off-by-one pos

efd52a9

danirabbit requested changes Jul 11, 2025

View reviewed changes

Fix dnd

cc1eb98

Merge branch 'main' into leolost/background-apps

879b056

leolost2605 requested a review from danirabbit July 26, 2025 12:29

Merge branch 'main' into leolost/background-apps

bf1f8d8

danirabbit requested changes Jul 27, 2025

View reviewed changes

leolost2605 added 6 commits July 29, 2025 13:04

Use quit, throw error, and show notification

acd541d

Make item disappear and reappear

0d96373

Merge branch 'main' into leolost/background-apps

08050fd

Fix not interactable, popover

d1d9da3

Readd size animation

03553b7

Fix offset

93c541a

leolost2605 requested a review from danirabbit July 29, 2025 13:27

danirabbit requested changes Jul 29, 2025

View reviewed changes

leolost2605 added 2 commits July 30, 2025 11:42

remove placeholder

aa00501

add comment

d298025

leolost2605 requested a review from danirabbit July 30, 2025 10:00

danirabbit approved these changes Jul 30, 2025

View reviewed changes

danirabbit merged commit 3f68ec7 into main Jul 30, 2025
4 checks passed

danirabbit deleted the leolost/background-apps branch July 30, 2025 14:56

github-project-automation bot moved this from Needs review to Done in OS 8.1.0 Jul 30, 2025


		var session_bus = yield Bus.get (SESSION, null);

		yield session_bus.call (

Uh oh!

Implement background app monitoring #394

Implement background app monitoring #394

Uh oh!

Conversation

leolost2605 commented Mar 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wpkelso commented Mar 18, 2025

Uh oh!

danirabbit commented Mar 18, 2025

Uh oh!

wpkelso commented Mar 19, 2025

Uh oh!

leolost2605 commented Mar 23, 2025

Uh oh!

leolost2605 commented Mar 23, 2025

Uh oh!

wpkelso commented Mar 23, 2025

Uh oh!

leolost2605 commented Jul 6, 2025

Uh oh!

danirabbit left a comment

Choose a reason for hiding this comment

Uh oh!

leolost2605 commented Jul 7, 2025

Uh oh!

This comment was marked as resolved.

danirabbit commented Jul 7, 2025

Uh oh!

leolost2605 commented Jul 8, 2025

Uh oh!

leolost2605 commented Jul 8, 2025

Uh oh!

danirabbit commented Jul 8, 2025

Uh oh!

danirabbit left a comment

Choose a reason for hiding this comment

Uh oh!

leolost2605 commented Jul 26, 2025

Uh oh!

danirabbit left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

danirabbit left a comment

Choose a reason for hiding this comment

Uh oh!

leolost2605 commented Jul 29, 2025

Uh oh!

danirabbit left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

danirabbit Jul 29, 2025

Choose a reason for hiding this comment

Uh oh!

leolost2605 Jul 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

danirabbit Jul 30, 2025

Choose a reason for hiding this comment

Uh oh!

danirabbit Jul 29, 2025

Choose a reason for hiding this comment

Uh oh!

leolost2605 Jul 30, 2025

Choose a reason for hiding this comment

Uh oh!

danirabbit left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

leolost2605 commented Mar 18, 2025 •

edited

Loading

leolost2605 Jul 30, 2025 •

edited

Loading