1
1
mirror of https://github.com/wez/wezterm.git synced 2024-12-27 15:37:29 +03:00
Commit Graph

4 Commits

Author SHA1 Message Date
Wez Furlong
8092886146
windows: add manifest to config-using console apps, force UTF8 ACP
Lua appears to populate package.path to something based on the
executable path on windows, but since it uses msvcrt in ANSI mode,
that string is encoded in whatever 8-bit MBCS is configured by
the host system ACP setting.

Rust expects that to be UTF-8, but Windows doesn't guarantee it.

This commit updates the manifest for wezterm-gui to tell Windows
that it wants its ACP to be set to UTF-8 prior to launch, which
should resolve this situation for the GUI.

This commit also introduces a more cut-down manifest for the
console-subsystem executables that also use the lua config layer,
which should hopefully resolve this issue for them.

This commit was authored on a mac, so fingers crossed that it
even compiles properly on windows!

refs: https://github.com/wez/wezterm/issues/3390
2023-03-28 19:18:48 -07:00
David Rios
b036bb3b05 Improve RESIZE window_decoration on Windows 2022-03-26 07:27:54 -07:00
Wez Furlong
aee37784e5 Windows: fix initial window size when display scaling != 100%
The heart of this issue was that the resize callbacks have two
layers of state; one in the low level window and one in the application
level window.

On Windows, the system triggers the low level callback prior to
opengl being initialized.  Since the application level depends on
the opengl state, there are some code paths where it NOPs and
returns early if opengl isn't yet initialized.

When the system-wide display scaling is set to say 200%, the application
layer can't know the effective DPI of the window it is creating because
it doesn't know which monitor will be used or what its DPI will be.

New windows are created at the default DPI of 96, and we rely on the
resize events to detect the actual DPI and adjust the scaling in
the window.

The early call of the resize callback meant that the low level and
application level size/dpi state was out of sync and the result was
that the window had half as many pixels as it should, but that the
terminal model was still sized as though it had the correct amount
(twice as many as visible).  This resulted in the window being too
small for the viewport.

The resolution is simple: we now suppress emitting the resize processing
until opengl has been initialized.

The test scenario for this is:

* Set system scaling to 100%
* Launch wezterm
* Set system scaling to 200%
* Observe that wezterm scales to match
* Press CTRL-SHIFT-N to spawn a new window
* Observe that the new window size matches the other window (previously
  this one would be half the size)

While I was looking at this, I noticed that the manifest didn't
match the DPI awareness that we have in the code, so update that.

refs: https://github.com/wez/wezterm/issues/427
2021-01-18 09:27:04 -08:00
Wez Furlong
a56f37598c Embed icon into windows executable and titlebar
This also applies to X11 when using the glutin frontend
2019-03-24 19:08:07 -07:00