Broken theming and missing icons on GTK file picker using kde-neon extension

snapcraft
1

Hi, I have a snap of a qt5 application, I was using the qt5 desktop helper but decided to switch to the kde-neon extension to reduce the size of the snap. However the kde-neon extension makes the app look like a KDE application even on GNOME. I’m able to make it look more at home on GNOME by setting QT_QPA_PLATFORMTHEME=gtk3, however the file picker falls back to the old adwaita theme and certain icons don’t render. I’ve tried using the desktop-helper script to see if it sets environment variables that may help with this, but I haven’t had any luck. Screenshot%20from%202020-07-18%2023-48-54

Snapcraft project: https://github.com/Nightmayr/dolphin-snap/tree/core18/snap

1 Like
2

The kde-neon extension does not appear to add a plug for gtk-3-themes, so the theme data necessary to style the dialog is not available.

Adding the plug to your snapcraft.yaml file directly might get things working the way you want:

plugs:
  gtk-3-themes:
    interface: content
    target: $SNAP/data-dir/themes
    default-provider: gtk-common-themes

Perhaps the extension should include this plug by default anyway, even though it is targeted at Qt apps?

1 Like
3

Hi @jamesh, I have the following plugs defined

plugs:
  gtk-3-themes:
    interface: content
    target: $SNAP/data-dir/themes
    default-provider: gtk-common-themes
  icon-themes:
    interface: content
    target: $SNAP/data-dir/icons
    default-provider: gtk-common-themes
  sound-themes:
    interface: content
    target: $SNAP/data-dir/sounds
    default-provider: gtk-common-themes

This seems to have improved the theming but the icons are still not rendering

Screenshot%20from%202020-07-19%2013-26-54

Edit: seems the icons are also not rendering in KDE either (should be folder icons next to folder names)

image

4

Hey @Nightmayr

Thanks for investigating this! I have a very similar issue with the Krita snap. I also think this should be part of the kde-neon extension. I can add it if we figure out how to get the icons working properly.

For reference; this is what it looks like in the keepassxc snap:image

This is what it looks like in your branch of the dolphin-emu snap:image

As you can see, most icons actually work. The icons which work are also the correct Yaru icons from the gtk-common-themes snap. This puzzles me a bit. In the past this has always been all-or-nothing; either a complete theme works or nothing works.

In addition, when I remove the dolphin-emulator snap completely and reinstall it, I get this error and a crash the first time when I run it.

(dolphin-emu:275781): GLib-GIO-WARNING **: 00:45:45.831: Error creating IO channel for /proc/self/mountinfo: Permission denied (g-file-error-quark, 2)

(dolphin-emu:275781): GdkPixbuf-WARNING **: 00:45:46.065: Cannot open pixbuf loader module file '/home/merlijn/snap/dolphin-emulator/common/.cache/gdk-pixbuf-loaders.cache': No such file or directory

This likely means that your installation is broken.
Try running the command
  gdk-pixbuf-query-loaders > /home/merlijn/snap/dolphin-emulator/common/.cache/gdk-pixbuf-loaders.cache
to make things work again for the time being.

(dolphin-emu:275781): Gtk-WARNING **: 00:45:46.065: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.

(dolphin-emu:275781): GdkPixbuf-WARNING **: 00:45:46.065: Cannot open pixbuf loader module file '/home/merlijn/snap/dolphin-emulator/common/.cache/gdk-pixbuf-loaders.cache': No such file or directory

This likely means that your installation is broken.
Try running the command
  gdk-pixbuf-query-loaders > /home/merlijn/snap/dolphin-emulator/common/.cache/gdk-pixbuf-loaders.cache
to make things work again for the time being.
**
Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /snap/dolphin-emulator/x1/data-dir/icons/Yaru/16x16/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
Aborted (core dumped)

However, when I run the snap for a second time, it actually works and doesn’t throw any errors about icons. :thinking: Is this just a one-time hiccup or is this related to our issue?

Maybe @jamesh has a better idea what might be happening here?

1 Like
5

Another observation: the icons also do not seem to be working in the Qt/KDE file picker (for example, on Kubuntu).

6

When I experimented with kde content snaps, I saw the same issue on 5.12 kde content snap, but didn’t see the issue with 5.14 kde content snap.

7

