From Tango Desktop Project
Revision as of 14:41, 11 November 2007 by Jpetso (talk) (Diplomatic wording is always important.)

Jump to: navigation, search

Shouldn't basic/generic icons for 3D tools be supported too, as it's not uncommon to see them on most users desktops nowadays ???


Please add 3D related icons to he list, if you have time. --Alexandre

Name review

As we need some of these icons for KDE 4, I had a look at the ArtLibreSet. Equipped with a good grasp of different icon sets and naming schemes, I came up with a couple of suggestions that should hopefully improve this set and unify names with KDE where sensible. As follows:


  • cleanup: I think edit-clear (from the CVS version of the spec that will become 0.9) is the same thing as this. Don't know though, as there is no description.
  • display-filters: The specification tends to use singular forms wherever possible, which I think would be reasonable here. Moreover, various filters are spread all over KDE, and I doubt that this icon needs to be different from those. So, how about renaming this icon to "view-filter-display"? view-filter would then be the more general fallback that is automatically used if view-filter-display is not available (and that's what we'll probably use for the KDE filter icon). Of course, in case you feel that there doesn't need to be any distinction, you could use plain view-filter also for this icon - depends, I'm not the great graphics guru.
  • flip-horizontal, flip-vertical: I think those should be removed because the naming spec already defines object-flip-horizontal and object-flip-vertical.
  • transform-flip-horizontal, transform-flip-vertical (from Transformations): Likewise.
  • image-properties: I think it would be best to drop this icon and use the spec's document-properties instead. If that's not an option, you should at least consider fallbacks and rename this to document-properties-image.
  • item-clone, item-duplicate: given how "object" is used for most of the similar icons (object-(un)group, object-(un)locked, and the flip/rotate icons from the naming spec), I think it would be appropriate to have object-clone and object-duplicate instead.
  • media-seek-prev-cut, media-seek-next-cut: Naming them media-seek-{forward,backward}-cut would get you sensible fallbacks for every theme that conforms to the naming spec, as media-seek-{forward,backward} is specified there. If you want to keep your icons separate (because the standard media-seek icons are too general, or whatever), media-seek-cut-previous and media-seek-cut-next would probably be better names. (At least, you should spell out previous as a whole.)
  • merge-down: Maybe it would be a good idea to standardize on the "layer-" prefix and rename this one to layer-merge? After all, there's no merge-up anyways, so the "down" doesn't necessarily need to be in the name.
  • node-delete-segment, node-join-segment: Be aware that those fall back to node-delete and node-join if this specific icon is not available in the current theme. Which might not be what you want, because segments are not nodes. In order to prevent this, I suggest renaming those two icons to node-segment-delete and node-segment-join respectively.
  • page-copy, page-delete: imho, those are clear candidates for renaming to something that falls back to the naming spec's edit-copy and edit-delete. In other words, those should be named edit-copy-page and edit-delete-page instead.
  • paste-in-place, paste-style: Those too are specialized versions of the naming spec's edit-paste, and should be named edit-paste-in-place and edit-paste-style.
  • save-to-channel: Refers to a specific object (the selection) without including that object in the icon name. So, this should probably be named selection-save-to-channel.
  • select-all: Duplicate of edit-select-all from the naming spec, this should be removed in favor of the "official" one.
  • select-shrink: Didn't you want to name this selection-shrink? It has little in common with the other select-* icons.
  • other select-* icons: Those should be named edit-select-* instead. There's no edit-select specified, so you don't need to fear generic fallbacks.
  • shrink-wrap: Operates on the window, and should therefore be named window-shrink-wrap.


  • input-scanner: The CVS version of the naming spec defines "scanner" (without "input-"), which is conflicting with this one. I think "input-scanner" is more appropriate, but in any case this inconsistency should be worked out in collaboration with the spec maintainers.


  • color-fill: I feel this is too specific - what about patterns or other fill tools? So my impression is that "fill", the tool category, should be first, and "fill with a color" a specialized form of this tool. That's also what you do with the draw-* tools, and would make or better consistency. Therefore, I propose "fill-color" for this icon.
  • color-gradient: Realizing that gradients are just another fill tool, I'd rename this to "fill-gradient". You can see the above reasoning does work :)
  • color-picker, clip-splitter: Most of the other icons use verbs instead of nouns, so I think color-pick and clip-split would be more appropriate. Although, this is minor nitpicking, feel free to ignore this suggestion as it's not too important.
  • extract-foreground-objects: This is a selection tool, so maybe it would be better to use "select-" instead of "extract-" as prefix.
  • page-magnifier: I vote for using the naming spec nomenclature and call this simply "zoom". Because the spec already defines zoom-in, zoom-out, zoom-original etc., and this is the "general" zoom tool - the mother of all zooms, so to say.


  • scale-image: This is clearly a more specific form of transform-scale (applied to images specifically), so it should really be named transform-scale-image instead. Or maybe the need for distinction between a "general" and an image resize is not that pressing, and you could drop scale-image in favor of transform-scale in the first place.
  • transform-crop-and-resize: "resize" sounds to me like "scale", and even the non-scaling method is performed anyways when cropping an image. I think that including "resize" is both unnecessary and confusing, and that the icon should just be named "transform-crop" instead.
  • canvas-size: Is this not the exact same thing as cropping, just with a dialog instead of a tool? Imho this icon should be dropped in favor of the (newly renamed) "transform-crop" icon.
  • layer-to-image-size: The most important part of this action is "Shrink layer", where "shrink" is not included in the icon name. I would propose to have this named "layer-shrink-to-image-size" (that way, it's also possible to add further "Shrink layer" actions in the future, e.g. "layer-shrink-to-selection").
  • transform-rotate-90, transform-rotate-270: Clashes with object-rotate-right and object-rotate-left from the naming specification. Please remove those from the set and use the specified ones instead.
  • transform-rotate-180: No idea what this icon should even look like, but if you really feel it's worthwhile to keep it then I'd ask to rename it to object-rotate-180 (or maybe you can find some textual description for 180 degrees.)
  • color-management, print-size: As those refer to actions which open a preference dialog, they should be brought in line with stuff like "configure-grid" (or KDE's configure-shortcuts, configure-toolbar) and named "configure-color-management" and "configure-print-size".


  • mode-*: Not really self-explaining, I'm thinking that "color-space-*" would be a more appropriate name for the color mode icons.
  • layer-visible: Duplicate of "visible" (in Toggles). I don't think there need to be two different "visible" icons, so my suggestion is to drop this in favor of the other one.


  • chain-locked, chain-unlocked: Inconsistent with object-(un)locked and object-size-(un)locked further down the list. I think "object-ratio-(un)locked" would be better name here.
  • hidden, visible: Despite the obvious generic purpose, I think those should wear a prefix. The most generic prefix is "object", and (depending on the point of view) one could even argue that a layer is also an object, at least in the sense of "something that is editable". So, what about renaming those to object-hidden and object-visible?
  • show-guides, show-scrollbars, show-rulers: Those don't need to be in the plural form, and singular would be more consistent with other stuff and more logical for apps that only use one ruler for example.
  • switch-foreground-and-background-colors, switch-to-foreground-and-background-defaults: As I don't find that "switch-" is a good prefix, I would propose to standardize on the already existing "color", and rename those icons to "color-switch-foreground-with-background" and "color-switch-to-defaults" respectively.

That's it... phew. Hope this is useful for you, and that some (if not all) of the stuff in here can be incorporated into the ArtLibreSet list.

Jpetso 06:39, 11 November 2007 (PST)