flatpak/libportal

libportal - Flatpak portal library

libportal - Flatpak portal library

libportal provides GIO-style async APIs for most Flatpak portals. You can find the documentation here.

Getting started

libportal uses Meson to build its projects. To install Meson on your system, follow the Getting Meson instructions. If your system is missing a dependency, Meson will tell you which one. How you install your missing dependencies is up to you.

Build libportal

The first time you build libportal, give meson a directory to build into; we recommend _build:

meson _build

Then use ninja to build the project, pointing it to your build directory:

ninja -C _build

For subsequent builds, you only need to use the ninja -C _build command.

Passing options

libportal includes Meson build options for components that can optionally be built. Run meson configure to see all available options or, after first running meson _build, view available options and their current values with:

meson configure _build

To change an option, re-configure the project:

meson configure _build -Dportal-tests=true

You can also pass in options right from the start, e.g. with:

meson _build -Dportal-tests=true

Then build:

ninja -C _build

Optional components

portal-tests

To generate test binaries, set the portal-tests option to true, e.g. -Dportal-tests=true, to build the portal tests for the backend built. Then run the desired test binary, e.g.:

./_build/portal-test/gtk3/portal-test-gtk3

or

./_build/portal-test/qt5/portal-test-qt5

libportal's Issues

Add qt support

Similar to the inline functions in portal-gtk3.h and portal-gtk4.h, we should have a portal-qt.h header.

Screencast fails on KDE

Screencast fails on KDE.

"Failed to create screencast session: CreateSession failed"

Is this because KDE service isn't running?

/usr/libexec/xdg-desktop-portal-kde
xdp-kde: Failed to register org.freedesktop.impl.portal.desktop.kde service

sudo /usr/libexec/xdg-desktop-portal-kde
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

I guess this is an issue for xdg-desktop-portal-kde.

API/ABI stability undefined and unclear

There is no documentation about API and ABI stability of libdecor. According to @GeorgesStavracas it's unstable and unsuitable for use outside of Flatpak, but the fact is that it's packaged in distributions, and used by applications packaged in traditional distributions. Distributions need some level of stability, e.g. compatible ABI version in the library name etc. If there is none, and libportal starts breaking ABI, things like nautilus can no longer use libportal, since it'll likely for the foreseeable future still be packaged in distributions.

Are there any examples avaliable?

I want to try to integrate some portals into https://github.com/fyne-io/fyne and do so over D-bus to avoid the need to call into C. I can't seem to find any examples of how to use it, neither using D-bus or when using the library. I think it would be very good to create examples here.

Add device access to portal-test

It would be great to be able to test the org.freedesktop.portal.Device portal using the portal-test app. This seems not to be integrated right now - are there any plans to do so? Or did I miss something?

Wrong types used in SaveFile() method from FileChooser portal

In xdp_portal_save_file() users are expected to pass current_folder and current_file as strings and they seem to be passed to the xdg-desktop-portal that way as well, but the portal expects them as byte array. You can see in documentation [1] that "ay" is expected. This results into failure when doing this call.

[1] - https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.FileChooser.xml#L213

Add compatibility with Thunderbird to send emails with attachment

Today, Thunderbird can't send an email with an attachment using libportal. GNOME Files in the newest version (43, still in beta) can send emails directly from context menu, that is, they incorporated the nautilus-sendto extension.
They use libportal, but libportal doesn't work well when I need to attach a file and I'm using Thunderbird.
I checked and xdg-email utility, from package xdg-utils, has some checks to use Thunderbird correctly. The idea is to implement to libportal too.

document glib mainloop dependency

We use GTask internally, and that depends on a running mainloop (otherwise cleanup never happens, and memory is leaked).

We should document this clearly.

location portal's location-updated signal is never emited

