Graphical snaps don't honour the desktop theme

Bug #1585332 reported by Bruno Nova on 2016-05-24
662
This bug affects 145 people
Affects Status Importance Assigned to Milestone
Snappy
Undecided
Unassigned
snapd
Wishlist
Unassigned
snapd (Arch Linux)
New
Undecided
Unassigned
snapd (Ubuntu)
Undecided
Unassigned

Bug Description

Confined graphical GTK & Qt applications do not use the user-selected or default theme of the end-user desktop outside Ubuntu.

# Expected behaviour

Graphical snaps should seamlessly integrate with the desktop, using theme, font and other visual preferences selected by the user.

# Actual behaviour

Outside Ubuntu proper, applications look un-themed. They don't match other applications on the same desktop which are not snapped. Applications look like 'Windows 95' (or worse) and are thus not appealing to use.

# Steps to reproduce

1. Install a recent one of the following systems:-

Debian Squeeze, Ubuntu MATE, Solus Budgie, Fedora 27
(The above is by no means an exhaustive list of affected systems. Essentially install anything that isn't "Ubuntu Proper")

2. Enable snap support if not already enabled, as per https://docs.snapcraft.io/core/install

3. Install a graphical application such as the gimp from the archive

e.g. apt install gimp, dnf install gimp, eopkg install gimp

4. Install the same graphical application from the snap store

e.g. sudo snap install gimp

4. Run both instances of the application

e.g. /usr/bin/gimp && snap run gimp

5. Compare the look and feel of each set of windows.

Bonus: Change the theme on your install and observe the archive-installed application change look, and the snap one not to.

Attached are example screenshots.

Gustavo Niemeyer (niemeyer) wrote :

Agreed. Let's get that fixed somehow.

tags: added: snap-desktop-issue
Sebastien Bacher (seb128) wrote :

GTK theming is currently unstable and their css handling is changing between series so using the system theme wouldn't work great in practice, a snap of a GTK > 3.19 software wouldn't look right on an host using GTK 3.18

Options:
- use the host theme via an interface, but then you get the issue if the GTK versions mismatch

- have applications to bundle and force one theme, but the result is that they would not look integrated to the desktop environment they are used on

- have applications to bundle themes for the different desktops and somewhat smart select the one to use ... that's probably not something an upstream wants to have to do since it would require to keep up with the envs existing out there and what theme they use

- invent a smart theme interface where you get a snap with a collection of themes and the one shared with your snap is selected somehow depending on the toolkit (+version) and desktop theme you are using

- other?

I think ideally we need the smartness, unsure how it could work exactly though

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in snapd (Ubuntu):
status: New → Confirmed
Ahmed Hamdy (a7med7amdy3iad) wrote :

This is how inkscape 0.92 appear in KDE neon 5.8.5

drwt (6lobe) on 2017-04-11
Changed in snappy:
status: New → Confirmed
Matej Moško (gnaag) wrote :

Since gtk 3.20 is considered stable. Is it possible to use system theme now?

hackel (hackel) wrote :

This is a serious limitation of the platform. Particularly with the upcoming move to gnome-shell, even the window decorations aren't going to match.

Owais Lone (loneowais) wrote :

Does anyone know how flatpack solves this or does this issue not affect flatpack at all?

Jamie Strandboge (jdstrand) wrote :

@Owais, this used to affect flatpak but they recently solved it. I brought this up to Zygmunt and we discussed it. The current thinking is listed here: https://forum.snapcraft.io/t/use-the-system-gtk-theme/496/8.

I suggest tracking/participating in that forum post.

Seth Arnold (seth-arnold) wrote :

Here's a quick sketch of flatpak's solution for themes https://tingping.github.io/2017/05/11/flatpak-theming.html

I understand this to mean flatpak allows paks to depend upon other paks. Perhaps I've misread it.

Thanks

KAYOver (sziberov) wrote :

Why we cannot implement some GTK3 version checker for snap apps and host? Then if snap's GTK3 ver equals to host's one use systemwide theme, in another case use preinstalled with snapd Adwaita or anything else.

description: updated
summary: - Graphical snaps don't follow the window theme
+ Graphical snaps don't honour the desktop theme
petersaints (petersaints) wrote :

Why is the theme correctly picked on Ubuntu (both Xenial, Bionic and I've also tested on Artful) but it fails under other Ubuntu official flavors? What is missing? It should be an easy fix, at least on GTK+-based DE's (maybe a little harder on Kubuntu).

Balint Reczey (rbalint) wrote :

IMO detecting dark/light theme from the desktop would solve the most annoying usability problem and can be solved by snapping two theme variants.

Matching the exact widget set versions of the system may not be important and even be less appealing than bundling for example newer GTK themes assuming snaps are heavily used for backporting and newer bundled themes look more modern/look simply better. Showing the newer theme could be seen as demoing the new look.

Just my 2 cents.

Any progress on this? even flatpak respects my system theme, please respond.

Mark Dammer (mark-dammer) wrote :

Please fix ASAP: Ubuntu is often praised for "Accessibility". "Honouring" dark themes is an absolute MUST for this. I have an eye condition where it is recommended to use a dark desktop theme in order to put less light stress on the retina.

ajmannen (andreas1300) wrote :

Please prioritize this, I cannot recommend that any one uses snaps or even Ubuntu with Ubuntu software store until this is resolved.

Anthony Jackson (arjackson54) wrote :

As a note to testers concerning this issue - as observed on 18.04LTS Ubuntu, on ubuntu-session the snaps only follow the installed theme if it is one of the themes preinstalled or from base repos; ie Adwaita(/dark) Ambience or Radiance etc. User installed themes from other repos, in my case Adapta from ppa:tista/adapta, are not applied to snap apps.

Example : https://imgur.com/a/jVBrUre

This is not a uniform bug. Chromium for instance on snap does find the titlebar theme, but not the mouse theme. Gnome Calculator as seen above finds only default theme, but keeps the user choice of mouse pointer just fine.

Anthony Jackson (arjackson54) wrote :

Small addition to #24 :
It seems not all Canonnical repo themes work after all, Numix is an example of the same issue as the example screenshot. Also the colour of a theme for the window backgrounds is not always carried across to snaps even though the window decorations and mouse pointer theme are.

Grey Seeker (greyseek3r) wrote :

Seriously guys, this isn't that hard to fix.
A change can be made to the theming structure so that all GTK+ config files in each snap directory are linked to the user's to honor the theme. It doesn't even require each snap to be written differently. Just put it in the guidelines for developers to follow. In the meantime a separate snap daemon can be written to scan for independent GTK config files in snap directories and link them to the user's.

Daniel Flaum (daniel-flaum) wrote :

I'm on Fedora 30 here in May 2019, and this bug dismays me. From my reading of the comments so far, the only problem with the solution in #26 is that Snap applications may expect a different version of the user's GTK theme than is installed.

Version mismatches may not be easy to fix--I don't know, I'm an outsider--but surely it's easy to detect them? With that, can't the solution in #26 be implemented so that it solves this bug at least for some users?

Fredrik (fredrk) wrote :

I get wrong mouse pointer in some snap apps but not all. Chromium and robo3t has wrong pointer, IntelliJ IDEA has the correct one.
Any way to fix this?

Zygmunt Krynicki (zyga) wrote :

This is an umbrella bug for many efforts that build towards having much better support for theming. As one example we recently landed support for icon themes. This will also improve the support for mouse cursor icons. I switched the priority to wishlist because it's not a bug, it's a lot of new functionality for us to implement.

Changed in snapd:
status: New → Triaged
importance: Undecided → Wishlist
Norbert Klár (klarnorbert) wrote :

You know, we know what are your guys trying to do here with snap and we really appreciate, but look at this way: I was really happy with Kubuntu 19.04(I could finally achieve uniform look for all apps, Qt and GTK), but after moving to 19.10, some packages only available from snap, and those are looks like crap, because it doesn't use themes that I set in KDE settings for GTK applications.

This feature was requested back in 2016, and still nothing.

John Lenton (chipaca) wrote :

@Norbert, which snaps? I've only heard about electron snaps losing some themeing in 19.10 (unrelated to snap vs non-snap afaik).

Norbert Klár (klarnorbert) wrote :

Robo 3T and Chromium for example.

Norbert Klár (klarnorbert) wrote :

Robo 3T only using theme's(Arc theme in my case) titlebar, and Chromium(v77) using the fallback cursor theme.

Norbert Klár (klarnorbert) wrote :

So this is how it looks after updating Kubuntu to 19.10. Both Robo 3T and Postman's theme messed up, and they're only using Arc's titlebar. Screenshot added.

Removing them, and using installer from their website fixes the issue.

Ferry Toth (ftoth) wrote :

As a user I am experiencing 0 advantage from chromium packaged as a snap. Except that it looks ugly.

Did I somehow miss the good stuff?

Eric Adams (esa1975) wrote :

I'm trying to be optimistic about this and realize that it is a solution for maintaining packages across multiple releases but I have to say that as more and more things are migrated to snap without a solution to these integration issues it will become a real problem for many more users and hence, the Ubuntu team itself. Yes, the issues are larger on non-GTK DEs so mainly Kubuntu and Lubuntu but it will have a downstream effect as well. I can only assume this is a complicated problem or it would have been solved long ago. Regardless, it seems like this warrants some focus sooner than later. I apologize if this post isn't seen as contributing to the issue but I thought I'd add my viewpoint as a long-time Kubuntu user.

Kanehekili (jentiger-moratai) wrote :

snap is a another way to hurt the linux desktop experience. It is a shame watching developers rendering linux unusable/ugly again. I've spend some time creating new themes (noting that its documentation is very bad)just to see that it will not be honored by snap packages. Sorry not to be constructive, but this flaw has been known for about 4 years and nobody seems to care.
It is hard to explain an former windows user why some of his apps look different (i.e you can see if it is a snap or deb package) from others.

Erich Eickmeyer (eeickmeyer) wrote :

I'd like to point-out that this bug seems to be affecting the snap-store snap in bug #1867417. I have filed a bug already to get Materia included in gtk-common-themes (default theme in Ubuntu Studio) but nobody seems to care.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers