Wondering if anyone has some ideas. I made this snap of OpenTaxSolver (/otax) with build linked against gh repo (shrmpy/ots)
When printing the PDF, the error appears about the PDF VIEWER (no gui_settings.conf). It then falls back to xdg-open, but that fails.
This is the latest in a series of side quests. To get to this point, started from the GTK app guide and then I needed to work out the following:
Unfortunately I can only add that I gave up on opening files using the associated program from the snap as though I found the docs about xdg-open (or I believe I found), and thus tried running it from the recommended path, it didn’t work out. I found bigger fish to fry first but on one hand thanks for being reminded and bringing the topic up…!
As part of snapd’s security system, each snap is isolated from the rest of the system in a sandbox. This is why you can’t see other applications.
The main method allowed to start other applications is the /usr/bin/xdg-open program provided within the sandbox. This provides the same interface you’d be used to, but is implemented as a small proxy that asks a service outside the sandbox to open the associated application. Some things to keep in mind though:
If you pass it an http://… URL, it will probably just open the user’s web browser. If you want file type specific behaviour, you’ll probably have to download the file yourself and then call xdg-open on it.
With the current version of snapd, there are restrictions on what other URI schemes are supported. If you try to open a magnet: URI, it will return an error rather than launching Transmission. These restrictions will be relaxed a bit when snapd 2.45 is released, provided you have xdg-desktop-portal installed.
That is good info. I can search what it is passing to xdg-open, and see whether it resembles a URL. I appreciate the new lead.
I had hit a wall like Monday morning, and brain just went blank.
Well, thanks a lot for the feedback, wasn’t sure if it’s of any use.
I must admit I didn’t get much more clever in this matter by now
As I understand there’s some ongoing progress in terms of interaction between snapped apps, e.g.:
Additionally I accidentally found that Qt’s QImage might be able to load from PDF’s too - if I’m right! saw that with only one eye and about 10 days ago due to a file filter I had incorrectly set up - although I believe I only saw the first page?
Looks like you have a very helpful app there by the way, congrats - I might end up being your user someday… =b
Note that the upcoming deskop-launch interface is not intended for general use by applications, and it is unlikely that your snap will be granted auto-connect if it isn’t a desktop shell or application launcher.
If the aim is to open a PDF file that the snap can read in the system’s default PDF viewer, /usr/bin/xdg-open should do the trick. If you are using the GLib/GTK API for launching the default handler for a file, try adding the following to your snapcraft.yaml:
So I’m embarrassed. It wasn’t even creating the PDF at the time. It expects a subdir of files in src/formdata where the “src” path is prepended in the code. I noticed this after seeing it has -verbose and -debug switches. After including these files, it can create a PDF file. Still fails to launch a PDF viewer, but I can continue to learn about snap universe gradually and experiment on the weekends