In the following code, the callbacks for location-updated are never executed, and the monitor does start correctly. Also reproducible on vala

        # ...
        window.present()

        portal = Xdp.Portal()
        parent = XdpGtk4.parent_new_gtk(window)

        time_threshold = 100
        distance_threshold = 100
        time_threshold = 100
        accuracy = Xdp.LocationAccuracy.CITY
        flags = Xdp.LocationMonitorFlags.NONE
        cancellable = None

        portal.connect("location-updated", (lambda x: print("Location updated")))
        portal.location_monitor_start(
            parent,
            distance_threshold,
            time_threshold,
            accuracy,
            flags,
            cancellable,
            cb,
        )
        
        # ...
     def cb(portal, result):
        try:
            re = portal.location_monitor_start_finish(result)
            print("Portal started:", re)
        except Exception as err: 
            print(err)

Add LICENSE or COPYING file

Would be very useful for packages, see https://bugzilla.redhat.com/show_bug.cgi?id=1782122

meson.build:22:1: ERRORL Dependency "qt5" not found, tried pkgconfig and config-tool

How do I fix the qt5 dependency not being found? On arch linux. Log attached
meson-log.txt

Generate vapi file

To have vala bindings.

Global shortcut implementations

Are there any plans to add the global shortcut? I saw it has been added to xdg-desktop-portal, and such a feature truly would be a life saver

Report error instead of aborting when g_bus_get_sync fails

In xdp_portal_init, the g_bus_get_sync can fail if a system has not properly set up DBUS. Instead of aborting, it would be nice if there was a way for the application to detect/handle this error, for example, reporting to the user that DBUS may not have been configured/setup properly.

It seems the reason for calling "abort" here could be because the Glib "init" hook doesn't provide a way to report an error? Maybe we'd have to add a function to check for errors on an XdpPortal object after it has been initialized?

Consider relicensing to LGPL or MIT

So that proprietary applications can link libportal and use all the goodness of this fantastic platform.

This will require explicit approval from:

• ✔ @GeorgesStavracas
• ✔ @grulja
• ✔ @hadess
• ✔@jtojnar
• ✔@matthiasclasen
• ✔@mjog
• ✔ @smcv
• ✔ @TingPing

libportal should treat file URIs as paths inside the sandbox namespace

We can pass multiple types of uri parameter to xdp_portal_set_wallpaper:

1. an URL to a location on internet. for example https://avatars2.githubusercontent.com/u/48521955?s=60&v=4 which is my avatar icon. This works.
2. a file:/// URI of a file available inside the sandbox

However, the third point doesn't work. If I pass a file:/// URI, it thinks it is outside the sandbox and doesn't find it and if I pass a filename (/tmp/app111/image.png), there is the loading spinner forever but the image can't be set as wallpaper nor does it appear in the preview window.

This is reproducable by applying this patch to a clean master tree (with the path changed to an image installed in the sandbox) and run PortalTest:

