[Proposal] Meta themes spec.

[Evgeny Egorochkin]

On Friday 08 June 2007 16:30:05 Matthias Clasen wrote:
> On Fri, 2007-06-08 at 12:53 +0200, Stephan Arts wrote:
> > Hello all,
> >
> > I would like to propose starting to work on a specification for 
> > metathemes.
> >
> > Theme packages which are equipped with multitude of themes, like Gtk+,
> > metacity, icons, cursors, wallpapers, xfwm4, KDE-theme-manager, Kwin,
> > kde-sounds... etc.
> >
> > With the introduction of these 'meta-theme'-packages (lacking a better
> > word for it), artists will be able to provide the user with a complete
> > UI experience in one go.
> >
> > However, this is only going to work if it is going to encapsulate
> > existing theme standards. A metatheme not being a theme by itself, but
> > a package of different real themes, aimed towards providing the user
> > with a complete set of icons, wm-themes, wallpaper(s), cursors and
> > widget-styles.
> >
> > Typically, a metatheme package can be a .tar.gz archive, containing
> > the different themes in folders:
> >
> > /gtk-2/
> > /metacity/
> > /xfwm4/
> > /kth/
> > /kwin/
> > /icons/
> > /wallpapers/
> >
> > And an index.metatheme or metatheme.xml file containing information
> > about the contents of the package. Like which components are
> > available, a package might not contain an xfwm4 theme for example, and
> > the author, license and release-version/date information.
> >
> > Extensions of some sort might be nice to have too.
> >
> > Example:
> > Some gtk-themes might require a theme-engine to work correctly. The
> > metatheme package should be aware of this so implementations can
> > inform the user about such requirements.
> >
> > I would like to know what you think about this.
>
> I'd start by looking at existing solutions...what you are asking for
> largely works today in Gnome, I'm sure it does in KDE, too.

I believe Stephan is not talking about unifying/changing the way theme engines 
work, but instead proposes to standardize a packaging scheme to predictably 
pack :

1) things that *can be shared* between theme engines
2) things incompatible between theme engines but related to/utilizing (1) in a 
single package.

Overall sounds useful and feasible.

-- Evgeny