Re: central location for bluecurve gtk engines



I think having a way in configure to specify to build just the gtk2
engine is an important thing to have, but having configure fail because
you don't have qt installed is a real pain.

Alex


On Tue, 2002-10-08 at 23:30, Havoc Pennington wrote:
> Alex Duggan <aldug astrolinux com> writes:
> > 
> > I would like to make a formal request that the gtk1 and gtk2 bluecurve
> > engines be maintained in a more central way that allows non-redhat users
> > to more easily build them for their system.  Currently, a user has to
> > extract the tarball from the redhat rpms and do some hackery to install
> > just the gtk engines on their system.  As far as I know, everything in
> > the redhat-artwork rpm is GPL, so redistribuation should not be a
> > problem under the terms of the GPL.  I propose that the engines be in
> > gnome cvs and released versions go on the gnome ftp site.  I also think
> > that it should be considered for inclusion in GNOME 2.2.
> > 
> 
> I was talking with Garrett about this just today. The "redhat-artwork"
> package is intended to include a complete neutral "metatheme" covering
> Qt, Mozilla, XMMS, and whatever else in addition to GNOME, so I don't
> think we want to put it in GNOME CVS. However we can probably put it
> up on a Red Hat server (sources.redhat.com or i18n.redhat.com) and
> make tarballs available.
> 
> Before doing this, I want to add a --with-theme-name=Foo option to the
> configure script, however. The reason is that the name "Bluecurve" is
> a trademark and can't be used for commercial purposes. If Garrett
> agrees we might use the name "Wonderland" as the generic name of this
> theme.  So the tarball distribution would default to "Wonderland"
> instead and we will use --with-theme-name=Bluecurve in Red Hat.
> Wonderland was the original working name for the theme, some people
> will remember this from the beta releases.
> 
> For convenience of people who want only the GTK themes, I'd also be
> open to having configure check for the presence of each library (Qt,
> GTK etc.) and not compile the themes for stuff that isn't found.
> (--disable-gtk or --disable-qt type options are also possible).
> 
> Anyway, yes, we are working on doing this. I'm fooling with packages
> that add menu editing to 8.0 first though. ;-) And building a fix for
> the dup-o-rama bug: http://bugzilla.gnome.org/show_bug.cgi?id=94625
> 
> Havoc
> 
> _______________________________________________
> gnome-list mailing list
> gnome-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-list




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]