[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: crystal icons to hicolour for external applications
From:       Frans Englich <frans.englich () telia ! com>
Date:       2005-06-07 10:11:45
Message-ID: 200506071011.45631.frans.englich () telia ! com
[Download RAW message or body]

On Tuesday 07 June 2005 01:44, James Richard Tyrer wrote:
> Jonathan Riddell wrote:
> > On Mon, Jun 06, 2005 at 07:58:45PM +0100, Richard Smith wrote:
> >>On Monday 06 June 2005 16:56, Jonathan Riddell wrote:
> >>>Should KDE applications not released with the main KDE (KOffice,
> >>>extragear and everything outside KDE SVN) install icons to hicolour?
> >>>
> >>>This would be incase KDE changes its default icon theme from Crystal.
> >>>Applications inside KDE would be fine because we can rename those
> >>>along with the KDE schedule but applications outside KDE's release
> >>>schedule would find themselves without any icons if the user installed
> >>>a KDE version that had a new icon theme as the default one.
> >>
> >>Could we instead install the crystal icons as crystal, and do some
> >>automake/unsermake magic to automatically create a symlink pointing at
> >> the crystal icon if the corresponding hicolor icon doesn't exist?
> >
> > Maybe, but it wouldn't achieve anything over just installing in
> > hicolour, and it would be move complex.
>
> That should be obvious.  The situation you have now with KOffice is that
> the Crystal icons are installed as HiColor and if you already have
> installed HiColor app icons for KOffice:
>
> http://www.kde-look.org/content/show.php?content=24415
>
> And then you update KOffice, your HiColor app icons get overwritten with
> Crystal style app icons.
>
> There is only one good solution for this.  KDE should fully support
> HiColor (unthemed) icons. 

Yes, that sounds sensible, and that's what Jonathan set out to do -- that KDE 
applications install _at least_ hicolor icons(AFAICT). Every application 
should out of the box have hicolor icons, in order to play well with the icon 
theme spec and environments other than KDE.

In practice, it means that applications' Makefile.amS should install hicolor 
icons(and crystalsvg if available); any hicolor icons should not be in a 
separate package or similar.

hicolor is not a theme in the traditional sense. It is an area which arbitrary 
applications install icon into, which ordinary themes(such as crystalsvg) 
fallbacks to if they can't serve a particular icon themselves; hicolor is the 
default theme.

hicolor doesn't have a certain "style"; KDE's old hicolor theme had. One 
doesn't have control over hicolor since arbitrary applications installs into 
it(it's hence not themed), so trying to use it as a theme is asking for 
trouble.

If someone wants a particular theme, start a new one which fallbacks to 
hicolor, and in there craft a certain style. That's easiest, especially for 
the authors of that theme(because they can, say, override icons in hicolor).

I don't see the advantage of installing KDE's old hicolor icons into hicolor 
instead of Crystal svg icons, since the latter is more KDEish, prettier(that 
appears to be the common opinion), and better represent KDE since crystal svg 
is closely tied to it(a branding perspective).

In practice, this means:

1. In either case, ensure icons are installed into hicolor.

2. Ensure that it's crystalsvg icons that are installed into hicolor since 
that's the best we have. Or if people don't like that, install old hicolor 
icons.

3. If anyone feel like it, start a "second generation" hicolor which is a 
_real_ theme. Perhaps it has a resemblance to KDE's old hicolor theme and 
uses those icons as a base -- or whatever people feel like.

What was FUD, where was I wrong?


Cheers,

		Frans

[prev in list] [next in list] [prev in thread] [next in thread]