Qt5.12 QDesktopServices::openUrl not working

Hi…
I created a Snap for a Desktop application running with Qt 5.12.1.
I cannot find what’s missing to let DekstopServices::openUrl work.
Here is the staging end plugs of my yaml:

stage-packages:
      - libssl-dev
      - xdg-user-dirs
      - libgl1-mesa-glx
      - libgl1-mesa-dri
      - libegl1-mesa
      - libxcursor1
      - libnss3
      - libxcomposite1
      - libxi6
      - libxtst6
      - libasound2
      - ttf-ubuntu-font-family
      - dmz-cursor-theme
      - shared-mime-info
      - libxkbcommon0
      - libxkbcommon-x11-0
      - light-themes
      - zlib1g
      - dbus
      - dbus-x11

plugs:
      - home
      - x11
      - unity7
      - wayland
      - desktop
      - desktop-legacy
      - opengl
      - removable-media
      - network
      - network-bind
      - network-manager
      - network-control
      - alsa
      - cups-control
      - gsettings

Do you use Qt libraries from the system? Or are you using an already build app?

No, I don’t use the libraries from the system. I include them in the package.

What happens when you try to open a URL? Can you snap install snappy-debug and then snappy-debug.security scanlog in a terminal before launching your application. Perhaps some output will give us a clue?

Could show your yaml file?

That’s the problem: snappy-debug says nothing.
In Qt 5.12 they changed the code of QDesktopServices, instead of xdg-open now they use QDBusMessage.

Here is the snapcraft.yaml file

name: xxx
summary: an app using Qt 5.12.1 
description: Still under construction
confinement: strict
grade: stable
version: latest

architectures:
  - build-on: amd64
  - build-on: i386

parts:
  xxx:
    plugin: dump
    after: [desktop-glib-only]
    source: /home/me/progr/build
    stage-packages:
      - libssl-dev
      - xdg-user-dirs
      - libgl1-mesa-glx
      - libgl1-mesa-dri
      - libegl1-mesa
      - libxcursor1
      - libnss3
      - libxcomposite1
      - libxi6
      - libxtst6
      - libasound2
      - ttf-ubuntu-font-family
      - dmz-cursor-theme
      - shared-mime-info
      - libxkbcommon0
      - libxkbcommon-x11-0
      - light-themes
      - zlib1g
    override-pull: |
      snapcraftctl pull
    override-build: |
      snapcraftctl build
    build-attributes: [no-system-libraries]
apps:
  xxx:
    environment:
      PATH: $PATH:$SNAP/bin
#      QT_DEBUG_PLUGINS: 1
      LD_LIBRARY_PATH: $SNAP/usr/lib:$LD_LIBRARY_PATH
      QML_IMPORT_PATH: $SNAP/usr/qml
      QML2_IMPORT_PATH: $SNAP/usr/qml
      QT_QPA_PLATFORM_PLUGIN_PATH: $SNAP/usr/plugins
      QT_QPA_PLATFORMTHEME: qt5ct
    command: desktop-launch $SNAP/usr/bin/xxx
    desktop: xxx.desktop
    plugs:
      - home
      - x11
      - unity7
      - wayland
      - desktop
      - desktop-legacy
      - opengl
      - removable-media
      - network
      - network-bind
      - network-manager
      - network-control
      - alsa
      - cups-control
      - gsettings

I managed to get some debug info. I get the following message:

QDBusError(“org.freedesktop.DBus.Error.ServiceUnknown”, “The name org.freedesktop.portal.Desktop was not provided by any .service files”)

Oh! They’ve adopted the freedesktop portal spec? That’s interesting. We have a https://snapcraft.io/portal-test snap (whose snapcraft.yaml can be found on github).

The “Links” section does what you’re after. I wonder if there’s something you can learn from that yaml?

Just for the record, is the xdg-desktop-portal package installed in the host filesystem?

It does not really help… I think something is missing in the stage-packages, do you have any hints about how to find out the right packages?

This error indicates your app is trying to access the desktop portal, probably to call the OpenURI method. For this to work, there needs to be a xdg-desktop-portal program running as part of your user session. When your snap applcation has to use the desktop plug, it will be allowed to access the interface of the desktop portal.

In your case, I think the problem is that the portal is not running, and could not have been started by dbus activation. Maybe looking at the user journal could help, see journalctl --user could help. Also check ps -ef|grep xdg-desktop.

IIRC, some frameworks implement a fallback mechanism that calls xdg-open. Perhaps Qt does not.

2 Likes

Uhm… this sounds like “a lot of additional stuff to do” that I really don’t want to do…
I probably have better time to replace QDesktopServices::openUrl with os::system(“xdg-open url”)

I wonder if we could teach userd to handle this name in case there is no real document portal around. I worry that people will end up patching their snaps because one of the main frameworks did something without a good fallback.