Re: Colour settings, defaults and user modifications
Posted: Thu 30 Apr 2020 6:22 am
Thank you.
Support forum for Cumulus weather station software
https://cumulus.hosiene.co.uk/
I guess it's about getting the gauges to fit in with the rest of the colour scheme.
Yes, I understand However, updating gauges colours through ini settings is pretty impossible though (some settings that is), so I might leave it at an instruction. Have been studying all morning but there is no way to e.g. change the background, though the frame is easy. Unfortunate. Anyway, I'll continue looking for possibilities. For now, editing the gauges is the only possibility.
I am afraid you have to elaborate on the word impervious and what actually the problem is. Aha... I guess because you changed the ColorDashboardTextAccent colour it does not jump out anymore as rising. Transparency is not involved, it is the same colour as the accent colour. I think fixing it to the bright green colour (unchangeable by the user) would satisfy everybody? I'll fix it to green and see what remarks that generates I don't think I'll make a separate parameter for it (up and down). A bit too much detail isn't it? Other opinions welcome
If you are regularly changing things to experiment, it is better not to use thrifty. Read the thrifty explanation carefully, for the website, only the index.html is uploaded. If you change things in the cumulusutils.js (call it the runtime system) such as the colour definition of the accent colour, you can't use thrifty. You can't really know so I advise not to use thrifty. Thrifty is basically intended for stable systems, your regular run. If trial and error approach for changing the colours takes too long because cumulusutils does the windrose without thrifty, than I would advice for such exercise to switch off the windrose in the inifile. That saves a lot of time and irritation.
Frankly, I wouldn't bother to go there - it can be done through the gauges.js file
The reason for my comment was the difference between the increasing and decreasing symbol - the former's colour can be changed but the latter can't. I would vote for both to be changeable (not separately) - and leave it up to the user to decide what colour they would like. That allows the user to get a harmonious combination that they prefer. Some may not like the bright green version because it doesn't fit in with the rest of their scheme. I rather like "subtle" rather than "loud" but that's just me
Thanks for the tip. I'm happy where my page is at now and not planning on making further customizations .HansR wrote: ↑Tue 26 May 2020 9:47 am If you are regularly changing things to experiment, it is better not to use thrifty. Read the thrifty explanation carefully, for the website, only the index.html is uploaded. If you change things in the cumulusutils.js (call it the runtime system) such as the colour definition of the accent colour, you can't use thrifty. You can't really know so I advise not to use thrifty. Thrifty is basically intended for stable systems, your regular run. If trial and error approach for changing the colours takes too long because cumulusutils does the windrose without thrifty, than I would advice for such exercise to switch off the windrose in the inifile. That saves a lot of time and irritation.
Frankly, just had a tip from Mark which may bring me a lot further... we'll see.Frankly, I wouldn't bother to go there - it can be done through the gauges.js file
So you would like two parameters. They will be independently changeable because I can't bring the relation into the ini. But OK, two parameters, easy.I would vote for both to be changeable (not separately)
For everybody else to learnThanks for the tip. I'm happy where my page is at now and not planning on making further customizations .
I just put out a new release. It was a combination of typo's. Anyway, sorry for that, sloppy me Should be better now, hopefully goodbilly wrote: ↑Thu 28 May 2020 1:18 pm A couple of observations re gauge-related settings in the latest Version 3.7.0:
I set some custom keys as per below but only the first one seems to have worked:
SteelseriesFramedesign=ANTHRACITE
SteelseriesBackgroundColor=MUD
SteelseriesPointerColour=WHITE
SteelseriesPointerType=TYPE16
SteelseriesLcdColour=STANDARD
SteelseriesForegroundType=TYPE2 (although not sure what this actually does )
That is something which is a bit far from the original idea and design of CumulusUtils. I keep the configuration in one place, it is intended to be in one place. It was one of the starting points to have only one executable and one place of configuration. We could open a separate thread to discuss that, but it is very fundamental to what CumulusUtils is. Beside that, you need to know that gauges.js is also fundamentally different from the original by Mark, though it still bears the same name (I may change that in future to avoid confusion). They are no longer exchangeable. Some features have been taken out, some have been put in (e.g. the possibility to change the dashboard requires some minor but fundamental changes). The software change of the look of the gauges is also such feature.billy wrote: ↑Thu 28 May 2020 1:18 pm Also, any other user custom setting(s) in gauges.js are overwritten when running "cumulusutils.exe Website". This can be overcome by overwriting the new gauges.js with the users custom version. That would be required every time the Website parameter is used (maybe daily for some users?). I guess the overwrite could be automated? Or maybe there could be a key to not update gauge settings?
No need to apologize (although I never make mistakes )
I get that.
Now that is an offer you may regret . Here are the things I was fiddling with yesterday: