Use the system gtk theme

Lets say that we have a gtktheme snap containing the user’s selected theme exported via content interface, and a gtkapp snap that plugs into it. Now lets add a second user to the system, who goes ahead and changes to a different theme. What now?

  • Do we disconnect and reconnect the plugs on all installed apps each time someone logs in? (what about multi-seat when multiple users are logged in simultaneously?)
  • Do we require all available themes to be packaged in a single snap? (how do theme authors get their theme added to this snap?)

The extension point idea effectively changes from a many-to-one connection strategy to many-to-many. So all snaps that are interested in GTK themes would see data from all installed snaps that provide GTK themes.

This could potentially be modelled as a many-to-one relationship plus a one-to-many one through an intermediate snap (e.g. the GNOME platform snap), with the help of some kind of “reverse content interface” where the plug snaps provide content to the slot snap, but that has its own problems:

  1. snaps have independent mount namespaces, so creating mounts within the GNOME platform snap won’t make content visible to other snaps that plug into it. We’d need some way to transmit information about the platform’s theme plugs to its app plugs in order to work out what to mount.
  2. it introduces dependencies between snap connections. Plugging a new theme into the platform snap would require refreshing the connections of all the app snaps.

At that point, it’s not clear it is worth trying to squash this into the existing constraints.

@niemeyer: have you had a chance to think about this since getting back from your holiday?

There’s no designed constraint in the system that makes plugs/slots be one-to-many reationships and not many-to-many. We’ll likely hit bugs while trying to make that work since it was pretty much never exercised, but while designing the work with @zyga-snapd we at least consciously attempted to avoid closing major doors that would make that impossible.

So if you’d like to explore that, certainly sounds good to me.

A post was split to a new topic: Improvements in the content interface

As we discussed, this sounds like a good direction.

As a minor note, the syntax proposed is not just an extension to the current syntax. We have a bug today in the way that the content interface handles lists of paths with multiple entries, so that new syntax allows us to obsolete the old syntax in a backwards compatible way and fix the behavior, so that’d be a positive outcome even despite the theme-specific details.

I’ve split the content interface changes discussion into its own topic so we can discuss and track that work without polluting this one with issues not related to themes.

1 Like

Why don’t we just give read only access to snap of the required folder:

/usr/share/Kvantum (If the system is using Kvantum theming for QT Apps)

And expose the theme setting configured by the system?

Edited: I still don’t understand why don’t we just give access to the theme folder like we did with fonts.

Due to API issues. Snaps work in a non-trivial number of Linux distributions, and each one of those distributions evolve at their own pace, and soon we’ll be supporting dozens of versions of dozens of distributions. Applications will depend on different versions of the graphic stack libraries, and those will support different versions of the theme API. It must all continue working over time.

1 Like

Oh, is there any progress related theme, cause it’s a bit annoying to see alien apps!

Edited: Ubuntu default theme is so bad, that i can’t even use it more than a day!!

Yes, there’s work in progress towards transparent themed application support.

1 Like

Thanks for your time!
What do you mean by Transparent Themed Application support?

The end goal of the on going work is that when someone installs a snap that supports themeing, the application will run with the right theme for the local system transparently, without any need for manual user actions.

Interesting, how it will work for QT apps in Gtk Environment? or Gtk apps in QT Environment?

The details are still being worked out, but the basic idea is that themes will be packed in snaps, and the correct snap will be selected based on the theme name. So it will be possible to select the proper theme even in those cases, where there’s a cross over between a desktop based on one toolkit is running an application from a different toolkit.


So any more detail about this, This is the only thing that hold me back from using snap apps! Alien Cursor with Theme.

@zyga-snapd is landing some changes to snapd which will unblock the theme work fixes which are being work on by @jamesh. This post has some more details: Layouts: re-mapping snap directories


We just had a call to sync up on the progress of this work. Here are the details:

1 Like

Thanks for the status update. When Snap support for themes comes out, will all existing Snap packages get the improvement automatically, or will I have to repackage Polarr so that it will respect the user’s system theme? If I have to repackage, is this the thread I should be following so I’ll get notified when it’s time to rebuild the Snap?

1 Like

Any News on GTK and QT Theme Support? Its the major reason why i don’t use snap often :frowning:

Justification on asking for news:

Layouts landed in 2.32 (10th April) according to the snapd roadmap, I think the ‘improvements happening in the content interface’ is referring to ‘Auto install of content snap dependencies’? That latter feature also landed in 2.32. I’m sure I’ve seen some work on the forum for application themes but I don’t remember where and it should be linked to in this topic! :slight_smile: