Universal themes: a proposal

[François Revol]

Hi David,

> > 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?

Well I suppose it's the "lest worse" choice anyway :p

I just don't fancy the perspective of having to use libxml or some 
other parser.

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

As I said, xattrs don't matter much in Haiku anyway, they are mostly 
used by the theme manager itself when applying a theme (like setting 
the background image), but not required on the files themselves.

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

Yes that's the idea, just name the saver, or a category maybe.
Possibly we can archive the saver's config (for ex, a Matrix theme 
could use a marquee type saver with green text).
That's what I did in Haiku.

> > - 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?

Not much, it's a possibility, but it'd become quite huge to handle when 
using several large backgrounds.

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

As I said, it's possible to convert HVIF from SVG... And of course it's 
possible to render PNG from SVG as well... so it makes a nice canonical 
format.
We already use the icon theme names in several places (disk drivers) 
already btw.

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

Yes but having a large set of themes that not everyone can use if not 
as useful.

What would be interesting is having a normalized mapping for all those, 
so at least partially they could be applied elsewhere.

Even in Haiku the Theme Manager can apply themes made in ZETA, though 
it can't apply the decorators since they are different, but it tries to 
map the names at least.

For ex, system colors, sounds, ... could be extracted from the "native" 
archive and provided in the xml as canonical info to be translated.
Also background file names in the native archive...

It's a bit more work of course...

Also some things can be extracted and used right away, for ex dircolors 
or emacs color themes.

See my MSTheme importer for ex, it tries to map cursor and sound 
names...

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


Well, most themes usually want distinctive fonts.
Usually it's done by people who don't really care about licences though 
or disregard them as they make them up just for themselves first (as I 
did), and just take whichever TTF they find on the net that match their 
liking.
Most blatant ones are Matrix or Stargate Atlantis, for ex...

http://revolf.free.fr/beos/shots/shot_SGA_ancient_XEmacs.png

(with the added benefit that noone can understand what you are doing by 
just looking over your shoulders.)

So level 1 is providing font names (possibly with fallback à la CSS).
And level 2 is archiving the needed TTF along with.
Level 1.1 could be giving apt names for packages which include the font 
though, when there are.

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

It's a problem if it's not defined, people tend to assume stuff when 
it's not standardized ;)

François.