Unexpected behaviour: Terminal content scrolls up when console is hidden. Input position stays.

[webbertakken]

This setting is set to true by default, ~and works perfectly as far as I can see~ (was able to reproduce with true as well).

    // When clicking or alt-tabbing away to another app, the terminal will automatically (and instantly) hide.
    "HideOnFocusLost": true,

When setting it to false, I observed the following behaviours that would not be expected for a great user experience.

1. Pressing the hotkey to open the console while still open on a different screen or behind content does not open the console immediately but closes it instead. You'll have to press the same hotkey twice to effectively open it.
2. During described manual close action, all content of the terminal shifts up, out of view. You will have to scroll up to see what you last typed, as well as the caret. (perhaps solved by fixing point 1).
3. If instead you do not scroll up but start typing, it will type in the original position (not scrolled away). So there is a big gap between the content that scrolled away and the new enter. (likely solved by fixing point 2)

I will demonstrate case 3 by running dir before and after reopening the console:

before reopening console:

after reopening console, before pressing enter

after pressing enter and scrolling up by 2 lines:

proposed solution: (for point 1)

• Losing focus always counts as "toggled closed" (but does in fact not close the console)~
• reacquiring focus by clicking on the window counts as "toggled opened" (restore current behaviour)
• when the toggle says closed, the opening behaviour instantly closes the inactive window and slides it open like normal.

proposed solution: (for point 2 and 3)

• None so far.

Tested on:

• version 1.2.0
• some previous version

[flyingpie]

@webbertakken Thank you for reporting this, fun scenario :D

Regarding the shifting around of lines during toggle, I've had a couple of people mention a similar thing, and actually noticed this myself. In those cases, it had to do with the "ToggleMode".

Could you try this:

{
  "ToggleMode": "Move"
}

It defaults to "Resize", which I've been considering changing due to the feedback so far. The "Resize" mode is meant for when using multiple monitors stacked above one another, which doesn't work great with "Move", since the terminal is pushed to the top screen and then dissappears.

I'd love to hear if that fixes that part of the problem at least!

[webbertakken]

@flyingpie I can confirm this fixes point 2 and 3. It even looks (feels) to be a bit smoother now as well.

[flyingpie]

@webbertakken Great! Now on to the point 1.

Pressing the hotkey to open the console while still open on a different screen or behind content does not open the console immediately but closes it instead. You'll have to press the same hotkey twice to effectively open it.

This is a thing that's been bothering for some time now. What do you think would be the proper way of handling this?

Eg. move terminal to the active monitor, whilst staying open?

Also, since there is a bit of overlap with the "hide when focus lost", in my experience, the terminal only does this when I move to another monitor but don't actually focus a different app. So it's sort of this twilight zone of focus-lost-but-also-not. So perhaps you're suggesting to be able to hide the terminal when moving the mouse to a different monitor?

[webbertakken]

@flyingpie Cool. Here are my thoughts.

What do you think would be the proper way of handling this?

Before using this console with powershell I used ConEmu with a mix of powershell and ubuntu bash (WSL) shells. ConEmu is highly configurable and I spent considerable time trying different configurations.

What ultimately ended up working best for me was the following:

Behaviours:

A: Open regularly, with a smooth animation B: Close regularly, with an optional smooth animation C: quick or instant close then immediately open on the screen where the mouse pointer is.

Flows / cases when pressing the hotkey for open/close

• When closed: Behaviour A
• When open and active window: Behaviour B
• When open and inactive window: Behaviour C (mouse pointer on same screen (i.e. you clicked on something that is now in front of the console, thus no need for a long close animation, must be very quick or instant))
• When open and active window, but mouse pointer is on different screen: Behaviour C
• When open and inactive window, and mouse pointer is on a different screen: Behaviour C
• When currently inside any of the animations: Behaviour C

The last case ended up being bugged sometimes, which ultimately led me to reduce the close animation time to 0ms.

About close when focus lost

there is a bit of overlap with the "hide when focus lost"

So I can mostly only speak from my own use case: when I click on a different screen (say my IDE) I do not want the terminal to close, because I might be reading something from it. This is the main use case for having the auto-hide disabled.

perhaps you're suggesting to be able to hide the terminal when moving the mouse to a different monitor

In my opinion it should only hide once you click outside the console itself, causing a real loss of focus. I believe that behaviour would be most reliable and predictable to the all users.

Exceptions to that (i.e. alt+tab should not count as focus lost) should probably have a separate setting or might not be worth the extra complexity at all.