[Proposal] Meta themes spec.

[Stephan Arts]

On 6/8/07, Evgeny Egorochkin <phreedom.stdin at gmail.com> wrote:
> 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.

This is exactly what I mean, at the moment a user needs to grab
several different pieces from several locations to update their entire
desktop. And from a designer point-of-view, when they create several
components to build a certain look, they end up scattering all over
the place. (look at all the pieces you need from the *-look websites,
why download them one-by-one instead of just all-together).


Let me be clear on one thing, I am not aiming at replacing current
theming methods. I am looking for a system which works with them and
regardless of how they get the job done, provide the user of an easy
package to install several different types of themes at once.

>
> Overall sounds useful and feasible.
>
> -- Evgeny
>

--
Stephan