On 6/8/07, Evgeny Egorochkin <[EMAIL PROTECTED]> 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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
