The XDG output manager object may arrive *after* output objects. In
this case, we need to register the pre-existing output objects with
the XDG output manager.
This fixes an issue with some monitors having a DPI value of 0 on
Gnome/mutter, which resulted in incorrect font sizes.
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.
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'.
When we're handling the initial set of globals, the data-device and
primary-selection-device objects may, or may not be registered before
the seat(s).
We need to handle both cases.
When adding a seat, instantiate the data-device and
primary-selection-device **if available**.
When adding the device objects, instantiate them on **all** currently
available seats.
The commit log says that was needed to get tiling in GNOME
working. However, I don't know *which* extension that was.
Force resizing in a configure event means we'll trash a perfectly
valid buffer on e.g. 'activated' state changes.
So, let's revert this for now, and if this breaks GNOME, let's try to
find another solution. If worse comes to worse, we can detect if we're
running under GNOME and do a force-resize then, but not on sane
compositors.
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.
This ensures we _always_ commit a **new** buffer in response to a
configured event.
This fixes an issue in Gnome where e.g. tiling the window (on the
left/right side) only worked if that caused the windows size to
change.
The way things works right now, we cannot enable the ptmx FDM callback
right away. We need to wait for the Wayland window to have been
configured.
Before the window is configured, we don't have a size, and no
grid. Thus, if we try to process ptmx data we'll crash since we have
no where to write it to.
So, registering the ptmx fd with the FDM is now delayed until we've
received the first 'configure' event from Wayland.
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.
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.
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.
