Changing the colour of all text on screen

boybay7

@lavolp3 So just to confirm, even though I have edited code in like modules or custom.css for the font colour, it won’t be replaced when I update with git pull?

boybay7

@lavolp3 Also thanks, I figured it out, I was editing the wrong module because there is like 3 modules on weather. Okay another question, I want to change the colour on weather forecast. Currently it’s red and blue, but I want it to go blue (min temp) and then red (max temp), so how would I do that? Appreciate all the help

lavolp3

@boybay7 The only files you should change are config.js and custom.css.
These are also disregarded in the updating procedure, so will remain as they are. Everything else will be checked against its version on the servers.

Usually there’s nothing to be done in the module folders as long as you don’t want to manipulate module code.

For all styling options you should use custom.css, e.g. like advised above

lavolp3

@boybay7 said in Changing the colour of all text on screen:

Okay another question, I want to change the colour on weather forecast. Currently it’s red and blue, but I want it to go blue (min temp) and then red (max temp), so how would I do that? Appreciate all the help

That’s a bit more complicated, but can be done via styling.

Without explaining too much, put that in your custom.css

.weatherforecast tr.colored .min-temp {
  color: 'green';  
}

.weatherforecast tr.colored .max-temp {
  color: 'red';  
}

or use hex codes (like ‘#00ff00’) for any color you like.

ronw1309

thanks for this it really helped

lavolp3

@boybay7

So just to confirm, even though I have edited code in like modules or custom.css for the font colour, it won’t be replaced when I update with git pull?

To have a complete answer to this, a more basic approach.

You have two things going on in your MM environment.
One is the server side, that is represented by the node_helper.js files. It is kind of a back office, fetching, progressing and forwarding data so it can be displayed in the browser / on the mirror. It does e.g. call weather or calendar APIs and fetches the data.

The server side communicates with the client side, which is represented by the module.js and module.css files (among others).
These are (mostly) responsible for building the html and css code that you finally see in the browser.

The server side is refreshed whenever you restart the mirror (e.g. by pm2 restart mm, or by restarting the Raspberry pi…)
The client side is refreshed whenever you reload a browser page (also with pm2, or - on your laptop - just by reloading the browser page!)

Meaning, you can e.g. display your mirror on your laptop (by going to http://MIRRORIP:8080), change things in custom.css or in config.js and just reload the browser page on the laptop to test these changes out.
Note however, that when you just reload the browser there may be things running on the server side, that do not understand you changes made on the client side anymore, since the server side code has not been refreshed.

The best way of keeping your mirror running and properly updating after code changes is using pm2 and above command to restart.

All of this has nothing to do with git pull.
Git pull is a synchronisation with the code on the git server.
Git pull is used to get updates on the module code from the module creator. It is comparable to updating any program on your computer.
Of course you should restart the mirror after having done git pull.

Hope that helps to understand the environment. It’s surely not easy for beginners.

BTW: If you wonder why you need both of these parallel processes:
The magic word is asynchronity. Whenever you want to fetch data from an API, which your mirror does a lot of times, you have to wait for an answer (the api call is asynchronous, its not synchronous with the rest of the code anymore, it waits…)
If you implement this into the same code that would build up your page, you would end up in a mess.

So the trick is, you have another process that just sends messages (here: notifications) to your page building code. The page building code can then react to these messages by updating what is on the mirror. It does not have to sit and wait for an answer, it can just react to a message.

I could go on for ages here, it’s really a fascinating concept for someone who has only been slightly in programming in the past. This has thrown me into kind of a programming pit. You can see that from the size of my answer :-)

BKeyport

@boybay7 said in Changing the colour of all text on screen:

@lavolp3 So just to confirm, even though I have edited code in like modules or custom.css for the font colour, it won’t be replaced when I update with git pull?

Short answer without a bunch of confusing and unneeded parts: Yes.

Long answer in simple form but more detail:
These aren’t updated when you follow recommended upgrade path (usually just git pull && npm install in magicmirror directory):
config.js
custom.css
modules directory structure except for the default directory tree

There are scripts out there to stash any changes you have made to changed items, however, 99.99% of the time, changes are not needed to updated parts of the MagicMirror ecosystems. the remaining time, it’s a change to get around a short term bug (like currently, the calendar applet), that will be included in the next update, so there’s no reason to stash it.

Bottom line - your customizations, unless done in a poor way, will never be deleted, until you rm -rf the whole mess or the boot device (Not just SD anymore!) crashes.

If you’ve decided to customize a module within it’s own code, that isn’t a official fix of the module, I would highly recommend forking the project, switching to your fork, then modifying to your needs. Then, if you think everyone else would benefit from it, please do a merge request, and let the author(s) decide to do so, or, in the case of dead modules, change the name and take over the project (I’ve done that with MMM-Worldclock, for instance)

boybay7

@lavolp3 Thanks for the explanation!

boybay7

@BKeyport I mean when I say I’ve customised a module, I’ve changed the default fade value to false, or changed the time format on clock to 12 hour. Also I don’t know what forking the project means. But thank you also for the explanation.

sdetweil

@boybay7 the question is, did u edit the module source file (wrong way), or add parameters to the config.js config for this module (right way)

both produce the same results