Control xdg-open/dbus with gtk2 application

Dear all,

Thank you for the great job you are doing supporting Snap technologies. It is a great job.

I’m an amateur packager of an application, which I like very much: WPS-Office. By doing so, I want to learn more about the technology underneath SNAP and Linux graphic interface.

This is a Chinese office, which works great on Linux. But since I’m a little cautious with confidentiality, I like to run it unplugged from the internet.

I’m working on Snapping the 2019 version of this software. I followed the doc for snapping a GTK2 application.

You can find the corresponding snapcraft.yaml here.

However, the package suffers from a certain number of problems I would like to fix, which are:

  • I can’t open an office document from Thunderbird of Firefox
  • WPS is a multi-tab program. When I launch 2 different documents from Nautilus, I would like a single copy of the program to be opened, with the two tabs inside, and not two copies of the program.

Playing with firejail containment, I observed I could mimic the same behavior depending if I grant access or not to the /tmp folder. Looking at snapcraft documentation, I noticed this is not possible with snap, but I have to use xdg-open-portal instead.

If I understood correctly, it seems that this functionality is implemented in the gnome-3-28 part. So I tried to use the gnome3 part in my snap. The corresponding snapcraft.yaml could be found in a separate branch of my github.

This approach does not work. When I do this, Snap call the executable file (I did put an echo in the beginning of the bash file to make sure it runs) but WPS is not launched (or crash) without any noticeable error. It just keep running and have to be interrupted with Ctrl+C.

I re-read the doc for gnome-3 and it says that it will not work if the application is GTK2.

I tried to play a bit with the dbus slots. But I have to say I don’t understand really how to use them, and the default commands I could find in some snapcraft.yaml does not seem to do the job.

Am I right to think the problems comes from a DBus or XDG-Open problem?
If yes, how to fix it?

Thank you very much for you help and the great job you do here.

First of all, if you are planning to publish a snap of someone else’s proprietary software, make sure you have permission to redistribute it. It doesn’t look like WPS Office’s EULA alone is sufficient for that.

For the Firefox/Thunderbird issue, /tmp is indeed the problem. Snaps are run with their own private /tmp. When Firefox offers to open a file when clicking on a link, it downloads the file to /tmp and passes that path to the associated application. Due to the private /tmp, the file path does not work within the snap’s sandbox. We don’t yet have a good solution working for this, and it isn’t something you can work around from within the sandbox.


Thank you for your quick reply.

As for the licence, you are right that the EULA licence is not clear.

Regarding the WPS Linux, the EULA Licence says that “You shall not transfer this Software or by any other means attempt to resell, relicense, lease or otherwise transfer the Software for any consideration”.

First, it mentions “transfer” the software, which is not clear because the appropriate word that would block me from Snaping the application is “redistribute”. “Transfer”, in my understanding, refers to a transfer of Licence, which I’m not doing, because the Snap follows the same licencing rules than the original freely downloadable .deb package. By caution, in order to avoid other vision of transfer, I did not put all the private executable in my GitHub, precaution that other packagers have not taken.

Second, WPS did made a Snap themself of the 2016 version but they stop maintaining it: . In a sense, I’m continuing the work they do.

As for the /tmp, what you says explain the behavior for opening from Thunderbird/Firefox/Chrome. I hope there will be a workaround for this soon…

Yet, it does not explain though the multitab/multi-instance behavior.
I expect once a Snap image is launched, if I open a second file in Nautilus, through whatever mean I do not know of, Nautilus will interrogate the /tmp of the already running Snap, and if it exists, it should open the new file within the same Snap instance. Instead, what I observe is that it do not check for a pre-existing Snap instance and run a new one.

Do you know a way of fixing this issue?

Thank you very much

Forbidding the transfer of copies seems fairly clear. And the fact that WPS has distributed their software as snaps in the past does not imply that a third party can do the same. I would suggest you get in contact with the developers before publishing your snap.

The method of fixing the problems with Firefox/Thunderbird is probably to improve snap run so that it can export inaccessible files via xdg-document-portal. That is something to do on the snapd side rather than individual snaps though.

I don’t have an answer about your multi-instance question. How does WPS-Office usually communicate with the existing instance if you run it a second time?

My understanding, based on my experience with firejail is this. Nautilus runs a new copy of the software each time, but when the new copy is ran, it checks the existence of an existing copy by looking at the /tmp. If there is one, it transfers the document to the already running instance and stop the new copy of the program.

This process is made impossible by snap because each /tmp is contained. Would you think it would be fixed by the same snap run fix?

Thank you very much for your help,


Nautilus would just be using the standard Freedesktop MIME Apps spec to decide how to launch the file. So this would depend on the .desktop file provided by WPS Office.

There’s basically two ways this could happen:

  1. If the .desktop file includes DBusActivatable=true, then the caller may decide to send a D-Bus method call to the bus name matching the ID of the desktop file. This relies on the D-Bus Activation feature from the Desktop Entry spec.

  2. The application listed in the Exec= line will check for an existing instance by some means, and ask that instance to open the document on its behalf.

At present, (1) does not work for snaps due to the way desktop files are named. However if WPS Office’s desktop file doesn’t include the DBusActivatable key, this doesn’t explain why it isn’t working.