Re: Planning the release 2.10 of themes - part 1

[Andrew Johnson <ajgenius ajgenius us>]

I replied to this several days ago but evo seems to have eaten it.. so I
will try and summarize what I said then.

On Fri, 2004-11-05 at 11:40 +0100, Luca Ferretti wrote:
> Il giorno lun, 01-11-2004 alle 17:30 -0500, Andrew Johnson ha scritto:
> > On Fri, 2004-10-01 at 10:53 +0200, Luca Ferretti wrote:
> 
> > > --- Additional engines ----
> > > 
> > > A theme engine is not simply a control option. But a control option
> > > needs one (or more) engine to be "referenced".
> > > 
> > > A theme engine is not related to GNOME, it's related to GTK+. But GNOME
> > > uses it to provide control options.
> > > 
> > this isn't entirely true. theme engines can use traditionally gnome
> > dependencies such as gconf, and in fact for a few minor options, I plan
> > on adding just that too smooth. there is also the potential for adding
> > librsvg or libart support to an engine, which is not strictly "just"
> > gtk.
> 
> I didn't consider this case. Interesting. But engines that now are in
> gnome-themes and gnome-themes-extra should use only plain gtk/gdk, isn't
> it?
> 

In substance yes, but thats not the entire point, the main point I was
making was if an engine could potentially have a partial-depend aka
compile-time options for gnome modules, then it should be high enough in
the gnome depend path that it can reasonable depend on them. Whereas
gtk-engines should _always_ only depend on gtk+. which means engines
would never be built with anything gnome support, even if built for a
gnome install.

> Of course we need a different approach for Smooth-NG when it will depend
> on GConf. 
> 

Again this would be a PARTIAL depend. if someone wanted to compile it on
a system without anything but GTK+ they would be able to continue to do
so.

> The first idea in my mind, is:
>       * move engines in gtk-engines (this is a fixed point)

I asked owen about this and he doesn't want any new engines in
gtk-engines, and in fact has no plans to maintain it either. His
preference would be to move the pixmap engine into GTK+ proper, and then
just let the gtk-engines module die. But this still wouldn't happen
until gtk+ 2.6, which means we really should have a new module, for eg.
gnome-theme-engines, which is low enough in the compile chain it can
still be easily installed without too much more then gtk+, librsvg,
gconf, and maybe libart. If a solution is to be found it needs to be NOW
while there is still a slim chance of a new module being accepted into
2.10

>       * install a .pc file for each installed engine, rather then for
>         the whole package

Way to complex, if we are to provide these engines then they all of them
should always be available. In which case a simple version check against
the single .pc to see if its a version which is known to have the right
engine is available.

>       * of course let Smooth depends on GConf, so don't compile it if
>         GConf is not installed, but don't fail the compilation of others

Again. BAD idea. make this optional, if smooth can work without gconf it
should, but by default it should be high enough in the dependency that
it can have it if its available, aka automated gnome build.

>       * make each theme in gnome-theme depend on related engine(s). So,
>         for example, don't compile and install Glider if smooth-
>         engine.pc is not available. Of course if Glider will be the
>         default GNOME theme and smooth-engine.pc if not available, break
>         the compilation and suggest to check gtk-engines installation.
> 
Again, only need on .pc, and make the entire gnome-themes and
gnome-themes-extras depend on a specific version of it.

