Re: Industrial in 2.10?

[Andrew Johnson <ajgenius ajgenius us>]

On Fri, 2004-12-03 at 19:13 -0500, Seth Nickell wrote:
> > [luca redrum GNOME_HEAD]$ head gtk-engines/ChangeLog
> > 2004-12-01  Thomas Wood <thos gnome org>, Andrew Johnson
> > <ajgenius ajgenius us>
> > 
> >         * Update version to 2.5
> >         * Remove pixbuf and notif engines, and misc other files
> >         * Move crux, hc, industrial, mist, thinice engines over from
> >           gnome-themes and gnome-themes-extras
> >         * Replace configure.in with configure.ac
> 
> 1) Dare I utter the F word? AFAIK, the gnome-themes maintainers were not
> consulted about this change (I wasn't, but maybe Calum was). 

I would not have even considered pushing for engine separation had not
calum agreed(he seemed to be the active maintainer!), and he also cc'd
Bill H. IIRC. (Note that gnome-themes still contains the engines in
question until things stabilize)

> 2) I don't see why this is a sensible change. Themes are not just a GTK
> theme, or just an icon theme, etc. A theme is a combination of these
> elements. Moving GTK engines into separate module would just be a pain.
> It means you have to sync between modules. E.g. it means if we want to
> create a new GNOME theme we have to coordinate between modules to get
> the gtk-engine into the module, etc.

Because gtk-engines are NOT just part of any ONE theme, nor are they
used exclusively by gnome themes. There is nothing even remotely
GNOME-Theme specific about libraries to theme GTK+. In fact apart from
crux every single engine included is used by many themes, and apart from
hc often used under non-gnome desktops. Should all themes on art sites
then all also include include the engines which they use?  folly! The
entire point of problem is dependency, engines are not exclusive to one
theme, even when they are created initially for one in particular. 

And why on earth would you have too "sync" between modules. The default
theme will be with the engine in gtk-engines, non-default themes in
gnome-themes hardly need care about anything other then the fact the
engines is available at all. The entire point is to have any major theme
engine popular enough to warrant it in gtk-engines. Hardly every theme
requires its own engine, very few do in fact, so if a particular engine
is popular enough to warrant it, it should already be IN gtk-engines by
the time it is needed by any theme popular enough to warrant being in
gnome-themes, and if not, it is hardly a major stumbling block too add
it. 

Again the reason for the separation is DEPENDENCY, currently GTK+
engines are used by many themes under many situations, not all including
gnome, and moreover right now it already causes dependency problems and
headaches for those distros which supply theme engines as separate
modules, because we then have conflicting packages providing the same
things! By separating all engines into one location the problem can be
solved by allowing individual engines to be built as individual
packages, and have the main gtk-engines package become a virtual package
depending on said packages and providing nothing but the .pc file.

> 3) If somebody wants to actively fix bugs in the engines, etc, I would
> welcome that and be happy to have them maintain the engines in the
> module.

This is has nothing to do with it. Maintaining it is of course a
problem, and a secondary reason, by ensuring that at the least thomas
and I always maintain things if no one else does. But the primary
concern has been and will be dependency. GNOME has no business screwing
around including non-gnome packages which should technically be in it's
dependencies, this solves the problem for everyone once the configure
system has been properly completed to support it.

> 4) That the themes have not changed is partly a good thing. A blooming
> of lots of themes is not a desirable situation. Its too stale to date.
> At the point that I drew up the existing themes many of the great
> options we have today were not available. But I still want
> conservativism in adding new themes (or, e.g., remove a theme every time
> you add one :-)
> 

Again not our concern. We aren't in this to change themes(though we very
much think things do need to change) but to solve engine dependency
headaches and provide a central repository for otherwise non-maintained
gtk-engines. I currently believe we have too many themes in
gnome-themes, I think it should contain no more then 3 semi-reasonable
default metathemes, and that the a11y themes should be there own package
of JUST the semi-reasonable default a11y themes. We can hardly include
15-20 themes (and not all are even complete metathemes!) and claim we
are only including just sane defaults. But since I have no control over
that I leave it in other peoples hands for now and stick with solving
other headaches.

Andrew