2 ways:
– wait for an official default theme with colors appropriate for you;
– wait for a custom theme which you may more or less like - then wait for official docs about “how to add a theme, how to edit a theme” - or find someone’s step-by-step instructions.
The 2nd way: since currently Dev say that “only 2 vars are officially supported” → means “use other variables for your own risk” → then what docs are we talking about? probably only common steps like “how to add a theme” (w/o explanations for each variable) may be documented then…
I think that since UI elements are changing (which is GOOD generally) → then list of supported variables may change too → so maintaining a list of variables in docs could be a not easy task.
May I also voice my concern about this change.
The changes to state color does not make any sense. The contrast is terrible.
Now, are we expected to do this manual custom theming or is it going to change/revert back in the future?
I feel like this change should’ve stayed in the beta and not part of the actual release.
I hope that whoever came up with new colour scheme, will go to petrol station and be welcomed with all the labels changed to slightly different shades of blue with tiny fonts for diesel / petrol / high octane - and then labeled as toxic when he/she says that it was a dumb move.
I can’t see that this theme approach helps with the colouration of zones, or am I missing something? I’m a bit fed up with Green for home, grey for not_home or blue for everywhere else.
Sorry, can’t help you with that. I did not use the theme until now, first I want to set up a test system where I can test new releases to protect my daily use system.
My biggest issue is the history graphs. Off is the same colour as Unavailable. On is both orange and blue depending on if it’s a sensor or a switch(?) – On should be always the same colour. Thin bars of orange are much harder to see than the previous thin bars of green.
Can I change these in a relatively straight forward manner, or should I wait for customisation options?
That’s actually not only a color problem, but a rendering problem. The way they render the timeline bars is incorrect. Antialiasing will blur the colors together at the edge of each bar transition from one color to the next. If a bar is very thin, this reduces contrast a lot more than it would simply with the colors. You can see this by yourself by taking a screenshot of a history timeline and zooming into it. In my history explorer card, I specifically managed the timeline rendering in a way to keep high contrast at the color edges, even for thin bars. The HA devs didn’t do that.
You could use the custom card I linked to above to replace the native history, it’s has fully configurable colors and lots of nice other stuff too, I promise (shameless plug, sorry).
I too am struggling to see state changes on some cards.
My custom cards are fine, but the core cards, notsomuch.
I appreciate the steps towards making the colour selections easier to customise for theme developers, however I think it would have made sense to retain the previous colour selections in the core pallette so users can deviate away if they wanted.
Idea:
It would be great if there was a page in settings which had all the domains and state options with their default colour selections and from there allow users to select alternate colour for each as desired or necessary.
And any outliers being defined manually as before with css/card-mod or custom cards.
OK, I should clarify, I was saying that the dev said a documents page was coming soon to themes. Sorry, I don’t think there will be a UI page in the near future. My brains not firing yet and I missread your message.
Still, it’s a step in the right direction so we can get in there and get tinkering
Thanks again. Looks like you guys have had a rough couple of days.
Some… “passionate” people out there
I’ve been admin on a couple forums. I bet the private mod chat area’s been busy.
With that, I appreciate all you guys do to try and steer the threads back on point.
Normally it’s a thankless task, but thank you guys
Nothing that hasn’t already been said, but given the situation felt it important to stand up and be counted.
I don’t care for the color choices, but as I roll my own I don’t really care what you choose as long as I am able to achieve my own design objectives. A very big thank you to the Dev that offered to provide some documentation on the new direction.
That said, how they chose to do it is puzzling at best. Gaining more control over the colors et.al. is great, but I have a feeling it won’t be long until this needs to be re-factored. And, I am now wishing I didn’t accidentally stumble on WHY they made this change, because it is just stunning.
In the interest of keeping things constructive, I would like to suggest that from time to time it might be helpful to get outside guidance on big application architecture decisions.
Lastly, while it may “technically” not be a breaking change, anything that has this big of an impact on such a large part of your user base warrants far more communication than was given ahead of the change.
This is just a hobby for me, but I really do greatly appreciate the project and all the people that spend so much time and energy keeping it great
@ HeyImAlex Thanks for your work! And I did take notice of your earlier post about your add-on. I might have the time to tinker with these coming holidays.
I’ve tried to read through this thread but something I’m not clear on is future plans- I see this noted as the first step towards something, but has it been explained what that is exactly? I’m among others that don’t love the new changes (things like some items on/off states are not different enough to see at glance, along with lock default being red which catches my attention at a glance but is the state I’d like rather than a ‘concern’). I’m glad others have found workarounds and suggestions to mostly revert via theming, but I don’t want to be too reactionary. I don’t want to create a themes file, modify my configuration yaml, and apply the theme to my users if this is all something that will continue to change or get better over time. I’d mostly just like reassurance that these concerns are heard and the current marked solution in this thread is not a long-term recommendation.
(shameless plug, sorry).
