[Change Request] Allow custom calendar events to specify Font Awesome icon styles

[Antra]

What problem do you want to solve with this change?

The customEvents configuration currently assumes that all symbols use the default Font Awesome style (fas fa-fw fa-).

This works well for the majority of icons, but some Font Awesome icons belong to other styles, such as Brands (fab). For example, tesla or facebook are Brands icons and therefore cannot be used through customEvents with the default symbol handling.

Changing defaultSymbolClassName globally to fab fa- is not a suitable solution, since that breaks all the normal Solid icons.

Although symbolClassName exists as a calendar configuration option, it cannot currently be specified per customEvent, meaning a calendar cannot use both normal Solid icons and icons from another Font Awesome style in its custom events.

What do you think is the correct solution?

I think customEvents.symbol could support an optional style prefix while keeping the existing syntax fully backwards compatible.

For example:

{
    keyword: "Birthday",
    symbol: "birthday-cake",
    color: "Gold"
},
{
    keyword: "Tesla",
    symbol: "brands:tesla",
    color: "Blue"
}

A symbol without a prefix would continue to use the current/default symbolClassName, while a symbol containing a prefix could specify the Font Awesome style to use.

For example:

birthday-cake

would continue to resolve using the default Solid classes, while:

brands:tesla

could resolve to the appropriate Brands classes.

This would provide a generic solution rather than adding special handling for individual icons, and would allow other Font Awesome styles to be supported in the same way if needed.

Participation

• I am willing to submit a pull request for this change.

Additional comments

I have tested a possible implementation locally using the following syntax:

{
    keyword: "Tesla",
    symbol: "brands:tesla",
    color: "Blue"
}

The implementation checks whether symbol contains a : and, when present, uses the prefix to construct the appropriate Font Awesome class. Existing symbols without a prefix retain the current behaviour.

I would be happy to submit a pull request implementing this if the proposed approach is acceptable.

[sdetweil]

See the doc for the

symbolClassName

Property. In the list for a specific calendar url configuration

[Antra]

Thanks! I did look at symbolClassName, but as I understand it, that property applies to the entire calendar URL configuration rather than to individual customEvents.

My use case is to have different Font Awesome styles within the same calendar. For example:

customEvents: [
    {
        keyword: "Birthday",
        symbol: "birthday-cake",
        color: "Gold"
    },
    {
        keyword: "Tesla",
        symbol: "tesla",
        color: "Blue"
    }
]

Here birthday-cake is a Solid icon (fas), while tesla is a Brands icon (fab). Setting symbolClassName: "fab fa-" on the calendar URL makes the Tesla icon work, but then the normal Solid icons no longer work.

So I was proposing a way for the individual customEvent.symbol to specify which Font Awesome style should be used, rather than changing the style for the entire calendar.

[sdetweil]

ah, that selectivity wasn't clear in the prior wording..
so it uses the symbol and prefix of the matching custom event
I think it would be better to have an overriding symbolClassName property for that custom event..
then its always the same property base, or CE (no hidden : to remember to process) , and we have a method to get propertybyName from CE

[Antra]

Ah yes. That makes sense.

Having symbolClassName as an optional property on the custom event would be cleaner and more consistent with the existing configuration, while allowing the custom event to override the calendar-level value.

For example:

{
    keyword: "Tesla",
    symbol: "tesla",
    symbolClassName: "fab fa-fw fa-",
    color: "Blue"
}

while existing custom events without symbolClassName would continue to use the calendar's default.

I agree that this is preferable to introducing special syntax into symbol. I'm happy to implement it this way.

[sdetweil]

Go for it!!

Base your changes on the develop branch

[Antra]

I've implemented this as discussed and opened a PR: #4257

The PR adds an optional symbolClassName property to custom events, with fallback to the calendar-level configuration.
I've also added an E2E test and verified the Tesla icon works on my actual MagicMirror.

[sdetweil]

Awesome!