Hi @galgalesh, I can confirm I also experience the first time crash with my dolphin-emulator snap when I open up the file picker, I’m assuming it’s the final error that causes it to crash and it seems linked to being unable to locate the icons but not 100% sure. I’m totally stumped as to what’s causing this.

I gave @ilya-fedin’s suggestion about the qt 5.14 KDE content snap a go (https://github.com/Nightmayr/dolphin-snap/blob/core18-kf5-qt5.14/snap/snapcraft.yaml ). I expanded the kde-neon extension and replaced the default-provider to be the kde-frameworks-5-qt-5-14-core18 content snap, but I haven’t been successful in getting it to work. The created snap shows an error of being unable to locate shared libraries /snap/dolphin-emulator/x8/usr/local/bin/dolphin-emu: error while loading shared libraries: libQt5Widgets.so.5: cannot open shared object file: No such file or directory

It seems to just be the icons located in /usr/share/icons/Yaru/scalable, which aren’t able to be fetched from the gtk-common-themes content snap and rendered on GNOME. For KDE it’s unable to render any icons.

8

In my experiments the content snap didn’t reconnect automatically to the newer version for some reason, I had to reconnect manually

1 Like
9

And I used kf5-launch + desktop-launch in combine with the 5.14 content snap: https://github.com/KDE/snap-kf5-launcher
Usage example: https://packaging.neon.kde.org/kde/okular.git/tree/snapcraft.yaml?h=Neon/release#n112

1 Like
10

I did some experimenting with this a while ago. The desktop-launch script of the extension doesn’t support later kf5 snaps. I didn’t look further into why. Ideally, we can update the current desktop-launch script to support both the older and the newer content snaps, that way it’ll be easy to create an extension for the newer content snap.

(I don’t think it will be feasible to update the current kde-neon extension for the newer content snap without breaking some of the snaps out there, so creating a kde-neon-5-14 extension seems like the best solution imo)

11

My experiments with the 5.14 content snap haven’t been successful with GNOME. I get similar errors and warnings to the first time launch of my snap on the kde-neon extension, however this time the application will always crash whenever I attempt to use the gtk-file-picker.

(dolphin-emu:980563): GLib-GIO-WARNING **: 20:37:14.816: Error creating IO channel for /proc/self/mountinfo: Permission denied (g-file-error-quark, 2)

(dolphin-emu:980563): GdkPixbuf-WARNING **: 20:37:14.843: Cannot open pixbuf loader module file '/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory

This likely means that your installation is broken.
Try running the command
  gdk-pixbuf-query-loaders > /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.

(dolphin-emu:980563): Gtk-WARNING **: 20:37:14.843: 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.
**
Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/16x16/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
Aborted (core dumped)

Cursor themes on GNOME are also affected by this approach, the application falls back to the unstyled mouse cursor.

However the snap does now show icons in the KDE file-picker. I also get no first time launch crashes on KDE.

image

I pretty much copied the structure from the example provided by @ilya-fedin and make use of the kf5-launch script. I made sure to try enabling the content interfaces manually but still no luck on GNOME.

Snapcraft.yaml: https://github.com/Nightmayr/dolphin-snap/blob/56ffc60ca9523ba34e246e0a42d7fbce8788f475/snap/snapcraft.yaml

12

I used qgnomeplatform, not qt5-gtk-platformtheme, to build it myself and avoid incompatibility between the plugin (which compiled with Qt 5.9 in repos) and Qt from the content snap. However, I see that you install two copies of Qt: from content snap and from repos (i don’t think that this is a good idea).

2 Likes
13

Btw, some tdesktop users (I can’t reproduce this myself) have the same crashes even with pure core20 (without any content snap except gtk-common-themes) now: https://github.com/telegramdesktop/tdesktop/issues/8252

And I have no idea what can cause it

14

Some of my testing with krita:

  • When I install the regular krita snap built using kde-neon extension, disconnect the older content snap and connect it to kde-frameworks-5-qt-5-14-core18-sdk, the icons are fixed! So krita can use the newer content snap and the gtk3 platform theme without installing any “qt gtk platform” packages and without using kf5-launch.

I’m guessing the issues of @Nightmayr are because of including multiple qt versions in the snap itself and because of using kf5-launch. desktop-launch tries hard to ignore Qt libraries in the snap itself and prefers qt libraries in the content snap. kf5-launch tries to also use Qt libraries in the snap, which might be incompatible if those were installed using apt.

  • I went through the entire kf5-launcher and compared with desktop-launch from the kde-neon extension and the only extra useful thing kf5-launcher does is add "$SNAP_DESKTOP_RUNTIME/usr/sbin" to the path. However, the Krita snap works perfectly without that. I think desktop-launch is a safer choice because it does a whole bunch of extra stuff and tries to ignore the Qt libraries from the snap itself, which is useful if the snap isn’t completely “clean”.
15

I’m going to bed now. I hope I can work some more on it tomorrow, but I finally figured out why the kde-frameworks snaps also seem to include a (slightly worse) GTK3 platform theme. I found 4 themes in total being used by different snaps:

  1. gtk3: Default theme for Qt apps on Linux, integrates with the current GTK 3 theme, uses the correct icon set. Part of upstream Qt but as an optional plugin. Requires the GTK 3 libraries.

  2. QGnomeTheme: Fallback default theme for Qt apps on Linux in case the “gtk3” platform theme plugin is not found, use of Adwaita icon set is hardcoded in the theme. Works without gtk3 libraries.

  3. QGnomePlatform: Newer GTK 3 theme created by Fedora devs. Supports deeper integration than the “gtk3” theme. Requires the GTK 3 libraries.

  4. KDEPlatformTheme: KDE theme created by KDE devs. Default theme for snaps using kde-neon extension because the desktop-helpers fallback to this theme when QT_QPA_PLATFORMTHEME is unset.

Only 2. and 4. are included in the kde-frameworks content snaps.

  • When QT_QPA_PLATFORMTHEME is unset, desktop-helpers will fallback to kde (KDEPlatformTheme).
  • When QT_QPA_PLATFORMTHEME is set to an invalid version, Qt will fallback to “QGnomeTheme” because “gtk3” is not included in the kde-frameworks content snaps.

So during your testing, if you suddenly see the application is using the Adwaita icons instead of the Suru/Yaru icons on default Ubuntu, it means Qt falled back to QGnomeTheme. This is what is happening in the Krita snap currently.

I think for the extension, we should build QGnomePlatform, include it in the snap, and configure desktop-helpers to use QGnomePlatform when running on a GTK based desktop. Ideally, the kde-frameworks content snap will include the QGnomePlatform plugin in the future.

1 Like
16

Two comments:

1 Like
17

If this were the case, his screenshot would have a qt dialog, but his screenshot have the gtk dialog. Even more, in my experiments with the 5.12 content snap & QGnomePlatform I have seen the same issue. And icons doesn’t render in both kde&gtk dialogs. If an app uses system icons - then the app itself doesn’t render them too. I.e. looks like something wrong with some library that is used by both gtk&qt to render icons in the 5.12 content snap, maybe some svg library? :thinking:

18

I think I’ve found the cause of the missing icons. I decided to compare the yuzu snap (a snap I currently maintain) which uses the desktop-qt5 helper, with dolphin-emulator using the kde-neon extension (with qgnomeplatform included). The difference I identified was in the gdk-pixbuf-loaders.cache file in XDG_CACHE_HOME. dolphin-emulator was missing these lines:

"/snap/yuzu/54/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so"
"svg" 6 "gdk-pixbuf" "Scalable Vector Graphics" "LGPL"
"image/svg+xml" "image/svg" "image/svg-xml" "image/vnd.adobe.svg+xml" "text/xml-svg" "image/svg+xml-compressed" ""
"svg" "svgz" "svg.gz" ""
" <svg" "*    " 100
" <!DOCTYPE svg" "*             " 100

I added this block to dolphin-emulator's version of the file (changing the path to /snap/dolphin-emulator/x2/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so), which had the result of rendering the missing icons. I have confirmed this also works with the qt5-gtk-platformtheme package included instead of qgnomeplatform.

I’ve tried to investigate further by looking at the desktop-launch script from the kde-neon extension to figure out how the file was getting created. This is the logic responsible for creating the file

export GDK_PIXBUF_MODULE_FILE="$XDG_CACHE_HOME/gdk-pixbuf-loaders.cache"
export GDK_PIXBUF_MODULEDIR="$SNAP_DESKTOP_RUNTIME/usr/lib/$ARCH/gdk-pixbuf-2.0/2.10.0/loaders"
if [ "$needs_update" = true ] || [ ! -f "$GDK_PIXBUF_MODULE_FILE" ]; then
  rm -f "$GDK_PIXBUF_MODULE_FILE"
  if [ -f "$SNAP_DESKTOP_RUNTIME/usr/lib/$ARCH/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders" ]; then
    async_exec "$SNAP_DESKTOP_RUNTIME/usr/lib/$ARCH/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders" > "$GDK_PIXBUF_MODULE_FILE"
  fi
fi

Where SNAP_DESKTOP_RUNTIME=$SNAP/kf5 (entry point for the kde-frameworks-5-core18 content snap). Running the /snap/kde-frameworks-5-core18/current/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders binary did generate the file with the SVG block present, but when I execute the same command after I run snap run --shell dolphin-emulator.dolphin-emu the SVG block is not present. This is the diff between these two files:

5c5
< # LoaderDir = /snap/dolphin-emulator/x2/kf5/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders
---
> # LoaderDir = /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders
7c7,14
< "/snap/dolphin-emulator/x2/kf5/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ani.so"
---
> "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/io-wmf.so"
> "wmf" 0 "gdk-pixbuf" "Windows Metafile" ""
> "image/x-wmf" ""
> "wmf" "apm" ""
> "\327\315\306\232" "" 100
> "\001" "" 100
> 
> "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ani.so"
13c20
< "/snap/dolphin-emulator/x2/kf5/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-bmp.so"
---
> "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-bmp.so"
19c26
< "/snap/dolphin-emulator/x2/kf5/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-gif.so"
---
> "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-gif.so"
25c32
< "/snap/dolphin-emulator/x2/kf5/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-icns.so"
---
> "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-icns.so"
31c38
< "/snap/dolphin-emulator/x2/kf5/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ico.so"
---
> "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ico.so"
38c45
< "/snap/dolphin-emulator/x2/kf5/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so"
---
> "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so"
44c51
< "/snap/dolphin-emulator/x2/kf5/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so"
---
> "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so"
50c57
< "/snap/dolphin-emulator/x2/kf5/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-pnm.so"
---
> "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-pnm.so"
61c68
< "/snap/dolphin-emulator/x2/kf5/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-qtif.so"
---
> "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-qtif.so"
68c75,82
< "/snap/dolphin-emulator/x2/kf5/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tga.so"
---
> "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so"
> "svg" 6 "gdk-pixbuf" "Scalable Vector Graphics" "LGPL"
> "image/svg+xml" "image/svg" "image/svg-xml" "image/vnd.adobe.svg+xml" "text/xml-svg" "image/svg+xml-compressed" ""
> "svg" "svgz" "svg.gz" ""
> " <svg" "*    " 100
> " <!DOCTYPE svg" "*             " 100
> 
> "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tga.so"
79c93
< "/snap/dolphin-emulator/x2/kf5/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tiff.so"
---
> "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tiff.so"
87c101
< "/snap/dolphin-emulator/x2/kf5/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xbm.so"
---
> "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xbm.so"
94c108
< "/snap/dolphin-emulator/x2/kf5/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so"
---
> "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so"

I’m not sure what causes the difference in output between my host machine and the snap container, I’m assuming this is a problem with the content snap itself? Hopefully this is helpful in figuring out the solution.

UPDATE: I listed the contents of the modules present in the loaders directory of the kde-frameworks-5-core18 snap and can confirm the SVG module is not present (the same is also true for the kde-frameworks-5-qt-5-14-core18 snap)

$ ls /snap/kde-frameworks-5-core18/current/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/
libpixbufloader-ani.so   libpixbufloader-ico.so   libpixbufloader-qtif.so  libpixbufloader-xpm.so
libpixbufloader-bmp.so   libpixbufloader-jpeg.so  libpixbufloader-tga.so
libpixbufloader-gif.so   libpixbufloader-png.so   libpixbufloader-tiff.so
libpixbufloader-icns.so  libpixbufloader-pnm.so   libpixbufloader-xbm.so

I believe the librsvg2-2 package is responsible for this module, would it just be a case of bundling this into the content snap if it’s not already present?

3 Likes