Hi,
redhat-artwork has way too many build requirements and unrelated content.
I've split it up in a bunch of little packages and filed review requests for each one.
You can see them all here:
https://bugzilla.redhat.com/showdependencytree.cgi?id=305441
Once they get in, I don't plan on working on them much (basically just an initial push to fix whatever broke in the split). If anyone wants to be the upstream (and downstream) for one or more of the packages that's fine with me.
Jeremy is currently working on getting them all hosted.
Note, there will probably be a lot of issues initially. The split wasn't hard work, but it was very redundant and time consuming, so I'm sure I introduced more than a few regressions.
Just thought I'd give everyone a heads up.
--Ray
On Tue, Sep 25, 2007 at 04:17:44PM -0400, Ray Strode wrote:
redhat-artwork has way too many build requirements and unrelated content. I've split it up in a bunch of little packages and filed review requests for each one.
Hey, cool. I hadn't noticed that was being done. Thanks for the hard work -- this is very helpful.
Matthew Miller wrote:
On Tue, Sep 25, 2007 at 04:17:44PM -0400, Ray Strode wrote:
redhat-artwork has way too many build requirements and unrelated content. I've split it up in a bunch of little packages and filed review requests for each one.
Hey, cool. I hadn't noticed that was being done. Thanks for the hard work -- this is very helpful.
Yep. Good work. This would potentially help the art team continue to ship older themes on newer releases since some end users prefer that.
Rahul
On Wed, 2007-09-26 at 02:36 +0530, Rahul Sundaram wrote:
Matthew Miller wrote:
On Tue, Sep 25, 2007 at 04:17:44PM -0400, Ray Strode wrote:
redhat-artwork has way too many build requirements and unrelated content. I've split it up in a bunch of little packages and filed review requests for each one.
Hey, cool. I hadn't noticed that was being done. Thanks for the hard work -- this is very helpful.
Yep. Good work. This would potentially help the art team continue to ship older themes on newer releases since some end users prefer that.
This is really cool -- I really like the DNA theme, unfortunatelly, unlike the gdm theme, its desktop backgrounds are no longer present in subsequent redhat-artwork packages. At the first glance none of this packages contain it either. It would be really nice if we had packages with pictures from older themes. Anyone would package those, or mind if I did that?
Lubomir Kundrak wrote:
This is really cool -- I really like the DNA theme, unfortunatelly, unlike the gdm theme, its desktop backgrounds are no longer present in subsequent redhat-artwork packages. At the first glance none of this packages contain it either. It would be really nice if we had packages with pictures from older themes. Anyone would package those, or mind if I did that?
It was said many times we want to have available background from old releases, maybe even 1 or 2 releases back included in the default install, for those who like those better than the current.
Probably the wrong place to ask this, but I am not subscribed to the art list. Will the old artwork be touched up where necessary to go for the more "unbranded" style (I think) fedora has been moving towards?
(first thoughts - Bubbles and FedoraDNA have the logo build in as part of the background artwork, so can't/shouldn't change. But flying high just has the name written on top,but not as part of the image. It probably can be removed if Fedora goes down this road.)
Lubomir Kundrak <lkundrak <at> redhat.com> writes:
This is really cool -- I really like the DNA theme, unfortunatelly, unlike the gdm theme, its desktop backgrounds are no longer present in subsequent redhat-artwork packages.
I'd really like a working FedoraDNA KDM theme (the same reasoning applies to GDM too), for a simple reason: some users want to turn off the user list (or "face browser" as the GNOME folks call the same feature), and the newer themes have a blank placeholder where the user list should be if you disable it, which looks ugly. So we should keep at least one Fedora* theme without the user list working.
Kevin Kofler
Kevin Kofler wrote:
I'd really like a working FedoraDNA KDM theme (the same reasoning
applies to
GDM too), for a simple reason: some users want to turn off the user list (or "face browser" as the GNOME folks call the same feature), and the newer themes have a blank placeholder where the user list should be if you disable it, which looks ugly. So we should keep at least one Fedora* theme without the user list working.
People on the Art Team have experience mostly with GNOME theming, but if you come to the art list with the request and provide some handy KDM guides, there may be someone wanting to work on it.
Nicu Buculei <nicu_fedora <at> nicubunu.ro> writes:
People on the Art Team have experience mostly with GNOME theming, but if you come to the art list with the request and provide some handy KDM guides, there may be someone wanting to work on it.
For the old themes like FedoraDNA, all that should be needed is the backgrounds being still there.
What does need work for KDM is the new Infinity theme though.
Kevin Kofler
On Wed, 2007-09-26 at 12:15 +0200, Lubomir Kundrak wrote:
On Wed, 2007-09-26 at 02:36 +0530, Rahul Sundaram wrote:
Matthew Miller wrote:
On Tue, Sep 25, 2007 at 04:17:44PM -0400, Ray Strode wrote:
redhat-artwork has way too many build requirements and unrelated content. I've split it up in a bunch of little packages and filed review requests for each one.
Hey, cool. I hadn't noticed that was being done. Thanks for the hard work -- this is very helpful.
Yep. Good work. This would potentially help the art team continue to ship older themes on newer releases since some end users prefer that.
This is really cool -- I really like the DNA theme, unfortunatelly, unlike the gdm theme, its desktop backgrounds are no longer present in subsequent redhat-artwork packages. At the first glance none of this packages contain it either. It would be really nice if we had packages with pictures from older themes. Anyone would package those, or mind if I did that?
The old packages should be available in cvs, so anybody with sufficient interest can take the source, and package up the part he is interested in. Using Rays packages as guideline for package naming and spec file should make this very easy.