Background portal (Rebased 12-03-2024) #70
Conversation
joshuamegnauth54
force-pushed
the
feat-background-autorun-portal
branch
10 times, most recently
from
8a4ca82 to
5d6e3f2
Compare
joshuamegnauth54
force-pushed
the
feat-background-autorun-portal
branch
3 times, most recently
from
c725ec4 to
57e06f4
Compare
joshuamegnauth54
force-pushed
the
feat-background-autorun-portal
branch
3 times, most recently
from
9a93471 to
d2d7b90
Compare
joshuamegnauth54
force-pushed
the
feat-background-autorun-portal
branch
from
d2d7b90 to
0e5eeb2
Compare
joshuamegnauth54
force-pushed
the
feat-background-autorun-portal
branch
4 times, most recently
from
78be554 to
b1026bb
Compare
Looks like it was deprecated in May (flatpak/xdg-desktop-portal@458560c) and the last release was in April. So presumably it's still required on released versions of xdg-desktop-portal, but won't in the next. |
joshuamegnauth54
force-pushed
the
feat-background-autorun-portal
branch
3 times, most recently
from
c82b8ad to
ff66c14
Compare
|
Their reasoning makes sense. Every portal backend I checked implements autostart the same way (which, in a way, was really nice because it made it easier to implement here 😂 ). This is finally done and it works too! I learned a lot in the process as well. |
src/background.rs
Outdated
| // xxx Is this the correct way to determine if a program is running in the | ||
| // background? If a toplevel exists but isn't running, activated, et cetera, | ||
| // then it logically must be in the background (?) | ||
| AppStatus::Background |
There was a problem hiding this comment.
I don't think this is right. A toplevel is a window, this state seems to describe applications without a window. So the logic should be: If any toplevel exists, then the app is either Running or Active. We currently don't have a protocol to enumerate applications without a window.
I would think the portal would have to track apps launched in the background.
There was a problem hiding this comment.
Thanks for the review and help!
I checked how GNOME handles GetAppState. GNOME exposes a D-Bus interface that allows retrieving the list of running applications. It also has a signal for app updates.
Its Background portal uses that interface to check app statuses. An app that is running without windows is in the background. Apps with windows have their toplevel status checked (active, running).
KDE doesn't seem to check if a program is in the background at all. 🤔 I find this confusing.
The code for the GNOME background portal is pretty straightforward, but I'll have to check if there is a way to get running apps easily via COSMIC.
There was a problem hiding this comment.
There isn't because we don't track "running applications" (which KDE probably also isn't doing), because doing so isn't exactly easy. Any running binary could be an "app".
I assume what Gnome is doing internally is:
- Handle flatpaks as apps
- Use app-scopes to identify apps it launched through one of it's interfaces (still doesn't help with stuff started e.g. via a terminal).
You can do similar things on cosmic, as we also set the corresponding app-scopes. (e.g. systemctl --user list-units -t scope | grep -e "app-flatpak" -e "app-cosmic")
You would use the systemd dbus interface in the portal to enumerate the scopes, filter for app-cosmic and app-flatpak and pull the app_id from the name (the third component). Afterwards you can lookup the desktop-file, if you need anything more.
There was a problem hiding this comment.
Thanks again for the help! I think this is ready again. I'm actively working on this patch again, so any future changes should be implemented faster. 😁
joshuamegnauth54
force-pushed
the
feat-background-autorun-portal
branch
3 times, most recently
from
e05a724 to
fbe43f9
Compare
joshuamegnauth54
force-pushed
the
feat-background-autorun-portal
branch
from
fbe43f9 to
2d371c1
Compare
joshuamegnauth54
force-pushed
the
feat-background-autorun-portal
branch
from
2d371c1 to
77b1577
Compare
|
Can't wait until this is approved! Would this also fix cosmic-files not being able to supply files for flatpak uploads? |
|
Nope! But I can try to look into that after finishing some other patches I'm working on. 😺 The background portal allows sandboxed apps permission to run in the background without any windows open. |
I'll try to provide logs to help with the implementation |
|
Sounds good. I'll take a look into it soon. I can't guarantee I'll be able to fix it though. 😆 |
Here's the spam, it could be useful
There's also this weird thing: |
|
@gabriele2000 I'm not sure what's causing the permission errors. 🤔 The rest of the portal works, right? Like screenshots? You should open an issue with the same log in case someone else knows, but I'll continue looking into it as well. |
I hope the upgrade from 22.04 to 24.04 didn't mess something up too bad, because now the cursor in some flatpak apps is gigantic and there's this weird error. |
I fixed cosmic-greeter during a spark in my imagination, it all started because I was tinkering with dbus and it was the issue, so cosmic-greeter was broken and since it started crucial services (and I was using emptty to log-in, because cosmic-greeter was panicking because of broken configuration that I fixed now) a lot was going on. running now let's see what That's a lot... I shall look up what is this "error 101" |
|
@gabriele2000 I have good news and bad news. The bad news is that I can't replicate that panic, but I remember seeing an issue somewhere where COSMIC Session failed to launch the portal (I can't find it though!). The good news is that someone is experiencing a similar issue: pop-os/libcosmic#731 |
I based my implementation on the official specs as well as code from GNOME, KDE, Xapp (Xfce), and Pantheon (elementary). KDE's imminently readable codebase served as this implementation's primary inspiration. Autostart is deprecated but seemingly still used, so this implementation will still support it for compatibility. The Background portal depends on a working Access portal as `xdg-desktop-portal` calls it to show the initial warning. References: * https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.impl.portal.Background.html * https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/blob/main/src/background.c * https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/blob/master/src/background.cpp * https://github.com/linuxmint/xdg-desktop-portal-xapp/blob/f1c24244f90571209c56b7f45802b70e80da4922/src/background.c * https://github.com/elementary/portals/blob/d868cfa854c731e0f37615e225d5db07cc3f4604/src/Background/Portal.vala * flatpak/xdg-desktop-portal#1188
joshuamegnauth54
force-pushed
the
feat-background-autorun-portal
branch
from
77b1577 to
f986a4d
Compare
(This commit also holds any changes from rebases)
joshuamegnauth54
force-pushed
the
feat-background-autorun-portal
branch
from
f986a4d to
b4ef89f
Compare
joshuamegnauth54
changed the title
Requires the access portal to be enabled or else it does nothing
I based my implementation on the official specs as well as code from GNOME, KDE, Xapp (Xfce), and Pantheon (elementary). KDE's immaculately readable codebase served as this implementation's primary inspiration.
Like KDE, I intend to show a dialog, so the user may choose whether to grant privileges to an application. I will also provide an option to bypass the dialog for greater choice especially considering that GNOME automatically grants permissions.
According to the docs, the Autostart method is deprecated. However, I think I still need to implement it because background requests aren't routed to the COSMIC portal unless it's available.Autostart is implementedCloses: #49