> IMHO is an acceptable behavior: GConf is a core GNOME library, but it's
> low level (it don't needs gtk+, but only glib).
> 
> 

I disagree. The main problem being if this is a gnome module, then its
going to primarily be in a gnome install, if someone wants to compile it
themselves outside of the gnome install order they can, and we should
have some reasonable chance of success even if gconf for example isn't
available, but the primary target should be the gnome desktop itself.

> > > The route is simple: 
> > >      1. move HC, Smooth, Thinice, Industrial (it's in
> > >         gnome-themes-extra), Crux, LightHouseBlue and Mist engine code
> > >         in gtk-engines 
> > 
> > Important question to consider, who will maintain this? owen has
> > traditionally been the maintainer of gtk-engines, but due to his other
> > responsibilities he has barely touched it in years, if you plan on
> > adding all these engines to it, you had better have a lined up a
> > replacement maintainer people can agree on and owen is willing to hand
> > the problem over too. I have contemplated seeing about taking over
> > myself, but regardless it should be thought about.
> 
> I suppose that people that now maintain engines in gnome-theme* can do
> it if the engine is in a different location.
> 
> Of course a super-maintainer is needed for releases and other admin
> tasks, and to start implement to stuff.
> 
> Any volunteer?  Maybe we could ask on gnome-devel and gtk-devel. I'm not
> subscribed to the second one, can you send a message linking to this
> thread?

Like I said, since owen doesn't want anyone else touching gtk-engines,
and it may die anyway, I think we should make a gnome-theme-engines
module, of which the super maintainer can be myself or Thomas Wood or
Link Dupont from art.gnome.org, for example. Someone who is already
involved anyway. I offer myself mainly because I already know most of
the internals of most of the engines because I have gone through so many
of them in the past, and so am suitable to make fixes, and apply patches
if any arise. Thomas is also a good choice since he already has cvs
access and is maintaining the gnome-wallpapers module. 

I am of course open for other volunteers or more qualified people but I
am already working on making this module and should have it done very
soon. I have also started working on revising several of the engines for
a standard file layout to simplify maintenance. I am not including them
in this first release because I am not sure which modules are still
maintained outside of the gnome tree and don't wish to make someone
else's life difficult if they would then have to sync changes.

> 
> 
> > >      2. eventually remove Redmond95 and Metal (do we really still need
> > >         them?)
> > 
> > Redmond yes, metal no. I rewrote redmond over a year ago(hasn't made it
> > into gtk-engines because of owen's busy schedule).
> 
> Is it on bugzilla?
> 
I believe so but I am not sure of the bug number at the moment. I will
include the most recent version in my working gnome-theme-engines.

> >  The main reason for
> > it is integration and familiarity. Providing a theme by default that
> > converts are comfortable with. For example I use redmond as a theme on
> > one linux box among many windows boxes, with a similar panel layout to
> > windows defaults, to help ease the transition for those who use it but
> > are used to windows. I would in fact like to have a complete Redmond
> > gnome theme, gtk, icon, and mcity for this reason included in
> > gnome-themes.
> 
> Why don't use the plain GTK engine? The only big differences I can see
> now between Redmond95 and Traditional is the color scheme. 
> 

It is ugly. Plain and simple. Almost every windows user I know
personally agree, the gtk default is ugly, and not as clean. Redmond is
very basic, and simple, but it is nevertheless very clean. When it comes
down to it, GTK+ default doesn't look very much like Redmond IMO, and in
this case its highly a subjective debate, and thus is a good enough
reason for me.

> > >      3. add documentation about engines for theme makers. They need to
> > >         know available options without read the code.
> > > 
> > 
> > This I would potentially agree with, and that is why Thomas Wood and I
> > have started merging things from my own wiki over to live.gnome.org in
> > the art.gnome.org section covering these topics.
> 
> I was thinking about something installable. But as gtk-doc (so more
> developer oriented) or as yelp manual (so more end user)?
> 
Oh I of course agree. The intent has always been to use the wiki as the
place for the community to develop and edit the initial documents which
would then be imported into a more distributable format.

> Maybe I'll grab your stuff... By now I've to finish the Italian
> translation of coreutils %-)
> 
> > > Put here only the engine code and a minimalistic gtkrc. You need a gtkrc
> > > file to make the engine available, but provide it "as is". Ideally use
> > > the GTK+ default colors and settings. Oh, maybe call it "xxx-engine"
> > > 
> > 
> > Maybe yes maybe no. Some engines this makes some sense for others it
> > doesn't, for example redmond obviously has a very specific default look,
> > Smooth does not. Industrial has a very specific look, but xfce does not.
> > 
> > Presuming a default theme for a configurable theme engine, offers more
> > problems with confusion then its worth. If you want to provide all major
> > theme engines great, but don't muddle them up with "default" themes as
> > well when you don't need too. 
> 
> Yes, this is really controversial and KDE-oriented: the engine changes
> the appearance of widgets, the color scheme changes, well, the color
> scheme. But GTK+ don't separe them, and you can use more then one engine
> for a control option.
> 
This isn't at all what I meant. Smooth isn't just one look, it provides
many different types of looks via configuration flags, and there is no
default widget style. It can be made to look like bluecurve to some
extent, like flat, like thinice or mist to a degree, it can also to some
extent mimic redmond even. None of these are by any means its "default"
look, so I see no reason for even including any default theme at all
either. 

Additionally why should we include gtk themes in theme-engines, if we
aren't going to include mcity themes with mcity? It seems rather
inconsistent. In My opinion the gtk themes should go into gnome-themes
as well.

Anyway here is my current module, crux isn't in there because it does
some weirdness I want to change to make it compile a little more
normally.

http://ajgenius.us/Code/gnome-theme-engines-2.10.0.tar.gz

 I have, as I said, reworked elsewhere the Industrial, HC, and ThinIce
code layout to be more consistent with how Redmond is currently set up,
and if no one objects later on if this module gets accepted I can change
them as well.

Additionally all per engine AUTHORS need to be included, and the main
AUTHORS, README, NEWS etc written as well.

Some engines don't have any sort of license header and others aren't
clear, so I also would like to see if I cannot get the
license/copyright/authors info consistent in each engines files
eventually to make sure its all clear what license and what author etc.

-- 
Andrew Johnson <ajgenius ajgenius us>