Universal themes: an idea

I've just submitted a proposal to Freedesktop's XDG mailing list called Universal Themes. The proposal is attached as a PDF.

The idea is a new file format called "universal theme" (or utheme, for short), to accommodate all types of themes for your computer. Currently, the situation on Linux is far from ideal: find a theme on gnome-look.org or kde-look.org or wherever, and you get a .tar.gz. If you're lucky, it's been packaged correctly and the Appearance dialog knows how to install it. If you're new to theming, you'll just double-click a compressed tarball and be greeted with a collection of confusing files.

This new file format aims to have the following features:

  • It's a new mime-type, so double-clicking on a file should launch an appropriate installer. Thumbnails are also supported.
  • Any type of theme is supported, even ones that haven't been thought of yet. (Themes that have to be compiled, like programs, are not supported. So no screensavers.)
  • Themes can be linked together in skins, or collections. They're just as easy to install as activate as normal universal themes.
  • Themes can be easily indexed, categorised and indexed, thanks to a standard format of meta-data. Meta-data includes: name, license, author, version number, primary colours and description, which can be translated.
  • Themes can specify dependencies on other themes, if required. (For example, some icon themes inherit from other icon themes.)

You might notice that some of these features are implemented by Epidermis' .pigment format already. So why am I proposing a new format? The answer is that I want a well-designed format that becomes widely accepted. .pigment, to be frank, is not very well-designed. Plus it's unknown and obscure.

When I started developing Epidermis, I had two goals:

  • To learn Python and GTK. This goal I have achieved.
  • To scratch my own itch, and the itch of hundreds of other users. We want themes to be easily searchable, installable and groupable. This goal is far from complete.

Epidermis' mission statement is:

Epidermis aims to make changing the look of your GNOME desktop complete, rapid, simple, automatic, customisable and shareable.

For me, universal themes are a part of that mission, only not for GNOME only, but for all Free desktops. If universal themes are adopted and Epidermis dies in obscurity, I'd have completed my goals and would be a happier man. :) (For some reason, I felt a smiley was appropriate.)

So read the proposal and tell me what you think, I need feedback

Update: see this blog post.

AttachmentSize
Universal_themes.pdf114.89 KB

Comments

Benji's picture

Interesting idea. I like it.

I particularly like the fourth suggestion for handling unknown theme types. Although you may want to reconsider the rule for not including broad package dependencies (a GTK theme depending on GTK) since it would allow a .utheme to rely on its own installer. Although, this could be packaged along with the appropriate environments (amarok could package its own theme installer), and it might be preferable to get an error message if you don't have the software to which that theme applies.

Aley's picture

great work with epiddermis most useful software ever. By the way is emerald and compiz intergration still in development?

Flimm's picture

Correct me if I'm wrong, but hasn't development on Emerald officially stopped?
As for Compiz integration, it would mean creating a new theme format for Compiz.

When it comes to Universal Themes, it supports any type of theme, so there's no problem there.

Anonymous's picture

This is a fantastic idea. Should have bee started a long time ago anyway.
Will you cooperate with the FreeDesktop project?
Being able to have it as a specification there would get it rolling for most projects involved with themes.

A application specific theme format would be a good idea.
Makes it able for Desktop Engines to threat it somewhat intelligently (helpful error messages for noobs).
As for meta data, you might wanna look at RDF metadata (+ Dublin core). It's being used in ODF.

As for screensavers, aren't screensavers just a bunch of settings that can be put in a file without compiling anything? It would certainly make basic things possible. e.g. I want to set effect="pipes" starttime="30s" no need for compiling seems to me.

Please make it possible to package themes in meta-themes (preferrably default) for people who don't always have internet available. (It happends more than you think that people sometimes loose their internet.)
Please make it possible to use themes without internet necessary.

Although I can see your reasoning, I'm not very fond of toolkit-specific themes.
I would like to have a desktop option in the list of theme types that defines a general desktop thing.
This way you can package some stuff without requiring a specific toolkit. More freedom for everyone.
A big problem with some specifications is that they are stuck on a toolkit and not indepedent.
This huts small projects with other toolkits a lot. Please don't make the same mistake.

