The future of HiColor

[James Richard Tyrer]

Henrique Pinto wrote:
> Em Sáb 18 Jun 2005 23:33, James Richard Tyrer escreveu:
> 
>> For the application icons, the old HiColor icons (which were moved 
>> to KDE Classic) should be moved back to HiColor.
> 
> 
> If I understood you correctly, this means either:
> 
> * Users would need to install kdeartwork to get hicolor support; * 
> All kdeclassic icons would need to be re-added to the KDE packages 
> they were in before the theme switch, making the packages even bigger
>  than they are now (except kdeartwork, of course)
> 
> I don't think the first option would solve the problem. And I 
> _really_ don't like the second option. I see no reason to distribute 
> two complete icon themes with all KDE packages.
> 
Actually, it is only the HiColor app icons for the menu that would need
to be in the package with the apps.  Other HiColor icons could be in the
KDEArtwork package if the larger package size is an issue.
> 
>> Where HiColor icons were installed as "crystalsvg" this should be 
>> corrected.
> 
> Agreed. Crystal equivalents of them should be made, and they should 
> be moved to kdeartwork or wherever KDEClassic/HiColor icons end up 
> being.
> 
But till there are Crystal equivalents, they should be installed as
HiColor.  Otherwise, artists are not going to find that the icons are
missing.
> 
>> I would not install any Crystal style icons as: "hicolor".  I don't
>>  know how many apps don't have either a KDEClassic icons or an old 
>> HiColor icon that has gone missing (probably still somewhere in 
>> SVN).  I would expect that it wouldn't be very many.  We will need 
>> to make new HiColor icons for these.
> 
> In theory, I agree with you. However, your proposal would mean making
>  most KDE packages bigger, by containing two different version of 
> every icon (hicolor and crystalsvg).

As I said above, there are two issues.  There are the app icons which
need to be in the package with the app and then there are the other
icons which can be in KDEArtwork.

> I agree with you that crystalsvg icons don't fit the "hicolor" 
> definition. But installing crystalsvg icons as hicolor would solve 
> the interoperability problem with other desktops without hassle for 
> KDE users. (I mean, this would solve the interoperability problem if 
> users prefer any icon over no icon at all.)
> 
> I think the whole "hicolor" idea is not very good.

Perhaps, but it has been posted as a standard and GNOME supports it.

> Perhaps a better way of solving the problem would be having generic 
> icons and specify fallback generic icons in apps' .desktop files, 
> i.e., Kate, for example, would have "kate" as it icon and 
> "text-editor" as generic icon. If no "kate" icon exists in the 
> currently used theme, then the generic "text-editor" icon is used. If
>  a list of generic icons is agreed upon and major desktops' default 
> icon themes implement all of them, I think this can work very well.

I have previously suggested that the: "Icon=" tag should support a list 
of icons which would be searched for in order so that in you example you 
could have:

	Icon=kate,editor,text-editor

Yes, this would also help with this issue as well as resolve the 
specific vs. generic icon debate.

If you used this on GNOME, it would then pick up the GNOME HiColor icon: 
"text-editor" if KDE didn't have an "editor" icon.

NOTE: we also need to resolve that "-" issue as GNOME icon names contain 
them -- standardized icon names are going to have to decide on whether 
to use "-", "_", or "".

It works for MIME types as well:

	Icon=svg,vectorgfx,image

and probably issues which we haven't thought of yet.

-- 
JRT