ThemePackageSpec (aka Metathemes)
dobey.pwns at gmail.com
Sun Jun 7 15:38:53 PDT 2009
I think the problem is that you're simply conflating the locations to
mean that the icons and such *must* be part of some meta theme, when in
fact, they do not have to be. Metacity, GTK+, and other themes currently
stored in the "themes" path, can be completely independent, and a
meta-theme could provide only a Metacity theme, and reference other GTK,
QT, icon, or sound themes just as they do now. The only difference would
be that the implementations would be looking in some additional place,
than where they do now, to resolve those theme lookups.
The number of files in those themes, and their location on disk isn't an
issue that would require their location to be somewhere specifically
away from where other theme content is kept. The bigger problem is that
currently, icon themes and cursor themes, are stored in the exact same
place on disk. The changes here would fix that, and make it simpler for
artists to package entire collections of themes as a desktop theme,
which they can't do now, because all of the files are in independent
locations on disk.
With the proposed change, the GNOME icon theme for example would simply
It's quite a simple change, with lots of benefits. I've even advocated
making the change several years ago, but alas.
On Sat, 2009-06-06 at 12:53 +0200, Torsten Rahn wrote:
> I think there is a known problem with your approach.
> There is a good reason that icons and sounds were always kept in "distinct"
> Iconsets and sounds have the exceptional property of
> * involving many files
> * consume a lot of space on the device
> * are time-consuming to produce
> That's why a specific icon theme is often (re)used by several meta themes.
> And of course you don't want to copy icon themes into every single meta theme
> folder that they get reused by and of course you don't want to work with
> symbolic links either.
> This and the fact that icon themes are able to inherit other iconthemes makes
> packaging the icons on a "per single content folder" base quite problematic.
> So this needs to get somehow dealt with.
> Am Samstag 06 Juni 2009 11:04:40 schrieb Stephan Arts:
> > On Thu, Jun 4, 2009 at 3:59 PM, Rodney Dawes <dobey.pwns at gmail.com> wrote:
> > > On Wed, 2009-06-03 at 09:19 +0200, Stephan Arts wrote:
> > >> On Tue, Jun 2, 2009 at 7:47 PM, Rodney Dawes <dobey.pwns at gmail.com>
> > >> > The biggest issues I see, are icon themes, cursor themes, and sound
> > >> > themes. These are currently installed in separate paths from other
> > >> > theme bits, and cursors and icons are both under icons, which is yet
> > >> > another issue. I think the best way forward is to probably get the
> > >> > specs for those themes updated to install under themes/$NAME/$type
> > >> > first, with the current paths listed for backward compat, but as
> > >> > deprecated, before getting some spec together that either moves them
> > >> > all to some other place independently, or requires lots of code to
> > >> > magically install/uninstall them to/from the correct places listed
> > >> > in the respective specifications.
> > >>
> > >> Agreed. So, for the locations we would have something like this:
> > >>
> > >> $XDG_DATA_DIR/themes/$NAME/$type
> > >>
> > >> where type can be anything, but has reserved names for:
> > >>
> > >> icons
> > >> cursors
> > >> wallpapers
> > >> sounds
> > >>
> > >> which are dedicated to sound-themes, wallpapers, cursors and icons.
> > >> Other dirs could be:
> > >>
> > >> gtk+2.0
> > >> metacity
> > >> xfwm4
> > >>
> > >> What do you think?
> > >
> > > I think we need to get the specs changed (I don't think there is a
> > > proper spec for X cursors though). I don't know what KDE does for kwin,
> > > KDE, and QT themes, but we'd need to get them changed to be similar as
> > > well.
> > AFAIK, there is no proper spec for X-cursors, and the X cursor
> > implementation seems to be considered buggy. And KDE... it's a bit
> > messy:
> > /usr/share/kde4/apps/color-schemes/
> > ~/.kde/share/apps/desktoptheme/
> > Regards,
> > Stephan
> > _______________________________________________
> > xdg mailing list
> > xdg at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/xdg
More information about the xdg