[kde-artists] Re: Icon Name Standardization, second draft
dannya40uk at yahoo.co.uk
Thu Mar 31 14:44:38 EEST 2005
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:
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
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
> 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
> 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
> 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 |
More information about the xdg