Common icon themes

Fri Nov 8 18:08:43 GMT 2002

On Friday 08 November 2002 7:11 pm, Alexander Larsson wrote:
|  On Fri, 8 Nov 2002, Antonio Larrosa Jiménez wrote:
[...]
|  > So we have to install app icons only to one place:
|  >
|  > 2.1) If we install them to hicolor, then we're breaking the whole idea
|  > of icon themes (as most of the crystalsvg's apps icons would be inside
|  > hicolor instead of where they should be in the crystalsvg directory, and
|  > evenmore, action/mime/devices icons would still be in the crystalsvg
|  > directory). That would be a real mess. Think also about kde installing
|  > crystalsvg icons for mozilla into hicolor and gnome installing its own
|  > mozilla icons (with the gnome look) into hicolor. Doesn't make sense
|  > neither.
|
|  KDE should not install the mozilla icon to hicolor. Mozilla itself should.
|  KDE can install it to crystalsvg of course.

May be, we should have common icon set for different applications, including 
Mozilla?
I am not sure where Mozilla (packaged by some distribution) should install its 
icon. Installing own icon into 'hicolor' is not that bad, BTW.
Current mozilla installs some icons into /usr/lib/mozilla/ and 
/usr/share/icons/:
[vad at VPlessky vad]$ rpm -ql mozilla | grep icon
/usr/lib/mozilla/icons
/usr/lib/mozilla/icons/mozicon16.xpm
/usr/lib/mozilla/icons/mozicon50.xpm
...
/usr/share/icons/large/mozilla.xpm
/usr/share/icons/mini/mozilla.xpm
/usr/share/icons/mozilla.xpm

*without* creating special folder for those icons, or using default folder.

On the other hand, package 'gnome-mime-data' installs  icons into
/usr/share/pixmaps/document-icons/
and 'libgtk+2.0_0-devel' installs a lot of  PNG images (which look like icons 
to me) at 
/usr/share/gtk-doc/html/gtk/

And Nautilus2 installs icons into
/usr/share/pixmaps/nautilus
(/usr/share/pixmaps/nautilus/sierra/, /usr/share/pixmaps/nautilus/gnome/, 
/usr/share/pixmaps/nautilus/default/, etc.)

|
|  > 2.2) That means we should install them to crystalsvg. But then we're
|  > back to the problem that (e.g.) konqueror.png would only be in
|  > crystalsvg and so when gnome's panel finds konqueror.desktop it won't
|  > find konqueror.png because crystalsvg is not in gnome's icon theme list.
|  >
|  > Perhaps (rewriting my previous idea), we should use a FORCEICONTHEMES
|  > env. var. that forces each desktop to append those icon themes at the
|  > end of the icon theme list. That way, it can contain
|  > FORCEICONTHEMES=crystalsvg:gnome
|  > and each desktop could remove icon themes which are duplicated in their
|  > respective icon theme list.
|  > Of course, each distribution could set that env. var. accordingly to the
|  > installed packages. Or maybe we should use a config file to store those
|  > things.
|  >
|  > In any case, I think 2.2 is the way to go.
|
|  This is a non-solution for several reasons:
|
|  a) It won't work for novice users that just want to use gnome apps from
|  kde or kde apps from gnome. They have to set up some strange environment
|  variable to make it work. Lots of people won't do this, but just complain
|  that it's "broken". If a distribution is forced to always set it then
|  we're just wasting env-var space in every process for something we should
|  just handle automagically.
|
|  b) People on the xdg-list violently opposed to sharing the namespace
|  between the desktops. And this is exactly what this will cause. Gnome will
|  get the mimetype/action/etc icons from KDE, and KDE will get the
|  mimetype/emblems/etc from Gnome. Chances are high that the names collide
|  and you get an icon you didn't expect. It also means that icon lookup will
|  be slower and use more memory because each desktop needs to read in all
|  the (non-application) icons that you normally don't use from the other
|  desktop.

What about creating list of common apps (and mimetypes) for both GNOME and 
KDE, and managing one complete set of icons (Reference Icon Theme) for both 
GNOME and KDE?

With list of common apps (app names) in place, we can avoid collisions.

|
|  c) You've been saying all the time on your webpage and here that apps are
|  supposed to install icons to hicolor, now you suddenly say they should
|  install in crystalsvg? Aren't we back to step 1 then? (I.E. what if KDE
|  wants to change the default theme again?)
|
|  > > and with an external package owning the hicolor theme so that it can
|  > > be shared.
|  >
|  > Ok, then I'll commit in the following days an icon-themes-base cvs
|  > module to kde's cvs where we can keep hicolor's out of kdelibs and any
|  > other dependency. Is that ok?
|
|  Maybe we should put it in cvs on freedesktop.org, and the tarball next
|  to the spec. In fact, I already have a tarball of the default theme there.
|  I think all you need to do is s/default/hicolor/ and we'll be all set. In
|  practice the package won't ever change, so it won't be a pain to
|  coordinate.

Well, my effort with BlueSphere icon theme was exactly to extend Hicolor theme 
(and repalce icons with bad design by completly new ones)

Can you pls download and test this tarball:
http://freetype.newmail.ru/svg/BlueSphere-0.2.tar.bz2  (3.3MB)

Some screenshots (KDE apps so far):
http://freetype.newmail.ru/svg/BlueSphere-kmail.png
http://freetype.newmail.ru/svg/BlueSphere-knode.png
http://freetype.newmail.ru/svg/BlueSphere-konqueror.png

Sources (SVG files):
http://freetype.newmail.ru/svg/BlueSphere-0.2.1.tar.bz2
(bzip2 successfully compressed 1.2MB traball into 55KB .bz2, don't be confused 
by its small size, there are 170 files there)

For several reasons, I don't like look'n'feel of Crystal icons, so I started 
to work on a set of own icons. And my goal is to make it desktop-independent 
(as far as possible), WM-independent, shared among different projects.
I develop those icons in SVG format from the beginning (in Sodipodi), 
reference renderer is rsvg_display from librsvg2 (unfortunately, it can't 
handle all of those icons at a moment, so I have to export some of them in 
PNG format from Sodipodi, and than rescale)
As librsvg2 is native renderer in Nautilus2, I hope Nautilus would be able to 
render it natively as soon as librsvg is fixed.

-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/