Hi Rodney, On Fri, 2007-02-16 at 10:59 -0500, Rodney Dawes wrote: > On Fri, 2007-02-16 at 00:08 +0200, Naba Kumar wrote: > > Hi, > > > > I just noticed that many text file mimetype icons found in > > gnome-icon-theme version 2.14 are missing version 2.16. For example, in > > 2.14, there are: > > > Please tell me if this is just work in progress with the new icons set > > or some political agreement to remove all distinction between the file > > icons. > > No. Most end users are going to almost never have to deal with source > code, or lots of various other specific types.
I agree with you that most normal users wouldn't see source files, but I think number of developers (and development tools) are still significant to take them into account in GNOME Desktop's overall usage plan. Frankly speaking, there are fewer normal users than power users using GNOME Desktop for now :), so it is still a safe bet to support them. > Also given that so many > people who do write applications, create new specific types, it makes it > incredibly hard, annoying, and tiresome to draw icons for specific > types. We don't necessarily have to support them all. Having the most common ones in default theme should be sufficient. I mean in free software world, source files are everywhere. We can't possibly ignore them. > For example, with C, C++, H, JS, and other similar types, you're > basically going to end up with the same icon used over and over again > anyway, with the only difference being an emblem of the letter "C" or > whatever, on top, or you're going to end up trying to shove too much > into the icon. > That is still a vast improvement over white square rectangles. As I see, the point of the icons is to give visual identification of the files and blank+emblem still satisfies it quite well. In fact, I see that as an advantage because it can be automated with a script to create most of those icons. > However, we do want to provide sets of specific icons external to the > default theme, for various types of users. The "artist", "developer", > "musician" and similar sets, which one can drop in to ~/.icons/ and > will Just Work to allow the users that need those icons, to have them. The problem with that is that no one is going to bother installing them (let alone figure out it needs to be installed in the first place). So putting the icons outside 'default' theme is just not going to work. The icons need to be default fallback when current theme doesn't have it. Along your lines of thoughts, what I propose is to split the default theme into several packages, like: gnome-icon-theme gnome-icon-theme-developer gnome-icon-theme-music etc. They would all be part of same 'logical' default icons (so that they won't have any overlapping icons), but just split for the sake of priorities. You can give more focus on the first one and leave the others to be improved as time allows. And the general GNOME desktop dependencies only uses the first one. The applications that rely on the specific default themes can then 'safely' set a dependency on them. As usual, the users (developers) can then override it with other fancy themes. As a start, I would propose putting the gnome-icon-theme-2.14 missing icons in the new gnome-icon-theme-developers module. I am not an artist, but I am willing to create the module as kick start (and also to restore the missing icons for now in Anjuta). May be Vinicius Depizzol could also help it with his nice icons. Thanks. Regards, -Naba _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
