Heterogeneous DPI Incompatibility

[Queuecumber]

When using ddterm with wayland heterogeneous DPI, the window can be the wrong size.

I have a 4k laptop monitor and 1440p external monitor. I keep the laptop monitor at 200% scaling and the external monitor at 100% scaling. When I initially open ddterm on the external monitor it correctly display at the full width, on subsequent openings it is only about half the width (see screenshot)

[amezin]

Could you test this change? f400e96

You could use a pre-built package: https://github.com/ddterm/gnome-shell-extension-ddterm/suites/8074180755/artifacts/348094355 (unzip pack.zip, then run gnome-extensions install -f ddterm@amezin.github.com.shell-extension.zip - yes, it's zip inside of zip, and you need to manually unzip only top-level one).

After installing, don't forget to log out and log in or reboot.

[Queuecumber]

Same behavior with that zip file

[amezin]

Ok, I've been able to reproduce the issue.

Window manager decides to place the window on the primary monitor, no matter what the extension does. And it happens only when monitors have different scaling. The extension moves the window to the correct monitor a bit later. But because the window is maximized horizontally - it can't be resized horizontally. Actually, window manager itself should resize maximized windows - but fails to do it in this case.

I'm not sure if I'll be able to fix this.

[Queuecumber]

Do you know whose bug it is and where I can file it?

[amezin]

It's all related to async resize handling in GNOME window manager on Wayland: https://gitlab.gnome.org/GNOME/mutter/-/issues/1627
As you can see, I've tried to fix that issue once... And failed (and others too).

Also, ddterm is doing things that aren't supported by GNOME Shell/window manager, and aren't intended to be possible.

Probably the proper way to fix this is to ask for new API in the window manager. And I should have done it already - but previously various workarounds allowed me to solve the problem without it. New API will only be available in GNOME 44 (if it will be accepted - which isn't guaranteed).

I've achieved something "almost acceptable" (especially if window animations are enabled) with various hacks - but there are multiple issues: the window flashes on a wrong monitor, sometimes renders with wrong scaling factor.

[amezin]

I have plans to write an xterm.js-based terminal emulator using GNOME Shell's UI (instead of the current implementation with a separate Gtk application). It should solve all window management issues, like this one.

However, it won't happen soon, as it will likely be a separate project, written (almost) from scratch.

#269