global variables in config.js

[A Former User]

Don’t get me wrong. I don’t want to make any argument about this issue. I also believe the global level values be needed and useful really. However, I’m just saying about reality.

Anyway who decides which variables should be included as MM-level-default-global?
Maybe timeFormat and language might be the ones definitely. But those are already included. (By the way, timeFormat:24 is not so really useful to define complex time format of calendars or clocks. What 24 means? “23:45”? “23:45:01”? “23:45:01 pm”?)
Maybe profile-related-things and page-related-things could be ones also. (Personally, I wish profile to be supported on MM by default).
But others? what remains? As a module developer, if I want MM community to adopt my variable verbose: as a default global value, Should I make a PR for it? But if other developers never use/support that field either despite including, what is its worth?
Only that is just my worry.

[sdetweil]

@Sean i just made a change to fix problems with the older pi hardware… and while fixing that realized everyone that needs to run serveronly has to create the startup scripts themselves, and its all hard coded…

so, I added another variable to the config.js, serverOnly:

it will help some users…

[sdetweil]

@Sean “24” means not am/pm, and it shows seconds ticking…

you have great ideas, and modules… share improvements to help everyone!..

[A Former User]

@sdetweil said in global variables in config.js:

@Sean “24” means not am/pm, and it shows seconds ticking…

That is my point. Each value could have a different meaning in different modules. I can’t use MM-level-global-timeFormat in calendar and clock modules which are created by me because that value is too ambiguous and has a meaning only in default calendar/clock modules. But If timeFormat would become the definite global value,(well, frankly it is already) the user will expect it works also in my modules like default module. But I can’t.
How about location? Some of the default weather-related-modules are using it like location: "New York", but other Geo-information-related-modules might need another format of value as that kind. If it could not be used really GLOBALLY, how it could become really useful?