- Consolidate a modifier's "left" and "right" variants to just one
modifier referred to by its name or mask. E.g. Control_L and Control_R are
resolved by detecting the mask and are both associated with the name "Ctrl".
- Store string representations of the modified key values as the keys to
the key entry map (exactly how they appear in the config file). E.g.
the string "Ctrl-m" would be the key to the map entry for a custom
Ctrl-m binding (whereas before the key would've only been "m", a
source of ambiguity and conflict).
- During init, pass through key mapping entry logic twice: once for
inputting the defaults, and a second time for adding any custom
mappings as defined by the config file. This allows defaults to stay
in place unless a user chooses to blow them away. E.g. mapping Ctrl-p
to key_up shouldn't blow away key_up's default mapping to up arrow,
and this fixes that use case.
These changes resolve several bugs due to key mapping resolution ambiguity and
conflicts, and generally make key mapping more intuitive. However, a new quirk
is that keys that are obtained using Shift (like "J", aka "capital j") now
require the use of Shift modifier when configuring that binding.
Since some time now, GTK3 themes can ship an optional "dark" variant
and applications like picture viewers can make use of such a variant to
appear dark (to not distract from the picture) without overwriting the
current theme (and risking optical breakage). While wofi is not a
picture viewer it may still be desirable to use a dark theme, for
example to contrast the (light) application displaying in the
background.
Of course, wofi can already be fully customized through CSS and/or the
colors file, but using the existing dark variant may be easier than
fully restyling it, if all you want is a darker appearance. The only
way to set an arbitrary GTK application to use the dark theme seems to
be setting an environment variable, but that bears two problems:
For one, one needs to specify the full theme + dark modifier in the
variable, so one would have to keep the global GTK theme and the one
used by wofi manually in sync.
More critical though, the environment variable would be propagated to
the programs wofi launches (for now at least). That would lead to all
GTK applications launched through wofi to use the dark theme, which may
not be desirable. Wofi could also unset that variable before launching
a program, but at this point adding a simple switch is probably easier.
Side note: It may be that there is some way to configure the CSS file
to include the CSS of the dark variant of the current theme, but I have
not been able to find out how. Gnome-terminal uses a switch like this
too (just with dconf), so this may just be the way to go.
