Most of the python config tools (system-config-*, anaconda) include their own copies of bluecurve icons. It makes sense to me that they should use system icons whenever possible, to match the current theme.
See https://bugzilla.redhat.com/show_bug.cgi?id=291261 for an example patch for one of the tools.
Do other people think this is worth fixing across the board?
Bill
On Fri, 14 Sep 2007 12:51:03 -0400 Bill Nottingham notting@redhat.com wrote:
Do other people think this is worth fixing across the board?
Yes, reduce the size of packages! Make it easy to swap in non-trademarked branding!
On Fri, 2007-09-14 at 12:51 -0400, Bill Nottingham wrote:
Most of the python config tools (system-config-*, anaconda) include their own copies of bluecurve icons. It makes sense to me that they should use system icons whenever possible, to match the current theme.
See https://bugzilla.redhat.com/show_bug.cgi?id=291261 for an example patch for one of the tools.
Do other people think this is worth fixing across the board?
My personal opinion is yes since this not only will make Fedora look consistent, it will benefit distro spinners who wish to change themes overall, as well.
The problem is they have to be filed as bugs against each package (with maybe one bugzilla entry depending on the resolution of all those bugs), and it would probably be marked with a lower priority. --
Richi Plana
On Fri, 2007-09-14 at 12:51 -0400, Bill Nottingham wrote:
Most of the python config tools (system-config-*, anaconda) include their own copies of bluecurve icons. It makes sense to me that they should use system icons whenever possible, to match the current theme.
+1 to making it match/use the current theme, but -1 to using generic system icons.
Pulling the individual icons out of the packages and into redhat-artwork (or perhaps system-config-artwork?) is fine, but I still think the distinctiveness of their icons versus the generic control panel icons is a good thing.
Ignacio Vazquez-Abrams (ivazqueznet@gmail.com) said:
On Fri, 2007-09-14 at 12:51 -0400, Bill Nottingham wrote:
Most of the python config tools (system-config-*, anaconda) include their own copies of bluecurve icons. It makes sense to me that they should use system icons whenever possible, to match the current theme.
+1 to making it match/use the current theme, but -1 to using generic system icons.
Pulling the individual icons out of the packages and into redhat-artwork (or perhaps system-config-artwork?) is fine, but I still think the distinctiveness of their icons versus the generic control panel icons is a good thing.
The problem is that doesn't actually help - you'd need to do a version of the icon for each theme, which is something I'd like to avoid.
Right now, you boot up a *stock* desktop, and you have the gnome icons (in the GNOME style), the config tool icons (in the bluecurve style), and the puplet icons (in the echo style). That's *ugly*.
Bill
On Fri, 2007-09-14 at 14:13 -0400, Bill Nottingham wrote:
Ignacio Vazquez-Abrams (ivazqueznet@gmail.com) said:
On Fri, 2007-09-14 at 12:51 -0400, Bill Nottingham wrote:
Most of the python config tools (system-config-*, anaconda) include their own copies of bluecurve icons. It makes sense to me that they should use system icons whenever possible, to match the current theme.
+1 to making it match/use the current theme, but -1 to using generic system icons.
Pulling the individual icons out of the packages and into redhat-artwork (or perhaps system-config-artwork?) is fine, but I still think the distinctiveness of their icons versus the generic control panel icons is a good thing.
The problem is that doesn't actually help - you'd need to do a version of the icon for each theme, which is something I'd like to avoid.
Right now, you boot up a *stock* desktop, and you have the gnome icons (in the GNOME style), the config tool icons (in the bluecurve style), and the puplet icons (in the echo style). That's *ugly*.
A lot of these tools have larger interface issues than non-matching icons, though...
Matthias Clasen (mclasen@redhat.com) said:
Right now, you boot up a *stock* desktop, and you have the gnome icons (in the GNOME style), the config tool icons (in the bluecurve style), and the puplet icons (in the echo style). That's *ugly*.
A lot of these tools have larger interface issues than non-matching icons, though...
That's a much large patch. Unless you're talking just blocking the packages from the distro entirely. Which I'm not averse to.
Bill
On Fri, 2007-09-14 at 12:51 -0400, Bill Nottingham wrote:
See https://bugzilla.redhat.com/show_bug.cgi?id=291261 for an example patch for one of the tools.
Good approach, but I would suggest that instead of falling back to the bluecurve icon, it should fall back to some generic icon in the icon theme. Thereby reducing the dependency on bluecurve. We can't expect all theme-makers to create icons for the various applets, apps, etc. and a fallback default icon is a good remind of what's missing that still looks okay. --
Richi Plana
Richi Plana (myfedora@richip.dhs.org) said:
On Fri, 2007-09-14 at 12:51 -0400, Bill Nottingham wrote:
See https://bugzilla.redhat.com/show_bug.cgi?id=291261 for an example patch for one of the tools.
Good approach, but I would suggest that instead of falling back to the bluecurve icon, it should fall back to some generic icon in the icon theme. Thereby reducing the dependency on bluecurve. We can't expect all theme-makers to create icons for the various applets, apps, etc. and a fallback default icon is a good remind of what's missing that still looks okay.
The bluecurve icon in this case is in the package itself.
Bill
On Fri, 2007-09-14 at 12:51 -0400, Bill Nottingham wrote:
Most of the python config tools (system-config-*, anaconda) include their own copies of bluecurve icons. It makes sense to me that they should use system icons whenever possible, to match the current theme.
See https://bugzilla.redhat.com/show_bug.cgi?id=291261 for an example patch for one of the tools.
Do other people think this is worth fixing across the board?
Yeah, it's probably worth doing. And at the same time, switching to using the fdo standard icon names[1] is also worthwhile where doable.
And as an added benefit, it makes the code quite a bit simpler.
Jeremy
[1] http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.ht... -- most of system-config-* are from before the existence of the spec, so the fact that they don't follow it is hardly surprising