The pipe command can contain almost all printable characters. In
particular, we can expect it to contain '='.
Having the pipe command as part of the key breaks the key/value
splitting.
Change it so that it is instead an optional initial part of the value,
enclosed in '[]'.
I.e. instead of
pipe-visible:cmd=binding
we now need to write
pipe-visible=[cmd] binding
A key binding may now have an optional ':<cmd>' string appended to the
key.
This is intended to be used like so:
pipe-scrollback:sh -c "cat > file"=Print
TODO: we still only allow one *action*. Meaning you still cannot
specify multiple pipe-scrollback bindings, for example.
When resizing the font on-the-fly, we now do a complete
font-reload (this is basically what fcft_size_adjust() did anyway).
To get the correct size, we maintain the current size ourselves.
We get the initial size from the user-provided font pattern, by
converting the string to an FcPattern, and using FcPatternGet() to
retrieve both the FC_SIZE and FC_PIXEL_SIZE attributes. These
attributes are then removed from the pattern, and the pattern is
converted back to a string.
The terminal struct maintains a copy of the font sizes. These are
initially set to the sizes from the config.
When the user resizes the font, the terminal-local sizes are
adjusted. To ensure the primary and user-configured fallback fonts are
resizes equally much, convert any pixel sizes to point sizes at this
point.
When the font size is reset, we reload the font sizes from the
config (thus once again returning actual pixel-sizes, if that's what
the user has configured).
They aren't really user configurable. At least not yet.
However, with this, we now handle raw key codes just like the normal
key bindings. Meaning, e.g. ctrl+g, ctrl+a, ctrl+e etc now works while
searching with e.g. a russian layout.
This adds an undocumented 'tweak' section to footrc, with two new
options:
* delayed-render-lower
* delayed-render-upper
Both takes an integer value, representing the lower/upper timeout
values (in nano seconds) for delayed rendering.
A button may only be mapped to a single action. Detect when the user
tried to map the same button to multiple actions and error out.
To clear a binding (for example, to free up a button from the default
bindings), one can set the action it is bound to to
`NONE` (e.g. `primary-paste=NONE`).
* New config section, "mouse-bindings", where bindings are defined on
the form "action=BTN_<name>
* pointer_button() handler now scans the bindings list instead of
hardcoding primary-paste to BTN_MIDDLE.
* The implementation handles single- double- and triple clicks in the
bindings, but there is currently no way to define anything but a
single-click binding in the configuration.
This adds parsing of a new section - "key-bindings" - where the user
can configure the key bindings on the form "action=combo1 .. comboN"
The validity of the key combinations are checked with the default XKB
keymap.
New actions defined and implemented:
* scrollback up/down
* font size up/down/reset
* spawn terminal
Break out key combo parsing to a new function,
parse_key_binding_for_action(). This function parses a string
containing one or more space separated key combo definitions on the
form (mod1+mod2+...+key), where key is a XKB key name (e.g. KP_Add).
Convert all hardcoded key bindings to configuration based
bindings. These still cannot actually be configured by the user, but
at least lives in the conf struct.
This adds initial support for defining key and mouse bindings that are
applied in different terminal modes/states.
For example, there are two arrays dealing with key and mouse bindings
in the "normal" mode. Most bindings will go here.
There's also an array for "search" mode. These bindings will be used
when the user has started a scrollback search.
In the future, there may be a model selection mode as well. Or maybe
"search" and "modal selection" will be combined into a single
"keyboard" mode. We'll see.
Since the keyboard bindings depend on the current XKB keymap,
translation from the user specified key combination string cannot be
done when loading the configuration, but must be done when we've
received a keymap from the wayland server.
We should explore if it's possible to load some kind of default keymap
just to be able to verify the validity of the key combination strings
at configuration load time, to be able to reject the configuration at
startup.
A couple of key bindings have been added as proof of concept.
Mouse bindings aren't handled at all yet, and is likely to be
re-written. For example, we can probably translate the configuration
strings at configuration load time.
getline() will re-use the allocated line if it large enough, or resize
it otherwise. Thus there's no need to free it and set it to NULL
between each call.
The user can now configure the following:
* Whether to prefer CSDs or SSDs. But note that this is only a hint to
the compositor - it may deny our request. Furthermore, not all
compositors implement the decoration manager protocol, meaning CSDs
will be used regardless of the user configuration (GNOME/mutter
being the most prominent one).
* Title bar size and color, including transparency
* Border size and color, including transparency
Also drop support for rendering the CSDs inside the main surface.
If the display resolution *is* 800x600, using this size is bad since
there will typically be panels and other things on the screen too.
Not that 800x600 is something we expect to see in real life, but may
happen on virtual displays.
When there is no configuration file, and we're using the default
configuration, we accidentally jumped pasted the code that ensures
we have at least "monospace" in the font list.
When splitting the font configuration into multiple font
specifications, we now trim leading spaces.
This makes no actual difference; fontconfig matched the fonts just
fine anyway, but this looks better in the logs.
They where previously identical to the corresponding 'regular'
colors. Now, we've done a saturated add with 0x202020 (which seems to
be roughly the difference between the other regular and bright
colors).
