Currently it seems themes is configured inside settings.js, so it will be global for the entire node red instance. Why not have it in .config.users.json so each user can have their own?
The .config.*.json are not intended to be hand edited. They are maintained by the runtime.
We looked at allowing per-user themes, however it wasn't simple to achieve. Most theme content is loaded before we know who the user accessing the editor is. We don't currently have a way to change theme without reloading the editor.
1 Like
I'm having to deal with installation and distribution, so have to configure and store templates of all .config.*.json files. They are no more difficult to handle than any other config file like settings.js.
Ok so it is a technical limitation. Normally it would be some conditional css class based on user data?
Could you not use a standard theme name but make different theme files and provide a small script to swap them out?
I guess normally you'd do something like swapping theme files yeah. No idea how that works in node red, all I know is you can set themes in settings.js. If you swap theme files, won't that affect the entire instance, and not individually per user?
Yes, I thought you'd said that you have a separate instance for each user - maybe not?
If you did, you should note that the settings.js file is a node.js module and so you could make the theme settings more dynamic. Not truly dynamic of course since it is only read on Node-RED start but still, would be enough if each user had their own instance.
I can run node red locally yes, in which case this wouldn't be an issue as you point out. But it's just too much work mocking all the external dependencies at the moment, so it's not really useful unfortunately. So many different connections, like Thingsboard (which doesn't provide dev server), then all the unusual protocols like modbus, mbus, bacnet etc. One day I'll make http API for all of those, but it's too unstable at the moment.
Not sure how helpful this will be. But if you have a number of common services, why not proxy those via a central node-red service? That way, you only need a single connection to them and only the data is accessible to the users?
Of course, I'm working blind here as I don't really know what your actual needs are but anyway, just another idea.
Well this topic was just about having individual themes per user. The wider background as we touched upon is that my team work on the same instances in production. I would really like to move away from that and instead have dev environments if that makes sense? But that's impossible when all inputs and all outputs only exists in prod environment. One plan I had was to make a second NR instance which functions as a http proxy to all those unusual protocols. To sort of encapsulate them in http. Which could then either be mocked and/or accessed directly from dev env to prod env (for read-only requests at least).
Absolutely. 
And that is the same conclusion I came to and described above - though not as well as you have.
This approach has the advantage that you can if you wish, as you say, mock instead of having to reproduce all the dependent systems as test versions. Also, if you needed to use a live connect for some reason, you could put limits and/or caching on it to reduce possible accidental abuse during testing.
So this leads me again to suggest that you have a simple flow (or a plugin or custom node) that lets users select from a range of themes and uses a background copy to update the users settings and restart Node-RED - all the user would need to do would be to reload the editor and you could even automate that if you really wanted to.
1 Like
Gotcha 
It's just a one-time job so it could be a test for how much they want the theme and then take steps to manually edit their own settings.js hehe.
1 Like
