KDE: global auto-connect qt-common-themes

scarlettmoore · July 5, 2024, 9:32am

Hello folks, I need auto-connect for qt-common-themes as this fixes long standing theming issues for qt6 based snaps. Thanks for you consideration. Scarlett

jslarraz · July 10, 2024, 1:17pm

Hey @scarlettmoore

Could you please develop your request a bit more.

I understand that you are requesting global auto-connection for one or more content interfaces. Could you please indicate which ones are you requesting the global auto-connection for, which content they include and which theming issues they solve?

Thanks beforehand!

scarlettmoore · July 10, 2024, 3:31pm

Hi, This request follows my update to the kde-neon-6 snapcraft changes that will be merged soon. Please see here: https://github.com/canonical/snapcraft/pull/4884 In that pull request you can find the long list ( not even a portion of the bug reports out there ) of qt snap theming issues reported. This follows the gtk-common-themes content snap, but with QT/KDE stuff. We will take over our GTK themes as well as the ones in gtk-common-themes are extremely outdated and non functional.

Here are my new plugs that need to the respective qt-common-themes snap slots.

                "kde-gtk2-themes": {
                    "interface": "content",
                    "target": "$SNAP/data-dir/themes",
                    "default-provider": "qt-common-themes",
                },
                "kde-gtk3-themes": {
                    "interface": "content",
                    "target": "$SNAP/data-dir/themes",
                    "default-provider": "qt-common-themes",
                },
                "qt-icon-themes": {
                    "interface": "content",
                    "target": "$SNAP/data-dir/icons",
                    "default-provider": "qt-common-themes",
                },
                "qt-sound-themes": {
                    "interface": "content",
                    "target": "$SNAP/data-dir/sounds",
                    "default-provider": "qt-common-themes",
                "qt-6-themes": {
                    "interface": "content",
                    "target": "$SNAP/kf6",
                    "default-provider": "qt-common-themes",
                },

Thanks for your time. Scarlett

jslarraz · July 11, 2024, 7:16am

Hey @scarlettmoore

Thank you for the information. In general, I’m fine with the requested auto-connections. For gtk themes, I’m wondering if we should try to bring gtk-common-themes up to date instead.

@kenvandine mentioning you as the last uploader of the snap (if I’m right). Any thoughts?

Thanks

scarlettmoore · July 11, 2024, 10:59am

Not that I don’t trust the gtk-common-themes team, I would prefer to maintain our own themes, we have updates often and I can bring them in much faster under our own infrastructure and our users will benefit greatly. Thanks, Scarlett

soumyaDghosh · July 11, 2024, 11:10am

I would also like to help her to maintain it. So, count me in.

YamiYukiSenpai · July 13, 2024, 10:19pm

is it still being maintained? I checked the GitLab page, and it was last updated 2 years ago.

scarlettmoore · July 17, 2024, 1:08pm

@jslarraz from the lack of response from gtk-common-themes, we you please allow us to maintain our own gtk themes and move forward on this? snapcraft has been merged. Scarlett

kenvandine · July 24, 2024, 2:40pm

@jamesh thoughts on this?

jamesh · July 26, 2024, 11:18am

Here are my thoughts on the snap:

The kde-gtk2-themes, kde-gtk3-themes, qt-icon-themes, and qt-sound-themes slots should all drop the kde- and qt- prefixes. As is, no application snaps will be able to connect to them since the content ID (which defaults to the slot name) doesn’t match. If the snap declaration sets slots-per-plug: * like the other snaps, then it can be connected simultaneously with the other snaps.
We don’t have a great story for distributing GTK 2 theme engines. At present we put the engines in the gtk2-common-themes snap separate from the platform independent data. We’d probably need to add the oxygen-gtk engine there (and make sure the snap is still buildable).
We have a system set up to automatically install theme snaps to match a user’s GTK, icon, and sound themes. Unfortunately it won’t work with a snap by the name of qt-common-themes, since it looks for snaps on the store named after the theme (with some limited support for stemming to combine related themes: exact details here). What are your thoughts on splitting those parts out into their own snaps? This would probably involve creating snaps called:
- gtk-theme-breeze
- icon-theme-breeze
- icon-theme-oxygen
- icon-theme-kde-classic
- sound-theme-oxygen
- sound-theme-ocean
With this, any system with the snapd-desktop-integration package installed would be able to install those packages on demand on systems using those themes. While this is a lot more snaps, each one should be a lot simpler, and may not need to be updated as often.
As Qt themes involve some native code, we probably can’t just assume the same theme will work across different bases or possibly different Qt versions. I’d imagine an application built for core22 might have trouble using theme shared libraries built for core24 and possibly vice versa.

So the slot name should give probably encode what the compatibility guarantee is.
The qt-6-themes slot seems to be a grab bag of different types of data. As defined in the current snap, an application snap that plugged the interface would end up with a directory containing children breeze-dark, breeze-light, default, oxygen, look-and-feel, x86_64-linux-gnu, QtCurve, color-schemes, kstyle, Kvantum. It’s not clear you intended to flatten the hierarchy like this. This raises a few questions:
- How would you expect an application snap to use this content? Would the application set a few environment variables
- Would you expect other snaps to be able to provide more theme data (via slots-per-plug: * like we’re using for the other theme types), or would this snap provide all possible themes?
- Is all of this relevant to applications? On the GNOME side, we tended to leave e.g. gnome-shell themes out of the theme snaps, since regular applications don’t use that data.
If you don’t expect any other snaps to provide additional Qt theme data, and the compatibility guarantee is essentially the same as the kde-neon framework snap, might it be easier to just ship the theme data in that snap?

As for the maintenance of the gtk-common-themes snap, I’ve had a go at bringing it up to date here:

https://github.com/ubuntu/gtk-common-themes/pull/11

It still needs a bit more testing, and there are some issues to resolve with building architecture independent core24 snaps on Launchpad. But even with all that resolved, splitting Breeze off seems reasonable if you want to take over maintenance.

I only ask that we do it once things are in place so we can automatically prompt people to install your replacement snaps.

scarlettmoore · July 28, 2024, 12:36pm

Thank you so much for your input. I will get started ASAP.

jamesh · July 29, 2024, 8:01am

Here are some example snap projects for packaging GTK and icon themes:

The main things to call attention to are:

They are using base: bare so they don’t pull in a large base snap that may not end up being used by any applications. They also specify build-base: coreNN to tell Snapcraft what environment to build in.
They build as architecture independent snaps: they’re providing architecture independent data to other snaps, so there’s no reason to go to the trouble of building the snap for each architecture.
All the provided themes match the snap name. If a user is using the Yaru-MATE-dark GTK theme, then snapd would look for gtk-theme-yaru-mate-dark, gtk-theme-yaru-mate, and gtk-theme-yaru snaps sequentially. The second name would give a hit.

If you install either of these snaps, you can see that they connect to all the application snaps with gtk-3-themes and icon-themes plugs in parallel with gtk-common-themes. This is how your snaps would ideally integrate.

scarlettmoore · July 29, 2024, 8:05am

Now qt themes in many cases use libraries ( .so files ) I don’t think that would go well in arch independent, would it?

jamesh · July 29, 2024, 12:11pm

Those suggestions were specifically about packaging the GTK, icon, and sound themes.

The Qt themes are going to be different for the reasons you state. I think the heart of the question here is how would the application snap use the Qt theme libraries provided by your snap?

In the case of other theme data types we’re currently handling, it was enough to mount the data into a directory tree that could be added to $XDG_DATA_DIRS. Looking at what’s in your snap, there’s some libraries that need to end up in Qt’s plugin directory, and there’s data files specific to some theme engines that need to be in other locations. How would an application snap wrangle all of this?

scarlettmoore · July 29, 2024, 1:10pm

Right. So the theme snap will need to set the environment to ensure everything works. I will need to do more further experimenting on the qt side. I will get the gtk ones done first as they are easy…

scarlettmoore · August 2, 2024, 11:21am

Ok so I have made Install gtk-theme-breeze on Linux | Snap Store and Install icon-theme-breeze on Linux | Snap Store

What next? Tell our users to install them or ? Thanks for any help.

Scarlett

scarlettmoore · August 4, 2024, 10:45am

Never mind I figured it out, users need to run

for PLUG in $(snap connections | grep gtk-common-themes:icon-themes | awk '{print $2}'); do sudo snap connect ${PLUG} icon-theme-breeze:icon-themes; done
for PLUG in $(snap connections | grep gtk-common-themes:gtk-3-themes | awk '{print $2}'); do sudo snap connect ${PLUG} gtk-theme-breeze:gtk-3-themes; done
for PLUG in $(snap connections | grep gtk-common-themes:gtk-2-themes | awk '{print $2}'); do sudo snap connect ${PLUG} gtk-theme-breeze:gtk-2-themes; done

Unfortunately Breeze Dark is choosing breeze light icons. Breeze light looks good. Switching between the two works.

I think the breeze currently in gtk-common-themes may be conflicting. Can I please get Remove KDE breeze as it is outdated and broken. We will provide our own themes snap. by ScarlettGatelyMoore · Pull Request #10 · ubuntu/gtk-common-themes · GitHub merged?

mr_cal · August 28, 2024, 9:50pm

@kenvandine - can you help with the PR that @scarlettmoore linked above?

alexmurray · September 18, 2024, 2:34am

Pinged @kenvandine on the PR to try and get this moving.

jamesh · October 14, 2024, 5:49am

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:

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

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.
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:

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.
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: