-
-
Notifications
You must be signed in to change notification settings - Fork 267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optional support for new xdg background portal #535
Comments
At least at compile time it is possible to check if it is available as they use pkg-config. I have no idea about runtime. And I also have no idea about how to use it. I think I will need to see a code example. |
These are the places where changes have to be made https://github.com/wwmm/pulseeffects/blob/8e95621d6e11a0376b04e12beed7402e942c5db9/src/general_settings_ui.cpp#L140 and https://github.com/wwmm/pulseeffects/blob/8e95621d6e11a0376b04e12beed7402e942c5db9/src/general_settings_ui.cpp#L124. When we find out how to use this portal it is only a matter of using a preprocessor |
Sorry for confusing things. Just to clarify xdg-desktop-portal is a host dependency, not a bundled depedency. It is a dependency of Flatpak itself as you can see with I will try to find some example though. |
Surely a compile time check would be worthless since we build it once an re-use it it on all distributions, which again might not have Edit: Oh and the these portal interfaces are all DBus API:s, so I am pretty sure I caused a major misunderstanding here. |
Maybe we are not even supposed to compile PE with it. Maybe its pkg-config file is meant to be used when flatpak is compiled. I don't know. Assuming everything can be done through DBUS we could use GLIBMM wrappers for DBUS as it is already done for realtimekit. When we find a code example things will be more clear. |
Yes, that is what I failed to convey. You are meant to install this as a regular distribution package, before you can install flatpak apps. It is of course not compiled by us, but as a dependency of Flatpak. Bundling this would be like bundling core gnome desktop components. I should have mentioned that these were DBus API:s from the beginning. Back to searching for that example then. |
Not sure if it is enough but I found this in the mailing list. Unfortunately the example is not for this particular portal. I thought I would post this just in case.
Substitute data-collect-app with pulseeffects |
I'm hoping we can resurrect this old issue and perhaps finally close flathub/com.github.wwmm.pulseeffects#18. Since this was first posted things have developed. We now have
We can still do this, now with That said, I do think it should be enabled by default, when the dependency is found. Portals do work outside of flatpaks and sometimes bring the advantage of desktop integrations and a more uniform user experience. If that leads to issues, you can always change it later on. Unfortunately I still can't find any app that uses the background portal specifically, nor any code example. That made things even harder when I tried to implement this myself. I ultimately failed, due to my lacking programming skills, but it does seem like a simple job if you know what you're doing. Other apps that uses this library (other portals though) can be found in the "Required by" section at packages.archlinux.org. Documentation ships with the library in the form of gtk-doc generated html. I will be available for testing and anything else you might need me for. |
I have been a little busy but I will try to remember to take a look at this in the next days. |
I tried to follow what is done in this link https://github.com/flatpak/xdg-desktop-portal/blob/669e91c2774850944ac8f11881de4bd69831c182/tests/background.c#L67 but it does not even compile:
I don't know what I am missing... |
Just including the header is enough to have a failed compilation. Even with |
Then it would seem you came as far as I did. I too never figured out that error and I just assumed it was due to my own inexperience. At least, now I don't feel as stupid :| I will see if I can get some answers and get back to you. |
Ok, I'd like to try to get this working because it is still useful for EasyEffects in Flatpak. One detail which is somewhat new: apparently for the most part libportal/xdg desktop portals shouldn't be used for non-sandboxed apps flatpak/libportal#33. So libportal should probably be an optional dependency for now. I am really not sure how exactly an implementation should work, I am not very good at programming nor am I very familar with how portals work. But I will try. Do you remember what you tried to do here? #535 (comment). Maybe I can try to redo that now. |
Unless they decide to support non sandboxed apps it will have to be an optional dependency forever.
I couldn't even try to do something. Just including the library header was enough to get a compilation error. |
Yeah, I do think eventually that will change, but who knows...
Do you remember what file needed the header? I'd probably need to include libportal in the right meson.build file too right? I can try to build it locally and see what happens. |
Probably this one https://github.com/wwmm/easyeffects/blob/master/include/general_settings_ui.hpp as this is the class handling the autostart switch. |
Ok, I seem to be able to get it to build with the background portal header. #1115 I'll try to actually get it to do something useful later. |
Hi, libportal maintainer. Portals are supposed to work both inside and outside any kind of sandbox. libportal is still maturing up, but it is very unlikely that the background portal API will change. You are encouraged to include libportal in your Flatpak manifest, pointing to whatever commit or tag works. If anything changes, we will bump the libportal version. |
Thanks Georges! I do recall someone said on Matrix the background portal specifically might not work in host? But there's a tool to check so I guess I'll try that later. (edit: for reference, tool is: https://github.com/bilelmoussaoui/ashpd/tree/master/ashpd-demo) Ultimately it will be up to @wwmm to decide if EasyEffects should depend on libportal and use the background portal on non-sandboxed packages. I of course would ideally like it to as I like portals :) It will probably help that EasyEffects only has usable packages on distros like Arch or other rolling ones, so I think recent libportal exists there. |
Interesting. @GeorgesStavracas is there an example somewhere showing how to use libportal to autostart an app in the user login? We are considering using libportal because flatpak apps can not write to
Considering how often our flatpak is used I do not mind adding libportal as dependency. I am more concerned about how hard it is to use it for what we need. |
Yup, there's a plugin for GNOME To Do that does just that. You can check it here. The key part of it is that GTK4 apps must include |
I see in To Do there is:
Is there any point to have this, which compiled here: #1115?
|
No big point, just me being overly explicit with the includes 🙂 |
So for now the Flatpak will be patched to use libportal in the next Flathub release. This is mostly due to flatpak/xdg-desktop-portal#579. Because of that portal issue the background portal doesn't work properly on the host, so it means two codepaths would need to be maintained which is sub optimal. See #1141 for more discussion. |
The flatpak build has been using libportal for a while. We can close this issue. |
Thanks to a new portal interface (org.freedesktop.impl.portal.Background) it should now be possible to solve this old issue: flathub/com.github.wwmm.pulseeffects#18
In time this should ideally be used everywhere, whenever possible. It does however add a dependency on
xdg-desktop-portal >= 1.4.0
, which means distributions providing older versions is the primary reason it can't always be relied upon at this time.Would it be possible to check for the availability of this DBus API at runtime and if available use that instead of writing
pulseeffects-service.desktop
directly?I am no expert but if you need any more information or assistance I will try my best to provide it.
The text was updated successfully, but these errors were encountered: