Adds Invisible and Transparent icons

[sn4k3]

Adds special icons:

• Invisible: Do not display the icon, and do not reserve space for it in layout.
• Transparent: Do not display the icon, but reserve space for the element in layout. (Default icon)

The Transparent is now the default icon since common use is to have element size untouch when change icon.

• Fixes Allow for Null/Empty #58

Other fixes

• Fix the lack of IconSize property on avalonia design time, causing error due two constructors and taking IconAnimation as precedence.
• Fix inproper use of MaterialIconExt as control in avalonia design time

Please review:

• Naming?
  • Invisible and Transparent, they represent the real action and expectancy but together they can be confusing
• Alternatives?
  • Transparent -> None (Maybe None is more clear to diferenciate?)

[SKProCH]

I thought about this issue too

I think that we just need to make the Kind nullable, this is perfectly handles the case with "transparent" default icon, while also making user's life easier to just pass null instead of making specific branching logic/converters. And for "invisible" user can just utilize the Visibility=false/Collapsed without reinventing the wheel.

What do you think?

[sn4k3]

I also tought about going nullable, but I went this road because offers more flexibility and I don't like nullable enums 😅 It's more common pratice to have Invalid/None/Empty as first enum value than using null enums.

With this is route user can:

• Set default icon app-wide with a style, this allow to define whatever he prefers the "null" icon to take the layout size or not (Could be usefull)
• One less binding for IsVisible as it can be controlled with icon, yet can still be used.
• It opens the path for future tokens or icons, IDK

Code-wise, the coverage for null will be more "stressful"
Yet I'm fine with both approaches as end-user.

I'm tagging @fls-eugene as he raised the issue, what is your preference?

[SKProCH]

Yeah, I can understand your position

Set default icon app-wide with a style, this allow to define whatever he prefers the "null" icon to take the layout size or not (Could be usefull)

With a nullable approach users can achieve the same.
We can also add the style to threat null as not visible (but not as default variant)

One less binding for IsVisible as it can be controlled with icon, yet can still be used.

But we blurring responsibility here I think. Currently enum contains only actual icons, without leaking the viewing layer "variants" kinda.

Also, we adding the styles (or triggers) check to all icons instances only to handle a very specific rare, almost nonexistent usecase. Yes, this is not a something very compute intensive, but should we really waste compute to handle such rare case?

This is a corner case which behaves differently from all other icons.

Also we need to think what we should do with a MaterialIconTextExt with Invisible/Transparent icon. I'm not sure that we actually just need to hide only the icon (and keep text visible). Not handling this in a such way allows us to not bother with such things.

Code-wise, the coverage for null will be more "stressful"

Nah, the nullable reference types handles it fine I suppose

---

Tbh, currently I still prefer the nullable approach, but I've open to discussion. Let's wait a little and see if somebody (fls-eugene?) writes something about this

[sn4k3]

Maybe we can commit a null branch and compare?

Also we need to think what we should do with a MaterialIconTextExt with Invisible/Transparent icon. I'm not sure that we actually just need to hide only the icon (and keep text visible). Not handling this in a such way allows us to not bother with such things.

I think it only should apply to icon as we are dealing with Icon properties anyway.

[y0ung3r]

In Avalonia, there are built-in ways to achieve what you’re aiming for:

• Opacity hides the element visually but still reserves space for it in the layout
• IsVisible removes the element from the layout entirely (no space is reserved)

The community has grown accustomed to these standard Avalonia mechanisms, and it would be more appropriate to stick with them rather than introduce a new API that requires additional maintenance, documentation, and consideration when implementing new features.

Moreover, introducing Transparent and Invisible values would forfeit certain optimizations built into Avalonia. For example, animations might continue performing CPU-bound work behind the scenes, even when the icon isn’t visible (whereas with IsVisible = false Avalonia typically suspends such animations).

Overall, adding functionality that is already conveniently achievable via standard means is strongly discouraged.

The above concerns equally apply to the nullable approach as well.