I have been looking over the approach to icons for a bit and I think there are some improvements to be made, this issue contains my suggestions.

The current implementation is pretty "locked" in its implementation, as it maps 82 enum variants to embedded asset paths. This leaves two main issues:

1. If you want more than 82 icons in your application, you have a problem
2. If you want an icon in your application which does not have an appropriate IconName, you must pick a "spare" option and remember this mapping throughout your application

Another, but somewhat separate issue is that multiple components utilize icons internally, which are only rendered when the icon is present in the loaded assets, even though the button that "contains" the icon is still rendered. My best example of this is the close button for a sheet, which is just a Ghost variant button with no text or icon, making it difficult, if not very unlikely that you actually discover (unless you subscribe to log events and see the errors for failing to get the icon). I personally think it would make sense to always have these icons available in the crate, as they are "essential" in some way.

My suggestion is to add a new public trait that requires a .path method to be implemented. The Icon is changed to take anything that implements this trait as input. Then this trait can be utilized by users of this crate to implement their "own" IconName, which can contain however many icons they like, with whatever name they desire. The current IconName from this crate can still be kept as a sensible default.

This way, the essential icons could also be embedded and enabled elsewhere, outside of the current IconName, to ensure they would not interfere with users of this crate (although that may go against the desired behaviour of overwriting these essential icons).

I think an implementation of just the trait would be quite simple, and if it sounds reasonable and is desired I can implement it.