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:
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:
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.
Attachment | Size |
---|---|
Universal_themes.pdf | 114.89 KB |
Comments
Benji (not verified)
Mon, 08/02/2010 - 01:47
Permalink
Interesting idea. I like
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 (not verified)
Thu, 11/02/2010 - 12:16
Permalink
compiz and emerald support
great work with epiddermis most useful software ever. By the way is emerald and compiz intergration still in development?
Flimm
Thu, 11/02/2010 - 13:28
Permalink
Re: compiz and emerald support
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 (not verified)
Sun, 14/02/2010 - 13:49
Permalink
This is a fantastic idea.
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 (not verified)
Sun, 14/02/2010 - 14:58
Permalink
Maybe you can use this
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
Sun, 14/02/2010 - 18:25
Permalink
Re: gstyle
I just discovered this project yesterday. I contacted the author and I'm hoping we can cooperate on theming soon!
Flimm
Sun, 14/02/2010 - 18:12
Permalink
Re: This is a fantastic idea
I'd love to, but I need general approval first.
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.
Will do!
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.
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.
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.
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.
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.
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.
So you think implementation detail n4 is a good idea? If everyone agrees, I might have a shot at implementing it myself.
Thank you. You've given me the most detailed and thorough review of this proposal so far. Cheers.
Anonymous (not verified)
Wed, 03/03/2010 - 16:39
Permalink
Namespacing
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
Thu, 18/03/2010 - 17:20
Permalink
Re: Namespacing
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 (not verified)
Wed, 10/03/2010 - 18:05
Permalink
Why is this condition
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.
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.
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
Thu, 18/03/2010 - 17:17
Permalink
You're ambitious!
I see your point now. I'll add that point to the proposed specification.
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.
I wouldn't dream of it! You're absolutely right.
Anonymous (not verified)
Wed, 10/03/2010 - 18:29
Permalink
About screensavers. Please
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
Thu, 18/03/2010 - 17:17
Permalink
Re: About screensavers. Please
One idea at a time!
bitozoid (not verified)
Tue, 13/04/2010 - 22:51
Permalink
Even further
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 (not verified)
Wed, 14/04/2010 - 13:35
Permalink
Please make it mandatory that
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.