Languages, supporting more languages is fine on one condition.
Must have a mechanism to mark, know the original, native language of the theme.
Copyright: don't forget the type of license + allowing adding a .txt file in the theme file that holds a copy of the license. (Offline working with themes, needs this.)
Multi-Licenses is also becoming popular, you might wanna let the specification be able to include multiple copyright's and licenses for one file.

version: for pre-release things you might want to include: ~dev~codename because stable releases can also have a codename. with dev allowing dev, deva, devb and devrc would make it very flexible and more descriptive.

About your implementation details number four: why not finish it and provide an API + scripting language? This is the whole thing, you can use other experiences from open source projects with Lua if you choose it. Lua is being used as a scripting language for rpm5 FYI.

You're doing a fantastic job and adding a much-needed magnificant improvement to the free software ecosystem. Thanks!!

Anonymous's picture

Maybe you can use this project to test out things and get feedback:
It's called Gstyle project, a perfect oppertunity to make a great appearance:

http://www.webupd8.org/2010/01/try-gstyle-project-new-gnome-theme.html

Link to site itself:
http://ubuntuforums.org/showthread.php?t=1389711

Flimm's picture

Maybe you can use this project to test out things and get feedback:
It's called Gstyle project, a perfect oppertunity to make a great appearance:

I just discovered this project yesterday. I contacted the author and I'm hoping we can cooperate on theming soon!

Flimm's picture

This is a fantastic idea. Should have bee started a long time ago anyway.
Will you cooperate with the FreeDesktop project?

I'd love to, but I need general approval first.

A application specific theme format would be a good idea.
Makes it able for Desktop Engines to threat it somewhat intelligently (helpful error messages for noobs).

I wrote the specification with application specific themes in mind (for VLC, Songbird, Firefox, etc). Any type of theme that affects the appearance of the user-interface should be supported.

As for meta data, you might wanna look at RDF metadata (+ Dublin core). It's being used in ODF.

Will do!

As for screensavers, aren't screensavers just a bunch of settings that can be put in a file without compiling anything? It would certainly make basic things possible. e.g. I want to set effect="pipes" starttime="30s" no need for compiling seems to me.

Short answer is no. All screensavers are programs, and some of them accept additional configuration options, which GNOME hides. If you want to install screensavers, you're installing code which could potentially be a security risk. Electric sheep and Lifesaver are both screensavers, and they're programs.

Please make it possible to package themes in meta-themes (preferrably default) for people who don't always have internet available. (It happends more than you think that people sometimes loose their internet.)
Please make it possible to use themes without internet necessary.

The proposed specification covers this. It calls them skins. Skins include all the themes necessary, including any dependencies that are themes. It doesn't include external dependencies, however, like GTK engines.

Although I can see your reasoning, I'm not very fond of toolkit-specific themes.
I would like to have a desktop option in the list of theme types that defines a general desktop thing.
This way you can package some stuff without requiring a specific toolkit. More freedom for everyone.
A big problem with some specifications is that they are stuck on a toolkit and not indepedent.
This huts small projects with other toolkits a lot. Please don't make the same mistake.

I'm not sure what you mean here. Theme types are defined by the technology that implements them. I can't abstract them more than is technically possible. Eg: GTK themes are fundamentally different from Plasma themes, there's no way around it. GRUB, GRUB2, Xsplash, GDM, Plymouth and Usplash themes might all be classified as "bootsplash themes", but they're fundamentally different, and should be treated as such by the utheme file format. If a theme developer wants to cater for as many DEs as possible, he/she needs to create all the different themes and combine them in one skin. The handler of uthemes will then be able to ignore the themes it doesn't know how to handle, and activate the ones it does.
The specification is not stuck on one toolkit. GTK, Qt and others were only given as examples, any type of theme can be supported by uthemes, as long as meets the minimum requirements. It's not even stuck on one implementation, as it only describes a file format currently.

Languages, supporting more languages is fine on one condition.
Must have a mechanism to mark, know the original, native language of the theme.

Why is this condition important?
Most open source projects I know write their code in US English, and release translations for it. This is done even if the original authors prefer another spoken language.
Utheme doesn't require a US English translation of the name and description, but it doesn't have a mechanism to indicate the original spoken language the author used.

Copyright: don't forget the type of license + allowing adding a .txt file in the theme file that holds a copy of the license. (Offline working with themes, needs this.)
Multi-Licenses is also becoming popular, you might wanna let the specification be able to include multiple copyright's and licenses for one file.

