When adding a custom module with a name, e.g.:
```jsonc
{
...,
"custom/foo#bar": { },
...
}
```
The custom module does not retain the `bar` class as it should, because
all the classes are replaced with the runtime output:
1b4a7b02f4/src/modules/custom.cpp (L141-L147)
Avoid removing the module instance name class so css class behavior is
consistent between all modules.
In file included from src/modules/upower/upower.cpp:1:
include/modules/upower/upower.hpp:25:16: error: no template named 'unordered_map' in namespace 'std'
typedef std::unordered_map<std::string, UpDevice *> Devices;
~~~~~^
In file included from src/modules/upower/upower_tooltip.cpp:1:
include/modules/upower/upower_tooltip.hpp:13:16: error: no template named 'unordered_map' in namespace 'std'
typedef std::unordered_map<std::string, UpDevice*> Devices;
~~~~~^
1. battery.hpp - added local bool variable. Force to print warnings the
only once in order to warn user about wrong battery configuraion. And
does not bring a mess when the battery is turned off (gamepads, etc.)
2. dir_name is an object which takes a part in comparison. So converted to the string.
If the modifier is pressed and release without another event, the
intended behaviour is to clear an urgency hint and hide the bar again.
Note that if multiple workspaces have the urgency hint set, the bar is
hidden again and an urgent workspace is focused, the bar does not stay
hidden anymore.
Add a second reason to show the bar besides visible by modifier.
Update the visibility based on changes in the workspace urgency.
Check all workspaces for urgency and keep the bar visible if at least
one has an urgency hint.
As we always use the enum to compare or initialize uint32_t values, it
would be better to declare it with the right type. This way we could
avoid `-Wnarrowing` warnings or unnecessary type casts.
