Universal themes: a proposal

[David D Lowe]

Hello François,

On Sat, Mar 20, 2010 at 12:58 AM, François Revol <revol at free.fr> wrote:
> Hi,
>
> I've been thinking about a cross-platform theme format for a while
> too...
>
> Though I just hope it won't get too X11-specific, ideally it would be
> usable by Haiku and others like AROS and ReactOS maybe.
>
That's my vision for Universal Themes, I want it to work on all free
desktop operating systems, and possibly even on closed systems like
Windows.

> Some comments of what I read:
> - xml: hmm ugh, well... yeah I've yet to learn how to use libxml2...

I know a lot of people dislike XML. To my surprise, you're the first
to complain about my choice! I realise XML can be ugly, but I feel it
has lots of advantages compared to a custom configuration file: it's
format is standardised and very clearly defined, and almost all
programming languages have XML APIs. What format would you prefer?

> - new mimetype & ext: fine, I can even have Haiku's Themes to
> explicitely support it with the mime db.
> - .tar.gz: not my prefered format, plus it doesn't maintain xattrs (at
> least on Haiku, and not by default on Linux), but it probably doesn't
> matter much as most data will likely have to be converted anyway so it
> should be ok.
As a matter of fact, I've been thinking about changing the archive
format myself, for different reasons. tar is not good for extracting
one or two files rapidly, as it doesn't support random access. What I
suggest instead is the zip format with zero compression. It would
contain the metadata in an XML file, the thumbnail images and the
theme, compressed as an archive. Eg:
my_gtk_theme.utheme (a zip file with 0 compression)
-> utheme.XML
-> thumbnail.png
-> preview.png
-> my_gtk_theme.tar.gz (in this case, a gzipped tarball. This format
would be chosen by the theme creator)

This way, themes could choose their own compression format, one that
supports xattrs if need be. Extraction of meta-data and thumbnails
would be speedy, which is important when indexing or previewing lots
of uthemes simultaneously.

> - no screensaver: well, we can always keep the name of the current
> screensaver, or a limited set of classic ones. (in Haiku Themes also
> saves the saver's settings (a serialized BMessage).)

I'm divided on this one. A screensaver is much closer to a program
than a theme when it comes to packaging and distribution. It's also
just as powerful as a program, so it has serious security
implications. On the other hand, a screensaver is seen by a lot of
users as part of the appearance or look and feel of their system. They
would want a "complete skin" to change their screensaver.

You could create a new theme format, "screensaver-setting". All it
would contain would be the selection of a screensaver, not the
screensaver itself. It could include a dependency on the selected
screensaver package though, delegating the installation of the
screensaver to the package management system.

While I don't like this solution, it seems like the best one to me,
and users are bound to want this implemented if uthemes become
popular.

> - packaging: that's a feature I've yet to finish in Themes
> - color categories: it's quite easy to pick the closest color in a
> palette from the base color of a theme, just need the smallest distance
> in the RGB colorspace, there is a formula for this... so an utheme
> exporter can do it automatically from desktop color for ex.

Yes, indeed.

> - another option for archiving is to use data: in the xml file, as is
> done in svg for bitmaps, cf.
> http://dev.haiku-os.org/browser/haiku/trunk/data/artwork/HAIKU%20logo%20-%20black.svg
> though that might not be usable for large bitmaps, but possibly
> cursors. It would complicate the xml some more though...

Why would this be necessary? What advantage does embedding images in
the XML have over simply including an image file in the archive that
is the utheme?

> - things like icons would ideally be available in a vector format.
> Haiku uses HVIF because SVG is way too large to fit the inode
> small_data section (ZETA tried it and failed), it's possible to convert
> an SVG into HVIF, but it's not optimal... but I suppose this would have
> to do. Themes doesn't support changing icons yet anyway.
>

When it comes to icon themes, or any type of theme for that matter,
their format is entirely down to the system that uses them. For
example, GNOME and KDE use the icon theme specification posted on
freedesktop.org here:
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
All you would have to do to support Haiku icons would be to define a
new theme format. All that the utheme specification drafts is what all
uthemes should have in common.

> While it's useful to have target-ready files, I'd like to have as much
> as possible mapped into a format usable by others.
> It might be nice to be able to extend an existing theme with another OS
> /desktop version of it, to customize the OS-specific parts. The rest
> will always be "best effort" anyway.
>
I would love to see that happen, but that's not what the universal
themes idea is aiming at. This idea proposes that what's already in
common between themes should be standardised. Themes have these
characteristics in common:
- they have common meta-data
- they have preview images and thumbnails
- they're not architecture specific, they can be distributed as is
- they affect the appearance of the system, and not the functionality
- they're not completely independent from each other from the user's
point of view, some themes fit better together than others
Universal themes should standardise this commonality, and provide some
mechanism of packaging themes into collections.

What I'm not proposing is that all systems should be able to apply a
universal theme. Themes are limited to the technology implementing
them, and universal themes should recognise this. Eg: Haiku's icons
are not supported by GNOME.
What all systems should be able to do is sort, index and preview
uthemes, regardless of type. They should be able to handle unsupported
theme types elegantly.

I realise the name "universal themes" can be misleading in this
regard, and would gladly accept superior alternatives.

Tools are being written to make themes compatible with more
technologies. For example, it is possible to make Qt use a GTK theme
with QGtkStyle, and vice-versa with GTK-Qt theme engine. This tools
are complex and universal themes are not a replacement for them,
rather, they should complement universal themes.

> Something else that might be useful is adding fonts, though it might be
> abused to include non-free fonts even unintentionally...
>
Is a font a theme? I need to think this over.
As for non-free themes, they're supported by universal themes in the
same way that GNU Emacs supports writing closed or open source code.

> Btw, strings like name & desc don't mention an encoding, I suppose it's
> UTF-8 ;)
>

Yes, I suppose. XML supports different encodings, so that shouldn't be
a problem.

> Also, in Themes I made it easy to choose which part we want to apply/
> save (checkboxes per add-on), and made it extensible.
>

Good idea.

> A list of existing OS/Desktops to check for theme formats:
>
>  * Haiku
>  * http://dev.haiku-os.org/browser/haiku/trunk/3rdparty/mmu_man/themes
>  * http://www.haiku-os.org/blog/mmu_man/2008-01-25/the_bowels_of_the_theme_manager_or_how_to_make_haiku_as_ugly_as_zeta
>  * http://www.haiku-os.org/blog/mmu_man/2008-02-01/even_more_themes
>  * GNUstep & Etoilé (Camaelon):
>  * http://etoileos.com/
>  * AROS
>  * http://aros.sourceforge.net/
>  * http://aros-wandering.blogspot.com/
>  * ReactOS
>  * http://www.reactos.org/wiki/User:Mf/UIdeas/Themes
>
>
Great list! It's good to check that some theme formats won't conflict
with the universal theme format.

> Things that could be made themeable:
>  * sounds
>  * terminal colors
>  * dircolors
>
Of course! There's no reason why these themes could not support uthemes.

David D Lowe.