2021.7 History graph color changes

In this day and age customisable colours really should be standard for any form of graphing. I ordered some of my graph entities so that colour had meaning so at a glance I can see information rather than data lines I have to parse visually.

Having had those colours for a quite some time this is now ingrained.

So I have rolled back and I’m now stuck with the choice of don’t upgrade until I have time to convert all of my graphing (just shy of 90 graphs :frowning: ) to a 3rd party card and risk them all breaking if there is an incompatible core change in the future or screw my layout / my workflow / visual style.

Just feels odd that with all the open issues against the frontend / core that a dev spent time on a “feature” / “making style changes for all users” that I didn’t see loads of people asking to have changed when, as has been mentioned there are 3rd party options for changing the default graphing if the default didn’t work for them.

Also why on earth are front end changes not included in the change logs, surely they are just as important as backend changes.

8 Likes

The library HA uses (ChartJS) was updated to v3 from v2 (a 2016 version) and there were a lot of breaking changes. This is something that changed by default. It was not on purpose but the update was needed. Contrary to what you may believe, the devs do not change things to upset everyone on purpose. This is an open source project and the project uses open source tools, this is a byproduct of that. You don’t have to get this upset over colors. Put in a feature request and advertise it around the forums if you want color adjustment to graphs.

4 Likes

Someone has even created a feature request you can vote for:

… 3 years ago :wink:

2 Likes

Lol…That 16th vote could be the one that breaks the camel’s back.

That’s how voting works, no votes, no implementation unless you want to develop it yourself

3 Likes

I really doubt it works this way.
since developers are volunteers and can work on whatever they want (or reject the work if they decide so) there is no guarantee that features with high number of votes go first.

1 Like

It 100% works this way. Anything that gains rapid ground is picked up by the devs. Everything else is not.

Most recent case in points: pwned and the recent templates in packages. I think @finity even posted a bunch of places advertising his feature request to get the fan integration changed

Is it picked up because devs have to, or because they are keen to do so?

2 Likes

Because people want it… again that’s how voting works :wink:. Contrary to what you believe, there is no crazy conspiracy behind the development here.

3 Likes

You obviously don’t want to understand what I’m saying. It’s not about conspiracy. It’s about the fact that work on HA is voluntary. so devs are allowed to chose what they will work on. if it somehow correlates with voting results - great. But it’s their decision, not guaranteed rule.

It’s enough to look at FR subforum (not even speaking about wth) to see that there are delivered features with lower number of votes, while others with more votes are still waiting for better times.

1 Like

Exactly.
This is why Petro’s statement is not true. Maybe because it’s oversimplified. But not true.

Sorry to interject here (and call me lazy for not researching the answer1) but is this referring to the recent template trigger feature that couldn’t be used in packages? Are you saying that has now changed and they can?

Sorry if I’m barking up the wrong tree. (But I really hope not!)

1If it was announced somewhere I certainly missed it.

No. They are still unable to be used in packages. And will most probably remain that way.

1 Like

ya, Petro got me there too. Although you say template: will probably never be supported in packages, I still hope they will… too bad we can not revote :wink: or have a crying heart here in the forum…

Frenck said earlier on it can be done, but is rather complex. Dont recall the exact wording. So, maybe, if we keep on presenting good examples and reasoning, the dev’s will decide to make the effort.

I’m sure Klogg doesn’t like what you say, though the heart would give one that impression

I wouldn’t say that. It’s been brought up many times and iirc there have been changes to refactor that code to make it manageable. Also there is no maintainer, so it’ll just take some time before we see anything.

Ok. Apologies for the misinformation. I got that impression from discussions on Discord weeks ago, but things move quickly around here.

What I said is how it works for the main team. It doesn’t include the volunteers.

Actually. some of the main team are employed by Nabu Casa to work on HA full time, if I recall correctly.

2 Likes

Well, I think this is not only the question of skills, but also problem with the way that specific functionality is implemented. In case of these charts we are talking about library developped by external to HA developers, that maintain its functionality and debugging separately. Obviously it should be possible to modify this library before including it into HA to support custom colors, but then every time library is updated by original developers, same customization would need to be reapplied before updating HA, to keep consistent behaviour across versions. Not easy, especially when some major changes in the library are made and it need to be investigated over and over how to customize…
Said that, I would love to see custom colors being implemented :slight_smile: