KDE: global auto-connect qt-common-themes

store-requests
20

We’ve got an updated version of gtk-common-themes in the candidate channel (and latest/stable/ubuntu-24.10 for the new Ubuntu release) that merged PR #10 to remove the Breeze themes.

I see that there are gtk-theme-breeze and icon-theme-breeze snaps published to the store as stable. So snapd-desktop-integration should be able to trigger their installation when people upgrade to the new gtk-common-themes (although it may require a log out/log in to occur).

There are a few issues with the new snaps though, that prevent them from actually sharing the theme data.

For gtk-theme-breeze:

  1. it currently defines a gtk-theme-breeze slot, which no applications will try to plug. Instead, it should define the same slots as gtk-common-themes:
    slots:
  gtk-3-themes:
    interface: content
    source:
      read:
      - $SNAP/share/themes/Breeze
      - $SNAP/share/themes/Breeze-Dark
  gtk-2-themes:
    interface: content
    source:
      read:
      - $SNAP/share/gtk2/Breeze
      - $SNAP/share/gtk2/Breeze-Dark
  2. The snap contains a lot of files outside of the paths shared via the content interface slots. I think most of this could go, massively reducing the size of the snap.
  3. Consider making the snap architecture independent. If you’re using build-base: core24, adding the following to your snapcraft.yaml should do the trick:
    platforms:
  all:
    build-on: amd64
    build-for: all

For icon-theme-breeze:

  1. The snap seems to be shipping themes that are not exported via the content interface slot. Am I right in thinking these are all cursor themes? If they are likely to only be used along side the Breeze icon theme, it might make sense to just keep them here and add them to the icon-themes slot.
  2. This snap should also be architecture independent.

With those issues sorted out, the snaps will need to have the snap declaration updated on the store. I think we’d want the same declaration as was used for these other theme snaps:

2 Likes