Both interfaces drew every per-core bar with the aggregate CPU style:
`_msg_create_line` read `views['cpu']['decoration']` for every row, and
plugin-quicklook.vue called `getDecoration('cpu')` inside the percpu loop.
A core pegged at 100% among idle ones was therefore painted with the colour
of the average, which is the one number that cannot show it.
update_views now publishes `views['percpu_decoration']`: a style per core,
plus 'other' for the row that averages the cores neither interface shows.
Both interfaces read it, so they agree.
The styles are computed from the plugin's own quicklook_cpu_* limits rather
than through get_alert(), because get_alert() also records a threshold that
glances.events_list reads and can run a configured action, and both are keyed
by the stat name alone. Every core shares 'quicklook_cpu' with the aggregate,
so a per-core call would leave the last core as the value those two see.
Also drops a duplicated `msg = msg =` assignment on a line already touched.
load_limits split a config list on ',' and kept the spaces, so 'list=cpu, mem,
load' became ['cpu', ' mem', ' load']. glances.conf writes lists that way in its
own comments, so following the shipped documentation produced a config that did
not work.
The loudest symptom is show/hide: every item is used as a re.fullmatch pattern,
and a leading space makes the pattern match nothing. 'hide=sda2, loop.*' hid
sda2 and silently kept showing every loop device.
Quicklook also answered a bad list by falling back to AVAILABLE_STATS_LIST -
more than the user asked for, and its two GPU entries flip the gpu_stats polling
flags, so a typo started polling the GPU. It now falls back to the documented
DEFAULT_STATS_LIST and names the offending entries in the warning.
nicolargo