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.
Thanks