Terminal cursor displaced after minimize about lapce HOT 12 OPEN

On Windows, minimize means resize. We need a patch for the WM_SIZE event in the upstream winit crate.

See:

• Why do minimized windows have an apparent size of 160×31?
  
• WM_SIZE message
• rust-windowing/winit#2015

from lapce.

Thank you! I'll get started on it in a few days and i will keep you updated! Great work on the editor by the way. It seems to run smoothly and i can only imagine the amount of time and effort to get to this point

from lapce.

Is it alright if i pick up the issue and see if i can fix it?

Feel free to try fixing it!
You'd want to look at lapce-app/src/terminal/view.rs and probably the wheel_scroll function in terminal/data.rs, since it seems like some issue with scroll changing but possibly not getting sent to the terminal? Unsure.

from lapce.

I found out that when the application is minimized, the view buffer of the window only shows a small portion of the titlebar. This can be seen for a split second when you open the application.

This caused the terminals size to become 0 or less, causing it to move the cursor to the incorrect location. When the window is opened, the terminal is resized again and the cursor is moved again, causing it to render at the wrong location. I have validated this by forcing the terminals size to 1200x200 and the bug stopped appearing.

Is the scaling of the application intentional to save performance? As this is a pretty minor bug i want to make sure the fix will not break more important components.

from lapce.

I'm unsure as to the answer here. It might be something done in floem?

from lapce.

I am not sure myself to be honest. I'm looking into it, but if it is something caused by floem it might have to take the problem upstream.

from lapce.

Thank you kindly! I will see if i can get some kind of workaround

from lapce.

It seems the only way to really stop the cursor from displacing is to keep the width and height of the element when there is a drastic change in the size or to check for the exact size the window is when minimized, but this seems quite hacky an unreliable. I am not entirely sure how to proceed, but i think trying to solve the problem in lapce itself might not be a great idea. I'll keep the issue opened for a while to see if anyone else has some ideas, but i will close the issue soon

from lapce.

(The issue should remain open even if we can't fix it right now — thank you for trying at it! — because it would still be a bug)
I think ideally this is something fixed, or given a workaround, in floem. So we could have a change in our winit fork to support knowing when the window was minimized and ignore size changes with that.

from lapce.

Good point. I didn't know lapce used a custom winit fork, I'll give it a go

from lapce.

After some diffing i found out that while there is a resize event taking place when minimizing, it does not seem to be manually called. The winit crate seems to simply set a flag to the window and windows does the rest. Even if i could capture the minimizing event and bypass the size change somehow, the bug still happens when the window is made very small.

The only solutions i can think of are a minimum size or bypassing the size setting when checking the percentage of window scaling. Both solutions don't seem reliable. If anyone has any ideas i am glad to try them, but for now i am not sure how to proceed.

from lapce.

I created a PR for winit lapce/winit#6 to fix the issue when minimizing. But it doesn't work when manually resizing to a small size.

I believe that's a bug in ConPTY, as window terminal, vscode integrated terminal, and alacritty have similar issues.

https://github.com/microsoft/terminal/issues?q=is%3Aissue+is%3Aopen+label%3AProduct-Conpty+resize

from lapce.