Hello François, On Sat, Mar 20, 2010 at 12:58 AM, François Revol <[email protected]> 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. _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
