Only one QObject can be registered on a DBus path...but that object can have
multiple adaptors, which is how you've structured it anyway.
It's considerably easier than doing everything manually through a
QDBusVirtualObject
Details
Details
- Reviewers
jgrulich - Group Reviewers
Plasma - Commits
- R838:45843db8d63a: Massively simplify the class DesktopPortal
Checked all ifaces registered in qdbusviewer
Manually ran AddNotification, debug appeared in xdg-desktop-portal and a notification appeared
I haven't actually tested inside flatpak.
Diff Detail
Diff Detail
- Repository
- R838 Flatpak Support: KDE Portal for XDG Desktop
- Branch
- master
- Lint
No Linters Available - Unit
No Unit Test Coverage
| src/access.h | ||
|---|---|---|
| 32 | explicit (and others) | |
Comment Actions
I tested it with my test application and it doesn't work. I keep getting following warnings from xdg-desktop-portal:
- (/usr/libexec/xdg-desktop-portal:18253): WARNING **: Backend call failed: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such method 'OpenFile' in interface 'org.freedesktop.impl.portal.FileChooser' at object path '/org/freedesktop/portal/desktop' (signature 'osssa{sv}')
Terminated
I checked it and all services seems to be registered properly, but don't know why it doesn't work. Reverting this change makes it immediately working. Also please look into Inhibit.cpp where I also register dbus objects, will this still work?
Comment Actions
I think I found out why. In documentation [1] all methods starts with capital letter, which in our case they don't. This was obviously working before when I was doing everything manually. Still my question remains about registering additional objects in Inbit.cpp.
Edit: if you decided to rename all methods, you will have to probably rename all classes as well, because some method names are identical to class name so it will be considered as a contructor.
[1] - http://flatpak.org/xdg-desktop-portal/portal-docs.html
Comment Actions
Inhibit should be the same as that uses the virtual object from request.cpp which I haven't touched.
Comment Actions
Ok, I'll test that later. Can you please rename all portals? I would propose renaming all (Access, AppChooser, FileChooser ....) to (AccessPortal, AppChooserPortal, FileChooserPortal ...) so we can rename all methods to start with a capital letter. Then it should magically work.
Btw. thank you for this change, I had hard times at the very beginning to make all interfaces registered under one dbus path.
Comment Actions
Awesome!! I've tested all portals and they do work. Thanks a lot.
Btw. next time if you would like to test portals you can use my test application https://github.com/grulja/flatpak-portal-test-kde. You just need to go to flatpak-build directory and run build.sh. Then import the repo to flatpak and run the app.