appstream

appstream copied to clipboard

In "app store" environments like Android, customized UI themes are a fairly popular category of user-installable component. Free desktops have two main types of theme:

• icon themes, like the ones in https://packages.debian.org/sid/all/numix-icon-theme/filelist (multiple themes in one package here)
• GUI toolkit and window manager themes, like the ones in https://packages.debian.org/sid/all/arc-theme/filelist (multiple themes in one package again)

plus some more minor ones (Debian has a couple of sound themes and a few cursor themes).

Is AppStream an appropriate way to describe these theme packages?

• Themes should maybe have their own type, unless they are considered to be an addon to something (what?)
• Icon themes should maybe be their own top-level <provides>, like <provides><icon-theme>Numix-Light</></>?
• The various other kinds of theme often go together as a group to give multiple toolkits and packages a coherent look, so maybe <provides><theme types="cinnamon gnome-shell gtk-2.0 gtk-3.0 metacity-1 plank unity xfwm4">Arc</></> or something?

I didn't suggest

<component type="icon-theme">
  <id>Numix-Light</id>
...
<component type="theme">
  <id>Arc</id>
...

because it seems to be somewhat common to ship light and dark variants of a theme together, the same way you'd group variants of a font.

Having an icon-theme component type is on my radar, for that kind of component it's relatively easy to define since this one has an XDG specification. Component-types should never be vendor-specific, which makes this a tricky cases for GTK+ and KDE Plasma themes. If it is a GNOME Shell theme, it should definitely be of component-type addon and extend the GNOME Shell component (subsequently, a Plasma shell theme should extend org.kde.plasmashell). To make it easy for programs to find out which type of addon they are dealing with, I am thinking about introducing a new addon_type or addon_class tag, for software to filter out the right type of extension.

So, e.g. a GNOME Shell theme would be:

<component type="addon">
  <id>org.example.whatever</id>
  <name>Whatever</name>
  ...
  <extends>org.gnome.Shell.desktop</extends>
  <addon_type>shell-theme</addon_type>
</component>

While Plasma could have addon types for "plasmoids" (desktop-widgets) and themes etc. For GTK+ themes, GTK+ would need to get an AppStream-ID and could them be extended by the same mechanism:

<component type="addon">
  <id>org.example.mytheme</id>
  <name>MyTheme</name>
  ...
  <extends>org.gtk.gtk3</extends>
  <addon_type>theme</addon_type>
</component>

An alternative to this approach would be to define an abstract "theme" component type and have it get a tag like "only for GNOME and GTK+ bigger than version X". But I currently prefer the approach outlined above, as it is super-generic and also works for other software having different kinds of extensions.

Downside would be that software centers would need to know about the shell and toolkit AppStream-IDs in order to present a nice "themes" overview, and therefore would likely need to hardcode them. But I think something like that will need to happen inevitably no matter what solution for this issue is chosen, since it makes simply no sense to show a GNOME user KDE themes and vice versa.

I'll add an icon-theme component with a future (next or the one after) release, but for GTK+ and other themes I think it's best if they are addons. Maybe in the long run adding a special type of addon, visual-style may make sense to help software centers distinguish themes and other visual styles from functional addons. Then software centers would need to add explicit support for each theme type they want, which I think isn't too much to ask given that the software centers themselves are already written for use with specific desktop environments.

That doesn't apply to icon-theme though, as that is a widely used XDG standard which will work on any recent desktop environment.

for GTK+ and other themes I think it's best if they are addons

The arc-theme package in Debian has themes for GTK, GNOME, Cinnamon and several others. What is it an addon for? Can it be an addon for more than one thing?

I think it probably makes more sense for the user-facing object in a software center to be "Arc theme", rather than having a separate "Arc GTK theme", "Arc Cinnamon theme" and so on?

Arc's matching icon-theme is currently packaged separately, but if it was included in Debian, perhaps it would make more sense for a software center to show the icon theme and the matching GTK/Cinnamon/etc. themes as one object that is installed together?

I would expect - going with the current idea - that a package like arc-theme would contain multiple metainfo files, one for each part of the theme, but with the same <name/> as the user probably doesn't need to care what a "GTK+ Theme" is. So if Plasma Discover searches for visual-style components extending org.kde.PlasmaShell it would find the right thing, as well as GNOME Software searching for visual styles for org.gtk.GTK3. This means that something like Arc Theme may show up in multiple places when the user is looking for themes, but I think that's okay. Especially because such a visual style addon will contain screenshot of what the final result looks like, and those will be different depending on whether it is applied to the Cinnamon desktop or GNOME Shell. I expect GNOME Software to simply hide a theme changing the Cinnamon UX unless it's running on Cinnamon, while showing a GNOME Shell theme, etc.

If you mean that one visual style works for both shells, it may very well extend them both if the API loading the theme is the same.

would contain multiple metainfo files

Ah, this was the missing piece of information - I hadn't realised that was possible/allowed.

would contain multiple metainfo files

Ah, this was the missing piece of information - I hadn't realised that was possible/allowed.

It's perfectly fine :-) However, ideally the component should be split into individual packages to avoid the effect of other software being magically installed/uninstalled when the user is installing/removing a seemingly unrelated component.

I think I will add an icon-theme component to the next release of AS, as that's an easy change and appears to be pretty uncontroversial. Icon themes being well specified and adopted makes that possible. As for any other themes, I do thing a special addon type for visual changes is the best way to go (named visual-style, ui-style, style, appearance, etc. - not sure which name is best). That would also cover the cases of LibreOffice themes, media player skins, desktop shell themes and whatever else people might come up in future. Ideally this would even cover wallpapers, so the desktop's wallpaper dialogs can install new ones via the software center (currently, GNOME and KDE use completely different systems to handle wallpapers which are incompatible with each other, so wallpaper components need to extend the specific desktop anyway)

AppStream has icon-theme now, available with the next release (to be released today). I think autogenerating the icon-theme metadata from theme index files is probably not a great idea, so for now we would rely on icon theme authors to ship a metainfo file in order to make use of this feature.

I think this has actually been solved, but we would need a lot more tooling around it.