Reliable way to get size of WT's viewport?

[vefatica]

In the simple scenario ... my app run by a Windows shell in OpenConsole.exe in WT on the local machine ... is there a reliable way to get the number of rows and the number of columns in WT's viewport? Thanks!

[DHowett]

GetConsoleScreenBufferInfo will continue to return the size of the viewport in srWindow, just as it does in a console host session.

[vefatica]

MODE.EXE will screw that up. If you use "mode con: lines=large_number" srWindow changes to the largest number of lines that will fit on the monitor, though nothing has visually changed in WT.

[vefatica]

As you probably know, other things get screwed up too. For example, absolute cursor positioning (ESC[r;cH) uses the new srWindow. allowing rows that are out of bounds in WT. And TCC, my usual shell, gets hopelessly messed up.

Moral of the story: don't do that!

[j4james]

we don't want one pane to be able to cause a resize of other adjacent panes!

I've been considering this recently, and I'm starting to think the best approach might be the second option in #5094 (i.e. accept the requested size as a kind of virtual window, similar to the way conhost works when the buffer width and window width are different). This lets the app keep working as expected, and the user can always resize the pane/window afterwards to get rid of any scrollbars.

This would also make the #1860 fans happy.

[vefatica]

I've never been a fan of a horizintal scroll bar. And even though I don't follow issues closely, I somehow got the impression that a horizontal scroll bar was definitely not going to happen in WT.

[zadjii-msft]

If it was a "definitely not going to happen", I'd close it out. I had thoughts in #1860 (comment) that I've used to keep my mind open for the last two years.

I dunno, I'm still kinda of the impression we should reject client resizes if there are more than one pane[1]. The "virtual width" with a horizontal scrollbar - that kinda can make sense, sure. But then what about increasing the height? How could we indicate that?

[1]: Though, like, what if you zoomed a single pane, then ran mode - should that resize the Terminal? I guess maybe.

[j4james]

The "virtual width" with a horizontal scrollbar - that kinda can make sense, sure. But then what about increasing the height? How could we indicate that?

Yeah, a virtual height is a bit awkward, but the way I've seen other terminals handle this is with something like a dotted line in the scrollback marking the separation between the top of the page and the rest of the scrollback. I know it's not a great UI, but it's got to be better than the page layout breaking completely.

Of course if users don't like that they can always disable the option, and then we just ignore size requests altogether. But that only really works on apps that are prepared to handle their size request being ignored.

Not that I'm in any hurry to implement this, but it's one of those things I'd like to get to eventually, because it's key part of the VT windowing extension (which includes the paging operations we were discussing recently).