Wezterm: Add a Minimize action

[mardukbp]

Is your feature request related to a problem? Please describe.
Pressing Alt+Space on Windows does not bring up the so-called System Menu, which allows minimizing the window by pressing n. A Minimize action is also not available for assigning a keyboard shortcut to it.

Describe the solution you'd like
Adding a Minimize action can be done by implementing a set_minimized method in wezterm/window, as it is done in rust-windowing/winit.

Describe alternatives you've considered
Using the mouse, but no.

Additional context
I don't understand why Alt+Space does not work. It works with a window created by libui. Maybe there's something to learn from it to improve wezterm/window.

Why develop wezterm/window when there is rust-windowing/winit? I believe it is better to have a single (in the Rust ecosystem) cross-platform window-handling library, which everybody improves, than having several similar libraries.

[wez]

The Hide action is intended to serve this purpose, but it was a bit broken; you could hide but never find the window again afterwards! I just pushed a fix for that to master.
https://wezfurlong.org/wezterm/config/lua/keyassignment/Hide.html

Regarding ALT-Space: I can confirm that that isn't functioning as intended and will need to run down and resolved.

Regarding your comments about winit: when I started building wezterm I found that it had a number of deficiencies and that there's a lot about its event loop that isn't compatible with how I want to structure my project. If you're interested in contributing code then I can go into more detail.

Ultimately, whether winit is used or not is an implementation detail that is irrelevant to users; what matters is whether the features work correctly and that's what I'd like to keep focused on in the issue tracker.

[wez]

ALT-Space should be working correct in the latest master; that will show up in the nightly builds within a couple of hours of this comment being written.

[bew]

Quoting the commit message of https://github.com/wez/wezterm/commit/5088c62954f49fabff974ef548a49146e7616bbe

I'm kindof hoping that no one notices

Sorry ^^

On Windows only, if ALT is pressed, allow matching key assignments that include ALT to be matched. If there are no key assignments, then DON'T pass the key press to the active pane, and instead allow it to be passed to DefWindowProc. This allows ALT-space to be handled correctly, provided the user hasn't defined an ALT-space key assignment of their own.

I didn't test it, but from the description of it, it is pretty bad for me as ALL my keybindings in zsh and neovim are Alt-based bindings..
Not too long ago I had my main keybind to save a file in neovim to Alt-space, just so you know. I don't use that anymore but I have many others like this.

I wonder how web browsers do it, since they support
Alt-space and sending Alt-based bindings to the webpage.. Or maybe they also require to register those bindings?

I know it looks like https://xkcd.com/1172/ 😂 but... can you add an option to disable this behavior on windows?

[mardukbp]

Thank you @wez! In order to cater for everybody's needs, I think it would be a good idea to give the Alt+Space binding special treatment. A switch could be used for choosing whether it should be passed directly to DefWindowProc or it is available for binding to a command. In the latter case, when not bound then it is passed to the active pane.

Ultimately, whether winit is used or not is an implementation detail that is irrelevant to users; what matters is whether the features work correctly and that's what I'd like to keep focused on in the issue tracker.

With respect to wezterm I am a user, but I am also a developer. And I am concerned with all the time and effort that goes into solving similar problems across programming languages and software projects. If discussing development matters in the issue tracker is not welcome I respect that.

[wez]

I am also a developer. And I am concerned with all the time and effort that goes into solving similar problems across programming languages and software projects. If discussing development matters in the issue tracker is not welcome I respect that.

It's not unwelcome, it's just that in the case of windowing systems there's a lot of context to cover (which is largely discoverable from the commit and issue history here on github) and in my experience with open source projects over the years, most casual "why not X?" or "Y can do it!" comments don't come from people who are showing up to contribute. With that in mind, it is generally not worth the time to write up what amounts to a technical report on how I spent >2 years of my personal time, and then defend it from casual critique when what those people really care about is "how long until this issue is fixed?".

That said, if you (or others!) have an interest in improving the state of windowing in rust, I'd be glad to help you understand specific concerns in wezterm. I think that works best if you first dig into the code and identify areas where you have questions; that way it shows that you've put in some time "doing your homework" to build up some understanding of the issues and makes it that much easier to feel good about spending the time in what is more likely to be a productive technical discussion.

[mardukbp]

What a thoughtful and reasonable reply! Hats off to you @wez! I will do my homework then. I have a lot to learn before I can make a useful contribution.

[wez]

In the meantime: both the Hide action and alt-space functionality are now working in master / on the nightly builds, so I'm going to close out this issue.

[bew]

Looks great, thanks for the update 👌