Desktop integration and theme dependency

snapcraft
#1

I have a few questions about desktop and snap integration.

First, I need this integration due to the (Gnome) file picker dependency on gdk-pixbuf, when opening the file dialog the software crashes.

(e2-sat-editor:60006): Gtk-WARNING **: 14:00:33.759: Could not load a pixbuf from /org/gtk/libgtk/icons/16x16/status/image-missing.png.
This may indicate that pixbuf loaders or the mime database could not be found.
**

I’m trying extensions: [gnome] and it works as expected.

But the build time with snapcraft increases from ~15 minutes to over ~30 minutes. The log increases in size.

It also adds a dependency to the gnome-42-2204 snap.

I don’t remember if Kubuntu uses the KDE or Gnome file picker. :face_with_monocle: But if I want to support both Gnome and KDE, or whatever, in the same snapcraft.yaml, without making the build process too big?

In my opinion extensions: [gnome] is heavy, I tried to depend on gtk-common-themes this way, without success:

parts:
  e2-sat-editor:
    ...
    stage-snaps: [gtk-common-themes]
plugs:
  gtk-3-themes:
    interface: content
    target: $SNAP/share/themes
    default-provider: gtk-common-themes
  icon-themes:
    interface: content
    target: $SNAP/share/icons
    default-provider: gtk-common-themes
  sound-themes:
    interface: content
    target: $SNAP/share/sounds
    default-provider: gtk-common-themes

So, my software requires Qt6, but I need the file picker. No matter what DE you are using.

In my test system I installed xdg-desktop-portal-gtk, it seems not enough or not recognized in snap context, this for opening file picker.

I don’t want to remove the desktop file picker and put the Qt one instead.

Is there a smart way to get desktop integration?

#2

The gnome extension allows you all that you’ve added, but currently the kde-neon extension isn’t working properly. Both the extensions adds the dependency on the gtk-common-themes.

I have no idea about the coding required for file picker, though. But, to see what the extensions are doing, you can do,

snapcraft expand-extensions In that folder, where the snapcraft.yaml lies. Thanks.

1 Like
#3

Yes, I already tried snapcraft expand-extensions. I have seen that it adds a lot of environment variables.

I wonder if there is another way to achieve desktop integration, lightweight, without using extensions.

#4

gnome extension not only gives desktop integration but also dependencies that are necessary to run gnome apps. It’s possible, but if your app is a gnome app, this is recommended. You can try this,

But this is old, not able to find any latest one.

1 Like
#5

snapcraft-desktop-helpers are legacy tools that have been replaced by extension (gnome,flutter and kde-neon etc.)

#6

Even a modern snap like telegram uses it. Desktop helpers are the only way where you need to have classic confinement. The dev doesn’t want to use extensions, he’s anyway free to do so.

#7

I didnt even told you or the dev to not use it, what i mean is its better to refrain from using it since its no longer supported and is redundant and if someone is building a snap with latest core (telegram also uses core22) they should always use extension as snapcraft-desktop-helpers lacks theming integrations and also a lot of snap plug have to be manually added plus it also requires complex knowledge about the gui framework, not recommended for beginners plus devs who want to build snap with ease.

#8

What I meant is telegram is core22 and it doesn’t use extension.

#9

I know but see the unnecessary complexity that telegram faces to build it plus it doesnt even use the yaru-cursor etc. and by default use a foreign white cursor since it lacks integration provided by extensions ?? so its not recommended to use.

#10

You raised a bug, I guess. Cause. that shouldn’t be the case. It should’ve used the yaru-cursors. Black and beautiful. Can you show us some screenshots.

BTW, mine works completely fine on Ubuntu 23.04.

#11

I don’t know if the use of this extension is recommended or mandatory, surely there is a lack of support for Qt6.

I think that. A person using Kubuntu, an official flavour, would expect to find the KDE file picker, not the Gnome one. It would not be a real integration with the desktop, but an arrangement. This is whether you use Qt or not.