diff --git a/portal-test/portal-test-win.c b/portal-test/portal-test-win.c
index 9f07b38..bd0ec8e 100644
--- a/portal-test/portal-test-win.c
+++ b/portal-test/portal-test-win.c
@@ -1161,8 +1161,10 @@ static void
 set_wallpaper (PortalTestWin *win)
 {
   XdpParent *parent;
-//  const char *uri = "https://gitlab.gnome.org/GNOME/gtk/raw/master/demos/gtk-demo/portland-rose.jpg";
-  const char *uri = "file:///usr/share/backgrounds/gnome/adwaita-morning.jpg";
+  /* const char *uri = "https://gitlab.gnome.org/GNOME/gtk/raw/master/demos/gtk-demo/portland-rose.jpg"; */
+  /* const char *uri = "file:///usr/share/backgrounds/gnome/adwaita-morning.jpg"; */
+  const char *uri = "file:///my_path/in_sandbox/to_the/image.png";
+  g_assert (g_file_test (uri, G_FILE_TEST_EXISTS));
 
   parent = xdp_parent_new_gtk (GTK_WINDOW (win));
   xdp_portal_set_wallpaper (win->portal,

This currently blocks my MR for GNOME Web for the time being.

I hope it can be fixed.

Edited to clarify, following mcatanzaro message.

Install dependencies

It would help to have a dependency list in the getting started section. I managed to compile a list for some distros:

Ubuntu:

sudo apt install build-essential
sudo apt install meson cmake libglib2.0-dev libgstreamer-plugins-base1.0-dev libgirepository1.0-dev valac libgtk-3-dev libgtk-4-dev qtbase5-dev libqt5x11extras5-dev
sudo apt install python3-pip
pip install jinja2 markdown markupsafe pygments toml typogrify

OpenSUSE:

sudo zypper install --type pattern devel_basis
sudo zypper install meson cmake glib2-devel gstreamer-plugins-base-devel libgobject-2_0-0 gobject-introspection-devel vala gtk3-devel gtk4-devel libqt5-qtbase-devel
sudo zypper install python3-pip
pip install jinja2 markdown markupsafe pygments toml typogrify

Fedora:

sudo dnf install make automake gcc gcc-c++
sudo dnf install meson cmake glib2-dev gstreamer1-plugins-base-devel gobject-introspection-devel vala gtk3-devel gtk4-devel qt5-qtbase-devel qt5-qtx11extras-devel
sudo dnf install python3-pip
pip install jinja2 markdown markupsafe pygments toml typogrify

No API to create persistent RemoteDesktop sessions

Required for input-leap/input-leap#1699 - if the screensaver kicks in the RemoteDesktop Session is closed. For InputLeap we want to reconnect when it's available again, but that requires restoring the session.

xdp_portal_create_remote_desktop_session() doesn't allow the persist mode and restore token like xdp_portal_create_screencast_session() does, we'll need some new API here.

Redundant parameter in SaveFiles() method from FileChooser portal

In xdp_portal_save_files() users might pass current_name parameter, but this one is not mentioned in xdg-desktop-portal documentation and doesn't seem to make sense in this call as you are saving multiple files at once.

Test suite fails with dbusmock 0.30.0 or leaks multiple dbus-daemon instances with older versions

Originally reported in a Debian QA rebuild as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058245.

To reproduce

Be in a container (pid namespace) where no unwanted dbus-daemon processes are running. (I used a podman container with no dbus-daemon processes at all, but it's OK if the "real" system, session and/or AT-SPI buses are already running.)

Build libportal, then run:

xvfb-run -a -s "-noreset" \
env LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 \
meson test --timeout-multiplier 3 -C obj-x86_64-linux-gnu/

where obj-x86_64-linux-gnu/ is the build directory. (This is how the Debian packaging runs the test suite.)

Expected result

Tests pass. No libportal-related dbus-daemon processes remain running (it's OK if the system, session and/or AT-SPI buses are still running from before).

Actual result with python3-dbusmock 0.29.1-2

The tests pass, but 27 dbus-daemon processes are still running afterwards:

$ pgrep dbus-daem|xargs ps
    PID TTY      STAT   TIME COMMAND
  11681 ?        Ss     0:00 dbus-daemon --fork --print-address=1 --print-pid=1 --config-file=/tmp/dbusmock_data_4t6qy
  11688 ?        Ss     0:00 dbus-daemon --fork --print-address=1 --print-pid=1 --config-file=/tmp/dbusmock_data_4t6qy
...
  11792 ?        Ss     0:00 dbus-daemon --fork --print-address=1 --print-pid=1 --config-file=/tmp/dbusmock_data_81inv
  11796 ?        Ss     0:00 dbus-daemon --fork --print-address=1 --print-pid=1 --config-file=/tmp/dbusmock_data_81inv

Actual result with python3-dbusmock 0.30.0-2

The tests fail, with a dbusmock assertion failure:

____________________ TestRemoteDesktop.test_connect_to_eis _____________________

self = <pyportaltest.test_remotedesktop.TestRemoteDesktop testMethod=test_connect_to_eis>

    def test_connect_to_eis(self):
      setup = self.create_session(start_session=True)

pyportaltest/test_remotedesktop.py:428: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
pyportaltest/test_remotedesktop.py:62: in create_session
    self.setup_daemon(params=params, extra_templates=extra_templates)
pyportaltest/__init__.py:99: in setup_daemon
    self.start_session_bus()
/usr/lib/python3/dist-packages/dbusmock/testcase.py:296: in start_session_bus
    cls.__start_bus('session')
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

cls = <class 'pyportaltest.test_remotedesktop.TestRemoteDesktop'>
bus_type = 'session'

    @classmethod
    def __start_bus(cls, bus_type) -> None:
        bustype = BusType(bus_type)
        old_pid = getattr(DBusTestCase, f"{bustype.value}_bus_pid")
>       assert old_pid is None, f"PID {old_pid} still alive?"
E       AssertionError: PID 3954437 still alive?

/usr/lib/python3/dist-packages/dbusmock/testcase.py:284: AssertionError

Root cause

It appears that dbusmock starts and stops temporary session buses on a per-class basis (they're stopped in tearDownClass()) rather than on a per-test-case basis (they are not stopped in tearDown()). In older versions, starting more than one session bus per DBusTestCase subclass would result in only the last session bus being torn down, with all of the others being leaked. In newer versions, there's an assertion to stop that from happening, so the tests will now just fail.

Make bindable -gtk3 and -gtk4 libraries

While the inline header trick is cute, we should probably just install separate .so s for the benefit of bindings

Unable to link

So I have a very minimal source file and Makefile, but I keep getting errors when linking and I'm not entirely sure why
this is my capture.c:

#include <libportal/portal.h>
int main(int argc, char* argv[]) {
    XdpPortal *portal = xdp_portal_new ();
    return 0;
}

And here is my makefile:

CFILES := capture.c
CFLAGS := `pkg-config --libs --cflags glib-2.0`

build:
	gcc ${CFILES} ${CFLAGS} -o capture

And here is the error when I try to compile this

gcc capture.c `pkg-config --libs --cflags glib-2.0` -o capture
/sbin/ld: /tmp/cccGe8I9.o: in function `main':
capture.c:(.text+0x10): undefined reference to `xdp_portal_new'
collect2: error: ld returned 1 exit status
make: *** [Makefile:5: build] Error 1

Here's the output I got after compiling it without linking and then running ld --verbose capture:
https://pastebin.com/39LSPby0

I've tried using meson as well, but I have no experience with it so I couldn't fix an issue where it wouldn't find gio/gio.h
And even after manually running the build command with the necessary gio stuff included it only created 2 object files which I cant do a whole lot with.

0.6: test suite is failing with SIGABRT

Looks like test suite is failing with SIGABRT

+ cd libportal-0.6
+ /usr/bin/meson test -C x86_64-redhat-linux-gnu --num-processes 48 --print-errorlogs
ninja: Entering directory `/home/tkloczko/rpmbuild/BUILD/libportal-0.6/x86_64-redhat-linux-gnu'
ninja: no work to do.
1/1 Qt unit test        FAIL            0.23s   killed by signal 6 SIGABRT
>>> MALLOC_PERTURB_=44 /home/tkloczko/rpmbuild/BUILD/libportal-0.6/x86_64-redhat-linux-gnu/tests/qt5/qt-test


Summary of Failures:

1/1 Qt unit test FAIL            0.23s   killed by signal 6 SIGABRT


Ok:                 0
Expected Fail:      0
Fail:               1
Unexpected Pass:    0
Skipped:            0
Timeout:            0

Full log written to /home/tkloczko/rpmbuild/BUILD/libportal-0.6/x86_64-redhat-linux-gnu/meson-logs/testlog.txt

Specify GLib minimum version

I couldn't build it on elementary 5.1 because g_hash_table_steal_extended is missing, it has been added in GLib 2.58 so it might be reasonable to specify 2.58 as the minimal supported version

Improve documentation for Session.pointer_button()

On https://libportal.org/method.Session.pointer_button.html, the parameters section lists the button parameter as being an int with no further details.

However, as per https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html#org-freedesktop-portal-remotedesktop-notifypointerbutton, the button should be a linux evdev code. This should be mentioned in the documentation.

most inputcapture tests failing - dbusmock assert on trying to spawn a server for an already taken name

I made PR #140 based on the clue that calling setup_daemon twice was the issue.

One of the 13 tests that fails output is:

=================================== FAILURES ===================================
_______________________ TestInputCapture.test_activated ________________________

self = <pyportaltest.test_inputcapture.TestInputCapture testMethod=test_activated>

    def test_activated(self):
        """
        Test the Activated signal
        """
        params = {
            "eis-serial": 123,
            "activated-after": 20,
            "activated-barrier": 1,
            "activated-position": (10.0, 20.0),
            "deactivated-after": 20,
            "deactivated-position": (20.0, 30.0),
        }
        self.setup_daemon(params)
    
>       setup = self.create_session_with_barriers(params)

pyportaltest/test_inputcapture.py:481: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
pyportaltest/test_inputcapture.py:59: in create_session_with_barriers
    self.setup_daemon(params)
pyportaltest/__init__.py:108: in setup_daemon
    self.p_mock, self.obj_portal = self.spawn_server_template(
/usr/lib/python3/dist-packages/dbusmock/testcase.py:438: in spawn_server_template
    server = SpawnedMock.spawn_with_template(template, parameters, bustype, stdout, stderr=None)
/usr/lib/python3/dist-packages/dbusmock/testcase.py:614: in spawn_with_template
    server = SpawnedMock.spawn_for_name(module.BUS_NAME, module.MAIN_OBJ, interface_name, bustype, stdout, stderr)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

cls = <class 'dbusmock.testcase.SpawnedMock'>
name = 'org.freedesktop.portal.Desktop'
path = '/org/freedesktop/portal/desktop'
interface = 'org.freedesktop.portal.InputCapture'
bustype = <BusType.SESSION: 'session'>, stdout = -1, stderr = None

    @classmethod
    def spawn_for_name(
        cls,
        name: str,
        path: str,
        interface: str,
        bustype: BusType = BusType.SESSION,
        stdout=subprocess.PIPE,
        stderr=subprocess.PIPE,
    ) -> "SpawnedMock":
        """Run a DBusMockObject instance in a separate process
    
        The daemon will terminate automatically when the D-Bus that it connects
        to goes down.  If that does not happen (e. g. you test on the actual
        system/session bus), you need to kill it manually.
    
        This function blocks until the spawned DBusMockObject is ready and
        listening on the bus.
    
        By default, stdout and stderr of the spawned process is available via the
        SpawnedMock.stdout and SpawnedMock.stderr properties on the returned object.
        """
        argv = [sys.executable, "-m", "dbusmock", f"--{bustype.value}", name, path, interface]
        bus = bustype.get_connection()
        if bus.name_has_owner(name):
>           raise AssertionError(f"Trying to spawn a server for name {name} but it is already owned!")
E           AssertionError: Trying to spawn a server for name org.freedesktop.portal.Desktop but it is already owned!

/usr/lib/python3/dist-packages/dbusmock/testcase.py:559: AssertionError
----------------------------- Captured stdout call -----------------------------
signal time=1705154704.643778 sender=org.freedesktop.DBus -> destination=:1.3 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.3"
signal time=1705154704.643832 sender=org.freedesktop.DBus -> destination=:1.3 serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost
   string ":1.3"
method call time=1705154704.645333 sender=:1.4 -> destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello
method return time=1705154704.645357 sender=org.freedesktop.DBus -> destination=:1.4 serial=1 reply_serial=1
   string ":1.4"
signal time=1705154704.645372 sender=org.freedesktop.DBus -> destination=(null destination) serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.4"
   string ""
   string ":1.4"
signal time=1705154704.645396 sender=org.freedesktop.DBus -> destination=:1.4 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.4"
method call time=1705154704.645496 sender=:1.4 -> destination=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameHasOwner
   string "org.freedesktop.portal.Desktop"
method return time=1705154704.645514 sender=org.freedesktop.DBus -> destination=:1.4 serial=3 reply_serial=2
   boolean true
----------------------------- Captured stderr call -----------------------------
DEBUG | templates.inputcapture: Loading parameters: dbus.Dictionary({dbus.String('eis-serial'): dbus.Int32(123, variant_level=1), dbus.String('activated-after'): dbus.Int32(20, variant_level=1), dbus.String('activated-barrier'): dbus.Int32(1, variant_level=1), dbus.String('activated-position'): dbus.Struct((dbus.Double(10.0), dbus.Double(20.0)), signature=None, variant_level=1), dbus.String('deactivated-after'): dbus.Int32(20, variant_level=1), dbus.String('deactivated-position'): dbus.Struct((dbus.Double(20.0), dbus.Double(30.0)), signature=None, variant_level=1)}, signature=dbus.Signature('sv'))
dbus-daemon[27162]: [session uid=1000 pid=27162] Connection :1.3 (uid=1000 pid=27178 comm="dbus-monitor --session") became a monitor.
dbus-daemon[27162]: [session uid=1000 pid=27162] Monitoring connection :1.3 closed.

XdpPortal:update-progress never called on update

When using the update portal, it is expected that "update-progress" signal is emitted occasionally with status. I don't seem to be getting any calls there during the update which makes progress state look a bit weird in Builder.

Generate .gir file

This would make it easier to generate bindings for the library.

Qt 6.5+ does support xdg-foreign

The comment says TODO: QtWayland doesn't support xdg-foreign protocol yet but that's not quite true (moreover, QTBUG-76983 is closed as a duplicate while QTBUG-73801 is about importing a parent, not exporting). Qt 6.5 supports xdg-foreign, it's just there's no public API yet (although I'm not sure they will ever make it public, that's not something regular applications are supposed to use I guess). It could be accessed in such way:

	if (const auto services = dynamic_cast<QGenericUnixServices*>(
			QGuiApplicationPrivate::platformIntegration()->services())) {
		handle = g_strdup(services->portalWindowIdentifier(w).toUtf8().constData());
	}

The API prefixes the handle with x11:/wayland: doing actually all the _xdp_parent_export_qt's job.
The following includes are needed:

#include <qpa/qplatformintegration.h>
#include <private/qguiapplication_p.h>
#include <private/qgenericunixservices_p.h>

And a #if QT_VERSION >= QT_VERSION_CHECK(6, 5, 0) check perhaps.

Another way is to support xdg-foreign manually with libwayland-client + a custom wl_registry instance using wl_display from qApp->nativeInterface<QNativeInterface::QWaylandApplication>()->display() (6.5+) or reinterpret_cast<wl_display*>(QGuiApplication::platformNativeInterface()->nativeResourceForIntegration(QByteArray("wl_display"))) (5.4.0+ or if replacing "wl_display" with "display" then 5.0.0+). QGuiApplication::platformNativeInterface needs a #include <qpa/qplatformnativeinterface.h>.

Document how to view the docs

As someone not super familiar with the glib/GNOME software ecosystem, it is not clear to me how the docs in doc/ are meant to be viewed. It would be nice to have at the very least a brief explanation for what tool to use, or such. I tried using gnome-help, but it tells me "The file ‘/mnt/storage/Programming/libportal/doc/libportal.xml’ could not be parsed because one or more of its included files is not a well-formed XML document.", so I suppose I'm doing something wrong.

correct way to include headers is ambiguous

Are users of libportal meant to #include <libportal/portal.h> or #include <portal.h>?

If the former, then @includedir@ in the pkg-config file should probably be set to "${prefix}/" + get_option("includedir"), i.e. normally /usr/include, so that if the user has installed libportal in (for example) /opt/flatpak-stuff, they will get the correct -I/opt/flatpak-stuff/include to be able to use #include <libportal/portal.h> without error. It would probably also be a good idea for cross-inclusions between headers to use the format #include "account.h" or #include <libportal/account.h>, to avoid accidentally including a header like /usr/include/account.h if some other package includes that header.

Or, if the latter, then the headers should probably be renamed to something less namespace-polluting, for example portal-account.h instead of account.h.

Add file transfer

This is a new feature of the document portal; we should support it here

Use of deprecated `gdk_wayland_toplevel_unexport_handle`

Building libportal 0.7.1 with the nightly Gnome Flatpak SDK issues this warning:

[27/34] Compiling C object libportal/libportal-gtk4.so.1.0.0.p/portal-gtk4.c.o
../libportal/portal-gtk4.c: In function ‘_xdp_parent_unexport_gtk’:
../libportal/portal-gtk4.c:81:7: warning: ‘gdk_wayland_toplevel_unexport_handle’ is deprecated: Use 'gdk_wayland_toplevel_drop_exported_handle' instead [-Wdeprecated-declarations]
   81 |       gdk_wayland_toplevel_unexport_handle (GDK_TOPLEVEL (surface));
      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/gtk-4.0/gdk/wayland/gdkwayland.h:38,
                 from ../libportal/portal-gtk4.c:29:
/usr/include/gtk-4.0/gdk/wayland/gdkwaylandtoplevel.h:56:26: note: declared here
   56 | void                     gdk_wayland_toplevel_unexport_handle (GdkToplevel *toplevel);
      |                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Location of the call: https://github.com/flatpak/libportal/blob/main/libportal/portal-gtk4.c#L81

Build Configuration

========================================================================
Building module libportal in /var/home/sebastian/git/gtg/.flatpak-builder/build/libportal-1
========================================================================
The Meson build system
Version: 1.4.0
Source dir: /run/build/libportal
Build dir: /run/build/libportal/_flatpak_build
Build type: native build
Project name: libportal
Project version: 0.7.1
C compiler for the host machine: ccache cc (gcc 13.2.0 "cc (GCC) 13.2.0")
C linker for the host machine: cc ld.bfd 2.42
Host machine cpu family: x86_64
Host machine cpu: x86_64
Compiler for C supports arguments -Wno-unused-parameter: YES 
Compiler for C supports arguments -Wno-missing-field-initializers: YES 
Compiler for C supports arguments -fvisibility=hidden: YES 
Has header "sys/vfs.h" : YES 
Configuring config.h using configuration
Found pkg-config: YES (/usr/bin/pkg-config) 2.2.0
Build-time dependency glib-2.0 found: YES 2.81.0
Program /usr/bin/glib-mkenums found: YES (/usr/bin/glib-mkenums)
Dependency glib-2.0 found: YES 2.81.0 (cached)
Program /usr/bin/glib-mkenums found: YES (/usr/bin/glib-mkenums)
Run-time dependency gio-2.0 found: YES 2.81.0
Run-time dependency gio-unix-2.0 found: YES 2.81.0
Run-time dependency gobject-introspection-1.0 found: YES 1.80.2
Dependency gobject-introspection-1.0 found: YES 1.80.2 (cached)
Program /usr/bin/g-ir-scanner found: YES (/usr/bin/g-ir-scanner)
Dependency gobject-introspection-1.0 found: YES 1.80.2 (cached)
Program /usr/bin/g-ir-compiler found: YES (/usr/bin/g-ir-compiler)
Program vapigen found: YES (/usr/bin/vapigen)
Dependency gtk+-3.0 skipped: feature backend-gtk3 disabled
Run-time dependency gtk4 found: YES 4.15.1
Program vapigen found: YES (/usr/bin/vapigen)
Compiler for language cpp skipped: feature backend-qt5 disabled
Dependency qt5 (modules: Core, Gui, X11Extras, Widgets) skipped: feature backend-qt5 disabled
Build targets in project: 10

libportal 0.7.1

  Backends
    enabled backends: gtk4

  User defined options
    prefix          : /app
    backend-gtk3    : disabled
    backend-gtk4    : enabled
    backend-qt5     : disabled
    docs            : false
    tests           : false

Put libportal-gtk3/4 in a different namespace than libportal.

Every library should have its own unique namespace, so it can be addressed only with this namespace.
libportal-gtk3 should also have namespace version 3 and -gtk4 version4. And to have the gtk version numbers independent from the rest of libportal, they need to be in different namespaces.

How to detect the state of autostart background in libportal?

Hello everyone.

Through libportal we can request to enable autostart for a specific app. But how can we check if the autostart is enabled for the same app?

Is there a specific method or process to detect it? I don't see any function to get it and even Gnome ToDo that implements this service is using a gsettings key to track the state rather than ask to libportal, which is not really ideal.

Am I missing something or this is not possible?

Omit qt / qt5 while compiling?

Hey guys,

I am trying to compile libportal right now.

It tells me this though:

"qmake found: NO need ['>= 5', '< 6']"
"Run-time dependency qt5 (modules: Core, Gui, Widgets, X11Extras) found: NO (tried pkgconfig and config-tool)"

I tried to compile qt5 with the kde dev patchsets, but had a problem with wayland so I gave up for now.

I need libportal for nautilus and evince eventually. Is there a flag to skip building qt? If there is, would
it be possible to mention it in the main README briefly? Perhaps a new entry right in the existing
"Passing options" would suffice. I am not that familiar with meson and I am not sure how the equivalent
to "./configure --help" goes with meson. Thanks for reading either way.

PS: Indepedent of this, perhaps qt5 should not be a fail-error but just a warning. I believe libportal
can work fine without qt but for some reason it aborts right now since I have no qt installed. I think
the better default would be to continue building, UNLESS qt is mandatory for libportal.

Is the API/ABI stable?

Has libportal reached a point where its API and ABI are stable, in the sense that incompatible changes would result in a SONAME bump to libportal.so.1, as is done in e.g. libhandy, libdazzle and libflatpak?

I'm asking because there were API breaks between 0.2 and 0.3, and as a result, at the moment it's only in Debian experimental, which is appropriate for a library that isn't yet stable (although Ubuntu developers seem to have added it to the package set for Ubuntu 20.10 anyway).

If I put it in Debian testing/unstable where it will become part of Debian 11, then I can use it to get better test coverage in xdg-desktop-portal (and to make it easier to build Flatpak runtimes out of Debian packages), but that comes with higher expectations in terms of not breaking the ABI.

Pin a new release

Hello,

i am the maintainer of flowtime (github) on Alpine Linux. It also depends on libportal. Unfortunately it uses features, that are not available in v0.6 of libportal.

Would it be possible to bundle ready made changes over the last year and a half into a new release?

Thank you very much!

Qt5 tests require specific environment

The Qt5 tests were run when compiling the libportal RPM, but the tests don't set up their own environment, which means they're bound to fail when, say, a D-Bus daemon, or a display isn't available.

The tests should be self-standing and be runnable without further configuration from the caller. That would also mean that the tests could be run in the GitHub CI, which they currently aren't.

Test running in koji:

+ cd libportal-0.6
+ /usr/bin/meson test -C redhat-linux-build --num-processes 6 --print-errorlogs
ninja: Entering directory `/builddir/build/BUILD/libportal-0.6/redhat-linux-build'
ninja: no work to do.
1/1 Qt unit test FAIL            0.35s   killed by signal 6 SIGABRT
>>> MALLOC_PERTURB_=130 /builddir/build/BUILD/libportal-0.6/redhat-linux-build/tests/qt5/qt-test
Summary of Failures:
1/1 Qt unit test FAIL            0.35s   killed by signal 6 SIGABRT
Ok:                 0   
Expected Fail:      0   
Fail:               1   
Unexpected Pass:    0   
Skipped:            0   
Timeout:            0   
Full log written to /builddir/build/BUILD/libportal-0.6/redhat-linux-build/meson-logs/testlog.txt

CC @grulja

Full log