Auto-connect custom GTK themes to gtk-3-themes, gtk-2-themes and icon-themes

[gantonayde]

Hello, is it possible to get qogir-themes, vimix-themes, mojave-themes and chromeos-themes auto-connected to gtk-3-themes, gtk-2-themes and icon-themes (chromeos-themes does not have a slot for icons as I didn’t include an icon theme in the snap)?

[jdstrand]

@jamesh and/or @kenvandine - this affects your gtk-common-themes snap. Can you please acknowledge you’d like greedy plugs implemented at this time and that the gtk-common-themes snap is setup the way you want it for how you want this to work now and going forward?

[jamesh]

The three content interfaces on gtk-common-themes should all be ready for the greedy connection assertions.

As far as autoconnection for third party theme snaps, I am a little concerned about granting that until review-tools gains theme snap specific checks, as I outlined here:

Theme Connector For Snaps classic confinement

I was planning to just use gtk-theme- as the prefix for snap names, for two reasons: When there is a matched set of GTK 2 and GTK 3 themes, they’re usually maintained by the same developers, and often released together as a set. The XSETTINGS protocol exposes a single gtk-theme-name setting, rather than version specific settings. We’ve got one test snap up on the store for testing: gtk-theme-traditionalhumaized. It doesn’t have the “greedy connection” snap declarations from the store yet, s…

If we are going to automatically prompt users to install these snaps to handle their selected theme(s), then I want to be reasonably sure there are no other side effects. As well as checking that it shares the content we expect it to, we also want to be sure it isn’t bundling anything unexpected like daemons or commands.

[jdstrand]

@jamesh

The three content interfaces on gtk-common-themes should all be ready for the greedy connection assertions.

Thanks

@jamesh

As far as autoconnection for third party theme snaps, I am a little concerned about granting that until review-tools gains theme snap specific checks, as I outlined here:

I was planning to just use gtk-theme- as the prefix for snap names, for two reasons: When there is a matched set of GTK 2 and GTK 3 themes, they’re usually maintained by the same developers, and often released together as a set. The XSETTINGS protocol exposes a single gtk-theme-name setting, rather than version specific settings. We’ve got one test snap up on the store for testing: gtk-theme-traditionalhumaized. It doesn’t have the “greedy connection” snap declarations from the store yet, s…

If we are going to automatically prompt users to install these snaps to handle their selected theme(s), then I want to be reasonably sure there are no other side effects. As well as checking that it shares the content we expect it to, we also want to be sure it isn’t bundling anything unexpected like daemons or commands.

Right, I acknowledged this point in the other topic. My question to you was only about gtk-common-themes.

For the rest of this request to proceed, either the review-tools need to be updated or the publisher vetted. @Wimpress and @pedronis - can you weigh in on this? I’m going to hold of on updating gtk-common-themes for greedy assertions until I hear back from you.

[jdstrand]

@jdstrand

For the rest of this request to proceed, either the review-tools need to be updated or the publisher vetted. @Wimpress and @pedronis - can you weigh in on this? I’m going to hold of on updating gtk-common-themes for greedy assertions until I hear back from you.

@Wimpress and @pedronis - ping