Hello! When updating some bits of UI in xwiki-platform, I happened to run multiple times in the same problem: the current XWiki Icon Set does not have the icon I want.
I compiled the instances where I ran in this issue in the past months. Here is my main proposal:
The reasons I want to add those icons are on the design page mentionned above. The mapping in itself is not perfect but thatâs the closest I could get with the limited icons in the different themes.
This unique link does not reflect enough the importance that this list has in actually using icons when developing interfaces from experience, itâs difficult to find it when new to the project. I think we should update it to
AFAICS, this list is pretty stable and important for our design, and the design page itself is not a draft anymore, so it doesnât make sense to label it as a draft anymore.
Do you agree with those icon additions? Do you have an idea on how we could emphasize the importance of this list in the doc?
I think we need some consistency in the names. For example caret-left and move do not look consistent. Move is quite generic and could be about lots of things (moving a page to another location for example). What about prefixing all âarrowâ operations with arrow to indicate thereâs a notion of arrow in the icon?
The icon for move seems weird for silk as itâs a left arrow.
The icon for resize-horizontal seems weird for silk as I donât see whatâs horizontal in the chosen icon
2 icon names donât have a mapping for some icon themes and I think we need the mapping to be complete as otherwise it wonât work.
I donât agree with this fix, because I think a strength of the icon set is the easiness of the names. Systematically adding prefixes will make using this feature more difficult than it needs to be. AFAIK we donât have specific icons for moving pages or moving attachments in the iconset so this lack of specificity is not an issue. I agree that caret-left and move have different naming conventions (based on the character vs based on semantics), but itâs something thatâs already in the iconset with âaddâ and âcaret-rightâ for example. I donât think this is much trouble for devs so Iâm in favor of keeping things the same.
Unfortunately, silk was created in 2005 and not updated for a long time, so thereâs some huge holes in its icon theme cover. When checking out a list of the icons in silk, I could not find anything closer to those we would expect for those actions.
I think itâs more important to have an icon set that can represent a variety of icons, even if silk is a bit left behind. If we donât provide enough icons in the set, devs will need to:
hard code icons, defeats the purpose of having an icon set (see Loading...).
Regarding silk shouldnât we just start deprecating it? As you said itâs starting to get old, and I think weâre all more relying on FA those days than on silk. IMO it would make sense to deprecate it and stop bundling it in the future, maybe when we move to 16.x or 17.x.
Youâre right, I did only check the documentation page, which was out of date, but the mappings in FontAwesome.xml and Silk.xml do have values that are not mentionned hereâŚ
Iâll move this list to the icon theme documentation and update it so that it fits what we currently have.
The point is that the name should be about what the icon represents and not about a concept since otherwise 1) weâll have namespace problems and 2) different icons can be used for the same concept (e.g. use one icon for âmove pageâ and another icon for âmove attachmentâ or âmove a panelâ).
I didnât say that we shouldnât add these icons but we need an acceptable mapping for the other icon sets. This is crucial as otherwise the whole concept of icon set goes away (if you can only use a single icon theme).
Well, it means we would not be able to use the Elusive icon set. If we donât want to support it, then we shouldnât list it. However, I think itâs a good idea to list it and to perform the mapping as it offers a proof that the new icons can have mappings in several icon sets and thatâs important. So yes IMO we do need to make the effort of providing mappings for all icon sets, just as a proof that we can find mappings and thus that we are not adding an icon that is too specific to one icon set.
This was not my point. My point was that we need a mapping for the bell icons, for all icon sets.
Sounds good generally speaking, but could you explain precisely what you mean by deprecating? I think we need to make sure that contrib extensions (or custom code) continue to work if they use Silk. Does deprecating mean that when using Silk in future XWiki versions, the UI would get broken? IMO, one simple solution that could be acceptable would be that each icon set could provide a default icon when no mapping exists for a specific name. That would allow Silk to continue âworkingâ (even if it would be with icons not nice) in the future, at a low cost.