From Tango Desktop Project
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

Visual review

This section is for discussion about the appearance of the icons.

Drop shadow

It would be better not to use one below the icons, because a shadow looks often messy when the icons are on buttons or tool bars. In some cases (e.g. draw-rectangle) it even seems like the icon has not been cut out of its background properly.

As shadows are not mandatory for Tango icons (not even when they are draw in on-the-table perspective), removing them wouldn't break with the style guidelines either. --Markus

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:


  • align-bottom-vertical, align-top-vertical: Those are inconsistent with the other alignment and distribution names as those have "vertical" or "horizontal" as second part of the name and the position as third one. Moreover, a few alignment variants are missing (align-horizontal-right, etc.).
  • 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. dobey says "input-*" is only for HIDs (human interface devices) which scanners are not, so this icon should probably be renamed to "scanner" and be removed once the 0.9 version of the spec is released.


  • 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 :)
  • extract-foreground-objects: This is a selection tool, so maybe it would be better to use "select-" instead of "extract-" as prefix.
  • page-magnifier: The naming spec uses zoom-* for similar actions (zoom-in, zoom-out, zoom-original etc.), so I vote for using "page-zoom" instead of "page-magnifier". (I actually think that the "page-" prefix is unnecessary either, but we shouldn't just name it "zoom" in order to prevent zoom-* falling back to this icon.)


  • 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: Refer to an action which opens a preference dialog, so it should probably be brought in line with stuff like "configure-grid" (or KDE's configure-shortcuts, configure-toolbar) and named "configure-color-management". Or, going even further, maybe something like "preferences-graphics-color-management" (in the apps category, like the other preferences icons) would be an even better way to go.
  • print-size: I think this has nearly the same purpose as document-page-setup which is defined in the naming spec. You should probably consider dropping this icon and using the specified one.


  • 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)

Getting Art Libre Set

How does one download the Art Libre Set? I've looked around and I can't find any reference to download or cvs access. Thanks. --Wahooney 09:31, 21 March 2008 (PDT)

The module is tango-art-libre in CVS. Just use "co tango-art-libre" instead of "co tango-icon-theme" in your cvs command line. -- dobey

Creative Commons?

It would be nice if ArtLibre used the same license as Tango so I could use it in my creative commons-only site. Regards. --tardigrade4 05:46, 07 April 2008 (EST)

If anything, the license will be changed to LGPLv2+ for both the Art Libre set, and tango-icon-theme. We are not going to place Art Libre under Creative Commons Attribution ShareAlike 2.5 for any reason. The current license is suitable for using the icons on a web site. -- dobey