I don’t want to argue. My software requires Qt6, it shouldn’t depend on Gnome. If I add that extension, it creates a misunderstanding. Besides this misunderstanding installing my snap will install other snaps: gnome-44-2204 and gtk-common-themes. This might be right, if the official version of Ubuntu desktop uses that version of Gnome. But what I understand, these snaps should/could work on multiple distros and with multiple DEs. So I don’t know if this is right.

Everything works until you try to open or save a file.

Using that extension makes my software work, but it doesn’t make the software really integrated with a DE, not like you’d expect.

#12

Even if i ignore it as a bug,can you ignore the complexity of building the snap with such legacy tools ?? @ctlcltd Regarding qt6, surprisingly in flatpak kde is providing kf6 runtime even though its still in development phase this is validated by fact that the obs version of flatpak etc. uses kf6 runtime, @sgmoore Is there any plans for something similar for snaps, demand for qt6 is growing and there is actually kf6 runtime by kde for flatpak.

Edit: The Bug that i may have raised with telegram isnt reproducible with yaru although exists in case of breeze etc. atleast in lxqt/lubuntu.

#13

You can try with kf5, but as I have said before, it’s still buggy.

#14

Of course it is planned. When I (re) took over KDE snaps they were in bad shape and I have been working on getting them back in shape with the already stable kf5/qt5. Qt6/Kf6 developement will start soon ™

2 Likes
#15

@sgmoore On flatpak I’m using org.kde.Platform at version 6.4. When you read the yaml, the same misunderstanding arises. Though theme and file picker are showing correctly on Gnome, they come from Gnome.

@SamAlex Yes I read that, it is also specified in the documentation as “Qt5 and KDE Frameworks”. So I didn’t use it, not depending on the KDE framework.

I thought I’d support both Gnome and KDE without adding a ton of dependencies in snapcraft.yaml, but it’s hard :exploding_head:

I don’t know whether to put the Qt file picker at this point, the non-native built-in one. But then I would get the software with the style of Gnome or KDE, with a non-native file picker. It’s not nice.

Or I could disable native theme support and it would come out with Fusion style. It’s not nice.

I’ll think about it…

#16

Good to hear that, although i dont agree the kf5 snaps are super stable ? been building few qt5 apps few works but most break in several ways, also the kde runtime snap @ 102 gives error regarding improper naming plus the qt5 sdk used in builds have qtbase5-dev broken as i have to add it manually through jammy repos to build snaps, hope you will surely make building qt apps in snap at par with gnome apps in the near future, good luck…

#17

Well, one of the biggest problems is the kde-neon extension lags far behind the actual content pack release, despite my taking it over, it still suffers this. The latest content pack is kf5-5-105-qt-5-15-9-core22 A) I have to request global connect here on forums for tests to pass ( requirement for my PRs to get merged ) Last request took 12 days. And the PR still wasn’t merged for another week. B) Snapcraft has to release before the extension consumption will utilize the new content pack.

I get around this by building the extension myself and some well placed sed magic. This is an unreasonable expectation though for other users. I have brought up the issue several times and I do hope some light comes to the situation as it makes me look bad.

#18

Sad to hear that, these are some well known quirks of snap world that are yet to be addressed properly, hope these things things will be surely sorted in the future as honestly Qt integration in snaps currently is at very poor state, there are problems regarding theming and the ones previously mentioned etc. (Kde Snaps look good and work best only in Kde Plasma).

#19

I will install a non kde desktop and tackle these issues. I only took over fully a few months ago and they were in a much worse state. Thanks for understanding.

#20

I understand and am not in any sense blaming you, my proposed solution is that we should enforce somehow atleast on gtk based DEs QT_QPA_PLATFORMTHEME=gtk2 and also add the plugs in the yaml so that they automatically connect to gtk themes plug (currently they only use icon-theme-plug), this will make the kde/qt5 apps theme natively like gtk2 apps on these DEs(Dont know if kde respects this but smplayer,vlc etc. looks good as gtk2 ), this will atleast make them look native and look better same can be done for lxqt as it also lacks runtime to integrate such apps with it.

1 Like