I think I'd like to make a config option for this, but for the moment,
this first pass unconditionally updates the base environment with
data from the registry.
refs: https://github.com/wez/wezterm/issues/1848
Go directly to the underlying env_logger crate, as pretty_env_logger
hasn't been updated in some time, and I'd like to be able to redirect
the log output to a file more directly, and that feature is in a newer
version of the env logger than pretty_env_logger was pulling in.
We were pinned on the revision where I had added dual source blending,
because I wanted that feature ahead of the crate being published.
Since then a couple of releases have been made so we can unpin.
On Windows 11, we had a report of glium complaining about the opengl
version. I can't find that error message string in the current version
of the code so it's possible that that situation has been resolved.
refs: https://github.com/wez/wezterm/issues/1813
Resolves a little bit of the awkward duplication of color types
between some of the crates by factoring them a little bit better.
This is prep for allowing specifying alpha for some colors
in the config.
* WIP: IME support for X11
* Handle text generated by IME.
* Set IME position according to the cursor position.
* Improve IME position handling.
Geometry as well as window focus changes are now handled.
* Dispatch IME strings like it's done on windows.
* Make sure not to silently drop IME errors.
* Respect `use_ime` configuration.
* Add xcb-util as dependency.
* Only update IME position if necessary.
* Formatting.
* Update xcb-imdkit-rs.
* Set IME position under the start of the cursor.
This seems to be the way it is commonly done among gui frameworks.
(Tested with Firefox for GTK and Konsole for QT).
* Update xcb-imdkit-rs.
* Handle systems only providing libxcb-util0-dev.
* Add libxcb to freebsd dependencies.
Required by xcb-imdkit-rs.
* Update xcb-imdkit-rs.
* Try to use more recent gcc on centos7.
* More recent C++ compiler on centos7 as well.
* Also setup correct env on centos7 for tests.
This replaces the slightly gnarly subpixel enabled blending in the
shader with Dual Source Blending, which is a technique where the
fragment shader can specify both the primary color (RGBA) as well
as an additional per-channel mask that can be used to alpha blend
with the destination.
This enables artifact-free alpha blending when used together
with a transparent window background.
refs: https://github.com/wez/wezterm/issues/932
The main culprit was the calloop feature that is used by default
in the underlying SCTK crate.
This commit:
* Routes keyboard processing via the same keyboard mapping code
that we use for X11
* Implements key repeats directly, and with awareness of elapsed
time in case the repeat rate is quicker than the event dispatching
quantum
* Disables the calloop feature of SCTK and let us do our own polling
of the wayland connection.
Critically, key repeat is sticky and unpredictable while calloop is
enabled.
closes: #669
You can run `cargo build --release --no-default-features` to build
without wayland support.
This is useful for systems that do not have wayland (eg: the `slint`
distro).
Removes the callbacks type and replaces event dispatch with
an async capable channel.
This makes it a bit simpler to model some of the window internals,
and to prepare for a wgpu enabled future.
This changes have been tested only on linux so far.
There's something fishy with colorspaces and blending.
This commit removes the `window::Color` type and replaces
it and the confusing array of color types exposed by the
`palette` crate with a pair of much simpler types:
`LinearRgb` - a tuple of f32 linear color components
`SrgbaPixel` - the u32 sRGBA pixel representation
This doesn't change anything about rendering, it just
makes it a bit simpler and makes the SrgbaPixel -> LinearRgb
conversion happen slightly earlier which shaves off some
ad-hoc conversions.
Refs: https://github.com/wez/wezterm/issues/544
However, I'm not able to create wayland windows any more on my nvidia
system (either with or without this change).
I don't know if this is specific to my nvidia drivers or something else
:-/
refs: https://github.com/wez/wezterm/issues/476
This commit is a bit noisy because it also meant flipping the key map
code from using the termwiz input types to the window input types, which
I thought I'd done some time ago, but clearly didn't.
This commit allows defining key assignments in terms of the underlying
operating system raw codes, if provided by the relevant layer in the
window crate (currently, only X11/Wayland).
The raw codes are inherently OS/Machine/Hardware dependent; they are the
rawest value that we have available and there is no meaningful
understanding that we can perform in code to understand what that key
is.
One useful property of the raw code is that, because it hasn't gone
through any OS level keymapping processing, its value reflects its
physical position on the keyboard, allowing you to map keys by position
rather than by value. That's useful if you use software to implement
eg: DVORAK or COLEMAK but want your muscle memory to kick in for some of
your key bindings.
New config option:
`debug_key_events = true` will cause wezterm to log an "error" to stderr
each time you press a key and show the details in the key event:
```
2020-12-06T21:23:10.313Z ERROR wezterm_gui::gui::termwindow > key_event KeyEvent { key: Char('@'), modifiers: SHIFT | CTRL, raw_key: None, raw_modifiers: SHIFT | CTRL, raw_code: Some(11), repeat_count: 1, key_is_down: true }
```
This is useful if you want to figure out the `raw_code` for a key in your
setup.
In your config, you can use this information to setup new key bindings.
The motivating example for me is that because `raw_key` (the unmodified
equivalent of `key`) is `None`, the built-in `CTRL-SHIFT-1` key
assignment doesn't function for me on Linux, but I can now "fix" this in
my local configuration, taking care to make it linux specific:
```lua
local wezterm = require 'wezterm';
local keys = {}
if wezterm.target_triple == "x86_64-unknown-linux-gnu" then
local tab_no = 0
-- raw codes 10 through 19 correspond to the number key 1-9 positions
-- on my keyboard on my linux system. They may be different on
-- your system!
for i = 10, 20 do
table.insert(keys, {
key="raw:"..tostring(i),
mods="CTRL|SHIFT",
action=wezterm.action{ActivateTab=tab_no},
})
tab_no = tab_no + 1
end
end
return {
keys = keys,
}
```
Notice that the key assignment accepts encoding a raw key code using
a value like `key="raw:11"` to indicate that you want a `raw_code` of
`11` to match your key assignment. The `raw_modifiers` portion of
the `KeyEvent` is used together with the `raw_code` when deciding
the key assignment.
cc: @bew
This commit uses the guillotine algorithm to assign rectangles,
which is superior to the dumb algorithm previously in use.
In addition, in the first pass of painting, if we get a texture
space error, we clear the atlas and try again without increasing
it size, which should serve as the ultimate defrag.
Subsequent passes will cause the texture to grow if needed.
refs: #306
