This introduces a new state to a seat's mouse struct, 'consumed'. It
is set on a mouse *press* event that is claimed by a mouse binding.
It is cleared after a mouse *release* event.
While set, *no* mouse motion or button events are sent to the client
application.
This extends the "normal" bind action enum with mouse specific
actions.
When parsing key bindings, we only check up to the last valid keyboard
binding, while mouse bindings support *both* key actions and mouse
actions.
The new actions are:
* select-begin: starts an interactive selection
* select-extend: interactively extend an existing selection
* select-word: select word under cursor
* select-word-whitespace: select word under cursor, where the only
word separating characters are whitespace characters.
The old hard-coded selection "bindings" have been converted to instead
use these actions, via default bindings added to the configuration.
This can be set to 'none' (the default), 'osd', 'log' or 'both'.
When 'osd' is enabled, we'll render the frame rendering time to a
sub-surface after each frame.
When 'log' is enabled, the frame rendering time is logged on stderr.
When enabled, the mouse cursor is hidden when the user types in the
terminal. It is un-hidden when the user moves the mouse, or when the
window loses keyboard focus.
This allows us to detect syntax errors early on, and is also more
efficient since we don't have to re-tokenize the command line every
time the binding is executed.
Previously, we calculated the monitors horizontal and vertical PPI
values.
For font sizing, we used the vertical PPI value. It seems however,
that using the diagonal PPI value, i.e. diagonal_px / diagonal_inch,
gives more consistent results.
This is still a PPI value, but since it is intended to be used as a
FontConfig DPI value, name it 'dpi'.
* xcursor always set for all pointers
* xcursor sometimes not updated when it should be
* mouse grabbed state wasn't per seat, but global (i.e. "does at least
one seat enable mouse grabbing")
* selection enabled state wasn't per seat
Previously, we triggered a theme reload on output changes. This is
completely wrong. We may get a new output with a scale different from
the output the pointer is actually on.
Now, we store the current scale along with the theme. We then trigger
a call to reload the xcursor theme *every* time the pointer enters a
surface. When it does, we use the current scale factor of the terminal
that owns that surface.
If the terminal covers multiple outputs, with different scale factors,
we'll use the largest scale factor. This may not be 100% correct. But
to fix that, we'd need to track which regions of a surface are mapped
on which outputs. Too complicated I say.
That is, deal with monitors being unplugged.
At least on Sway 1.4, surfaces are not unmapped before the output is
removed. Thus, in addition to free:ing the monitor resources, we also
need to update all terminals that are mapped on this output - remove
the output from their "mapped on" list.
Before, we converted each axis event's scroll amount to an integer and
scrolled that many lines.
However, axis events are speed sensitive - very slow scrolling will
result in events with a scroll amount that is < 1.0.
For us, this meant we never scrolled a single line. You could slow
scroll all day if you wanted, and still we would never scroll a single
line.
Fix this by aggregating the scroll amount from axis events until the
scroll amount is > 1.0, and then scroll.
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.
Before, when looking for a matching user key binding, we only
matched *symbols*.
This means that the physical keys that generate a specific key binding
is layout dependent. What's worse, it may not even be possible to
generate the key binding at all.
Russian is one such layout, where all the "normal" (us) symbols are
replaced.
By using raw key codes, we can get around this - the key code has a
direct mapping to the physical key.
However, matching raw key codes **only** doesn't always make sense
either. For now, match **both** symbols _and_ key codes. Symbols take
precedence.
TODO: we might have to make this configurable _per binding_.
Note: 'search' mode still uses mostly hardcoded shortcuts that still
have this problem (i.e. ctrl+g doesn't work with a russian layout).
This way we:
* Don't have to call wl_display_get_fd() all the time
* No longer call fdm_del_no_close() even though the FD hasn't been
added to the FDM.
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 fixes an issue where the fonts were rendered too small when the
output had fractional scaling.
For integral scaling, using the logical (scaled) DPI multiplied with
the scaling factor results in the same final DPI value as if we had
used the physical DPI.
But for fractional scaling, this works around the fact that the
compositor downscales the surface after we've rendered it.
Closes#5
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.
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.
For now, this behavior is controlled with an ifdef. At least kwin
seems very buggy when the decorations are positioned like this (but
normally you'd use server-side decorations with kwin anyway).
This commit also changes 'use_csd' to be a tri-state variable;
when instantiating a window it is set to 'unknown'.
If there's no decoration manager available (e.g. weston), we
immediately set it to 'yes' (use CSDs).
Otherwise, we wait for the decoration manager callback to indicate
whether we should use CSDs or not.
