Hi, i made a content snap here with desktop-qt5 run-time dumped in it here
And an app to use the content snap , app running fine the only issue is widget style looks too old like in screenshot below:
here is the snapcraft.yaml of app that uses the content snap mentioned above
However, to be clear: as far as I know gtk-common-themes is not used to theme the qt widgets. It can only be used for the cursor and icon themes [*]. You still need a qt theme present in order to properly style the qt widgets and you need to tell qt to use that theme.
If the libs aren’t in a place where desktop-launch expects them, that is likely your problem. I’d say either desktop-launch should add additional paths to search or the content snap should adjust the paths to a more standard location.
I’d also recommend using a similar naming convention as we do for the GNOME content snaps. gnome-3-26-1604 includes libs from gnome 3.26 built on 16.04 (core) and gnome-3-28-1804 includes libs from gnome 3.28 built on 18.04 (core18). These help snap packagers know which content snap and base to use together.
i have all libs in place, and all path corrected, i am basically using desktop-qt5 helper with little modification to desktop-launch which i shipped with consumer snap to point and take libs from content snap.
Thanks, one question - how to use desktop-launch in consumer snap, cause there is no desktop-launch script in my consumer snap, content snap is mounted at qt551 in my consumer snap…
You cannot directly execute an app command that is external to your snap, if that’s what you’re asking.
i.e. : command: $SNAP/qt551/bin/desktop-launch test
This is because the app command specified must be present in the snap at final priming.
What you could do is provide a dummy desktop-launch script within the consumer snaps under the same location (/bin) and have that script call into the content snap, BUT (as I see you’ve already experienced), desktop-launch makes use of a few environment variables to locate its dependancies, which would now be pointing to the consumer rather than the content.
What you’ve done by modifying the desktop-launch to point to the content snap may actually be the cleanest solution here. Though one major advantage to the dummy script of course is that any changes to desktop-launch need only be made in one place for all consumers to benefit.
i modified desktop-launch from content snap to set env_vars from content snap, and shipped it with consumer snap. app launching fine with qt’s own theme fusion, but using gtk file dialog box to select files.
The simple reality is that we’re entering somewhat uncharted territory here. You may know more about this than we (or certainly I) do at this point.
This situation where a desktop-launch script is provided by one common content snap is something we definitely see as being useful, but unfortunately have just not carved out the time for yet.
Making content snap for apps runtime is good practice for developers, this will help me reduce size of all my qt apps who uses same dependencies. with that in mind i decided to do this test. the main issue is desktop-launch script that comes with default desktop-qt5 that thing is not made to be used as content snap,(by looking at the env_vars set in launcher script). shipping my own desktop-launch which point to content snap mount point within my app snap made the trick for now.
this is bit messy . hehe