[kde-artists] Re: Icon Name Standardization, second draft

[Danny Allen]

I think I should through my ideas in to the pot here...

A while back, I had a quick go at creating a standard icon naming scheme:
http://www.kde.me.uk/index.php?page=KDE-SINS

I created it to have the least impact on existing kde apps. Though not 
finished, I believe it to be a good start. I maintain an icon set myself, and 
so know about all the current problems with apps defining arbitrary icon 
names! :)

Thanks,
Danny

On Tuesday 29 March 2005 04:47, Andrew Conkling wrote:
> Hi folks,
> I'm glad to see that there are a handful of people ostensibly interested
> in getting an icon theme spec underway.  I've been contributing to the
> GTK+ portion of an icon theme (Lila: http://lila-theme.berlios.de) and
> that's been enough work, let alone trying to carry such efforts across
> DEs.
>
> As such, I approach this topic from a themer's standpoint, for better or
> worse.  After reading the spec, a few things come to mind that will need
> to be addressed.  Please bear in mind that I have very little knowledge
> of KDE and its theming.
>
> 1. I'm not sure of the state of the "Standardized Icon Names", but
> offhand I know that there are a number of names used by apps that are
> missing (namely stock icons).  I'm assuming this list is incomplete?  Is
> it meant to be (eventually) a list of centralized names to which apps
> will have to conform to be themed properly?
>
> 2. Many times I have had to copy an icon file to a new name just for one
> app's errant naming.  For the Lila project, we have aimed to be
> complete, but this means, for example, that we end up having a half
> dozen "Close" icons with different names.
>
> Might I propose an alias layer to these themes?  For example, anyone
> familiar with GTK+ theming knows the iconrc file tries to take care of
> this to some extent.  The problem is that they are bound to the GTK+
> theme, not to the icon theme.  If we could have some of this
> functionality in icon themes, it would go far to easing transition to
> conformance to this spec.
>
> We could go ahead and make a short list of icons (yay, designers have a
> less daunting task, i.e. fewer icon files to make) and our apps will
> still be themed properly (yay, users can enjoy the themes), even though
> they may refer to the icons using deprecated names (yay, app developers
> don't have to rush to conform).  Seems like a win-win.  If we like this
> idea, we can discuss details later; I just wanted to throw it out there.
>
> 3. I know it's blurring specs, but icon themes only work (at the moment)
> in menus if .desktop files refer to icon names implicitly, e.g.
> Icon=firefox instead of Icon=firefox.png or
> Icon=/usr/share/icons/hicolor/48x48/apps/firefox.png.  I think something
> should be mentioned to this end because many distros roll their
> own .desktop files that trash an icon theme's ability to work.
>
> 4. What happens when an app has a good reason to add an icon not
> specified?
>
> 5. Assuming #4 will happen, can we make some mention of some explicit
> communication between the developer and the themer?  A handful of times,
> I (not a developer) have been told to muck around the code looking for
> icon names to theme (even with such a big project as Evolution).
> Something like this would be nice to add to the "Conformance" section:
> "Any icons you deem to add must be documented and distributed with the
> source."
>
> Of course, we'll have to preface that heavily with discouragement on
> doing so. :)
>
> So there are my (rather) skewed comments and reflections.  While I
> haven't really touched on some of the questions and comments others have
> made, in many ways mine are the same questions and issues that got me in
> touch with Frans in the first place.  While this spec is a big step in
> the right direction, it still has room to improve as far as this themer
> is concerned.
>
> Let's make it great!
>
> Warm regards,
> Andrew Conkling
>
> ___________________________________________________________________________
>___ kde-artists at mail.kde.org | 
> https://mail.kde.org/mailman/listinfo/kde-artists