The proposed specification does cover adding a text file (named COPYING) for license information. Multiple licenses is a good idea, I'll include that on a next draft.

version: for pre-release things you might want to include: ~dev~codename because stable releases can also have a codename. with dev allowing dev, deva, devb and devrc would make it very flexible and more descriptive.

I can see that some developers might want to include a codename for a version number, even if that version is a final release. However, I thought it would be easier to just stick to one version numbering system that's already commonly used and understood (Debian's, but without the Debian revision numbers), rather than define our own new one.

About your implementation details number four: why not finish it and provide an API + scripting language? This is the whole thing, you can use other experiences from open source projects with Lua if you choose it. Lua is being used as a scripting language for rpm5 FYI.

So you think implementation detail n4 is a good idea? If everyone agrees, I might have a shot at implementing it myself.

You're doing a fantastic job and adding a much-needed magnificant improvement to the free software ecosystem. Thanks!!

Thank you. You've given me the most detailed and thorough review of this proposal so far. Cheers.

Anonymous's picture

Have you considered using a URI for the theme's type and unique name? It's not unknown for different project to use the same name and unless there is to be a central registry of names this could lead to clashes.

XML already takes this approach to keep namespaces unique and I think it's a sensible way of making future problems much less likely.

Examples could include:

http://themes.freedesktop.org/types/wallpaper or urn:xdg:theme-type:wallpaper (although the urn: scheme would require registration of xdg with the IANA).

Flimm's picture

Thanks for that comment, that was really helpful. Thanks to you, I decided to get to work and study XML and RDF. I want to do this properly. Namespacing is a very good idea, it makes universal themes as future-proof as possible.

Anonymous's picture

Why is this condition important?

Let's say someone downloads a multi-language uTheme.
And that person wants the most complete translation, without language preference.
Then it's possible to set that and let the computer work it out with the settings in the package.
I had another very good situation why this could be important but I lost it.

Although I can see your reasoning, I'm not very fond of toolkit-specific themes.
I would like to have a desktop option in the list of theme types that defines a general desktop thing.
This way you can package some stuff without requiring a specific toolkit. More freedom for everyone.
A big problem with some specifications is that they are stuck on a toolkit and not indepedent.
This huts small projects with other toolkits a lot. Please don't make the same mistake.

I'm not sure what you mean here. Theme types are defined by the technology that implements them. I can't abstract them more than is technically possible. Eg: GTK themes are fundamentally different from Plasma themes, there's no way around it. GRUB, GRUB2, Xsplash, GDM, Plymouth and Usplash themes might all be classified as "bootsplash themes", but they're fundamentally different, and should be treated as such by the utheme file format. If a theme developer wants to cater for as many DEs as possible, he/she needs to create all the different themes and combine them in one skin. The handler of uthemes will then be able to ignore the themes it doesn't know how to handle, and activate the ones it does.
The specification is not stuck on one toolkit. GTK, Qt and others were only given as examples, any type of theme can be supported by uthemes, as long as meets the minimum requirements. It's not even stuck on one implementation, as it only describes a file format currently.

I'm hoping for a basic theme format that works for all and is toolkit-agnostic. It's okay if not all kinds of settings are implemented that are in gtk or qt or something else. I and probably a lot of other themerusers/-makers would really jump on the idea of a basic desktop theme format. I realize that you can't do everything in it but a lot of basic stuff should certainly be possible, abstracted. Also the bootsplash themes, because of what they do, there are inevitable parallels in how they look/are composed. e.g. the splash screen or boot screen. It's a texture in all of the themes right? For these basic things it would be possible to abstract away from specific things. Please try it out (because if even a basic set is implemented, a lot of exchangeable themes will already be possible). Please try it out, even if it's only for archiving the experience. Don't mind if it's basic. Working with a core(basic, abstract) profile and a full profile wouldn't hurt anyone.

About your implementation details number four: why not finish it and provide an API + scripting language? This is the whole thing, you can use other experiences from open source projects with Lua if you choose it. Lua is being used as a scripting language for rpm5 FYI.

So you think implementation detail n4 is a good idea? If everyone agrees, I might have a shot at implementing it myself.

