Read the statement by Michael Teeuw here.
Three module issues from a new user
-
@skyfall I found this post exactly because of that icon, lol
Have anyone made it work? changing fas to fal does the job for the Canadian maple leaf icon but breaks the others :(
-
@sdetweil said in Three module issues from a new user:
// if there is a space in the name, ‘collectionname iconname’ use the string as is
// for example “fa-brands fa-canadian-maple-leaf”
// else use the current approach
symbol.className =(s.indexOf(’ ')>0?s:( “fas fa-fw fa-” +s));This works perfectly in calendar, however in the CX3 module it does not work, apparently spaces are not allowed
-
it would have been nice if the fontawesome 4 prefixes weren’t hardcoded into the module sources/templates. Would have made changing the icons to something else in so much easier.
-
@kayakbabe I agree.
I went to line 448 and 449 of MMM-CalendarEXT3.js and edited this
exDom.classList.add('symbol', 'fa-solid') exDom.classList.add(...event.symbol.map((s) => {return 'fa-' + s}))
I did it once but since the update I had to reinstall the whole MagicMirror and lost the changes, I did not realized I did not backup that part of the code. I don’t remember what I did but I removed fa-solid and made something that changes fas and fab. based on config.js.
Very similar of what it’s explain on this topic, but I can’t make it work anymore. Sorry for diverting the thread. We should talk about this on a new post as I’m talking about an extension.
FontAwesome is already at version 6. It would be nice if MagicMirror in the future considers a flexible version in case of future updates, where you can choose in config.js if you want “fas” (by default) of “fab” :beaming_face_with_smiling_eyes:
-
-
I’ll swing it back to this thread…
I got access to the extra fontawesome 6 by just copying the contents over the font awesome 4 in the vendors folder. NOT the right way to do it because it will get wiped out if I ever update my mirror. Correct me if I"m wrong, but I think it should have been a subfolder in the mm css folder in order to preserve it.
Also I copied the provider file for openweathermap.js (and gave it a new name) and changed the constants for the weathertype to the following.
(note, i have access to the pro fontawesome so I can use the duotone icons in my mirror).
/* * Convert the OpenWeatherMap icons to a more usable name. */ convertWeatherType(weatherType) { const weatherTypes = { "01d": "fa-duotone fa-sun", "02d": "fa-duotone fa-sun-cloud", "03d": "fa-duotone fa-cloud-sun", "04d": "fa-duotone fa-clouds-sun", "09d": "fa-duotone fa-cloud-sun-rain", "10d": "fa-duotone fa-cloud-showers-heavy", "11d": "fa-duotone fa-cloud-bolt", "13d": "fa-duotone fa-snowflake fa-spin-pulse", "50d": "fa-duotone fa-sun-haze", "01n": "fa-duotone fa-moon-stars night", "02n": "fa-duotone fa-moon-cloud night", "03n": "fa-duotone fa-clouds-moon night", "04n": "fa-duotone fa-cloud-moon-rain night", "09n": "fa-duotone fa-cloud-showers night", "10n": "fa-duotone fa-cloud-moon-rain night", "11n": "fa-duotone fa-cloud-bolt night", "13n": "fa-duotone fa-snowflake fa-spin-pulse night", "50n": "fa-duotone fa-cloud-fog night" };
I think these used to be configurable for the old weather modules in the config.js, but now they are constants defined in the provider file. Make sense because each profider sends differnt weathertype codes and it would be really confusing for people help one another. But then you have geeks like us who ust keep digging and we can usually figure it out maybe with nudges in the right direction.
For Openweathermap (OWM) those constands/weathertypes are based on the “icon” info that OWM sends. I thought about changing that to use the codes that OWM provides since ErikFlowers weathericons now have so many more weathericons and he actually provides a definition for the OWM codes to his icons too.
I did the kickstarter to help Fontawesome create 6, so have all the paid version 6 icons too without subscription fees. I love their weather duotone icons and they do work on the mm if the css is set correctly. They work in the calendar too. I’m sure they’d also work with the same fixes in the third party modules. I think a lot of folks just used the default modules as models of how to build their own so a lot of the hard coded stuff (that should have been config enabled instead) just carried through to their own modules.
All of us need to remember that Mich did this for himself and knew what he wanted. I probably would have hard coded it myself in that situation. We are lucky we have free access to what he began and gave to the public for free. I’m so glad he did. This is a great learning project with a great looking usable end product.