Yes I think detail n4 is good but only when carefully implemented.
You need to make an API because every program can be different on any point.
You don't need to defined a theme contents, only how it's packaged as a whole.
All more detailed, involved things with determining rules for the packages content itself will get in the way of flexibility. Nasty surprises could arise.
The API would take care to installing and managing themes cross-application.
Maybe a theme manager integration API is the kind of thing you need.
The API should specify stuff like naming schemes for applications.
Only in pretty general (boot, splash, desktop engines such as gtk,qt)stuff you can go specific.

And something else, about specifying directory structures.
Please don't choose a rigid design with a specific folder.
Instead choose some sort of folder variable (this would be part of the api) where themes are normally in installed. I'm asking this because it will not run into issues with things like the differences in Linux, Unix,Windows,Mac OS, GoboLinux http://gobolinux.org/ (has unique directory structure, very novel)
It's also error-prone to specify a specific directory. The user might have a different structure then the creator.

Thanks for commenting on my earlier post

(NOTE:Moderator has edited this comment to make the quotes a bit clearer.)

Flimm's picture

Let's say someone downloads a multi-language uTheme.
And that person wants the most complete translation, without language preference.
Then it's possible to set that and let the computer work it out with the settings in the package.
I had another very good situation why this could be important but I lost it.

I see your point now. I'll add that point to the proposed specification.

I'm hoping for a basic theme format that works for all and is toolkit-agnostic. It's okay if not all kinds of settings are implemented that are in gtk or qt or something else. I and probably a lot of other themerusers/-makers would really jump on the idea of a basic desktop theme format. I realize that you can't do everything in it but a lot of basic stuff should certainly be possible, abstracted. Also the bootsplash themes, because of what they do, there are inevitable parallels in how they look/are composed. e.g. the splash screen or boot screen. It's a texture in all of the themes right? For these basic things it would be possible to abstract away from specific things. Please try it out (because if even a basic set is implemented, a lot of exchangeable themes will already be possible). Please try it out, even if it's only for archiving the experience. Don't mind if it's basic. Working with a core(basic, abstract) profile and a full profile wouldn't hurt anyone.

I see what you mean now. Wow! You're ambitious. I've got to say, that's not what universal themes is about at all. Universal themes only support the common properties of all the theme formats on the planet: meta-data. That may not seem like much, but would enable fantastic mixing and matching, simple distribution and simple handling of theme files.

Instead of creating a new abstract theme format, a theme generator tool would be more useful. To take the bootsplash example, I could imagine a program that would take a wallpaper and a logo and use them to automatically generate a grub bootsplash, plymouth bootsplash, xsplash login screen and GNOME splash screen. It could package all those different themes in the utheme format, and bundle them together in one skin. But universal themes does not touch the actual implementation details of different theme formats.

And something else, about specifying directory structures.
Please don't choose a rigid design with a specific folder.
Instead choose some sort of folder variable (this would be part of the api) where themes are normally in installed. I'm asking this because it will not run into issues with things like the differences in Linux, Unix,Windows,Mac OS, GoboLinux http://gobolinux.org/ (has unique directory structure, very novel)
It's also error-prone to specify a specific directory. The user might have a different structure then the creator.

I wouldn't dream of it! You're absolutely right.

Anonymous's picture

About screensavers.

Please do n4 and implement an animation API for it.
(using SVG+SMIL or an API+scripting language for animated screensavers or other stuff e.g. movies)
In an API with a recommended scripting language (Lua is fine, I prefer it because RPM5 uses it, but don't mind other stuff e.g. Python) so that it becomes portable, even if it's an application.
By specifying an API + scripting language all the building blocks are in place and cross-platform (unified).
This way a designer can make a screensaver and have it work everywhere where the scripting language and the api is present.
Providing this is very doable for theme managers. They just have to implement the API and ask for the runtime environment of the scripting language.

Thanks for listening

Flimm's picture

One idea at a time!

bitozoid's picture

I totally agree.

Even further, user interface is more than the skin. For example, I'd love to see an uniform keyboard shortcut layer for the desktop. In a similar way, we could setup all the shortcuts in one click. Kind of a registry for shortcuts. Then, there are mouse gestures and user-defined keyboard layout as well.

I'd love to see that working.

Anonymous's picture

Please make it mandatory that implementations have as default full packages and not meta-packages. Could save a lot of time/efford/grief in the long term.