-
Notifications
You must be signed in to change notification settings - Fork 25
Conversation
Added window resize event and dotted border for fixed size terminal. Window resize event will fire when terminal window size changes. It may be used to adjust the terminal size. The idea is to always fit the terminal into the window, and for that we need to know when the window resizes. Then the client can resize the terminal to fit the window, and to notify others. Here is how it will look when the terminal size smaller than the window size. The dotted border is on the right and bottom sides and uses themed color. There are no changes in the appearance for the auto-fit mode. @dgriffen this is the final iteration for VSLS, please take a look. |
/// <summary> | ||
/// An event that is fired when the terminal is resized and either Rows or Cols have changed. | ||
/// </summary> | ||
event EventHandler TerminalResized; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TerminalResized
event is not really needed:
For auto-fit mode, WindowResized is sufficient.
For fixed mode, the client already knows the terminal size and when it changes it.
I'll remove it.
b1ecbb4
to
fccd3c0
Compare
@@ -37,6 +37,7 @@ namespace Microsoft.VisualStudio.Terminal | |||
[ProvideMenuResource("Menus.ctmenu", 1)] | |||
[ProvideToolWindow(typeof(TermWindow), Style = VsDockStyle.Tabbed, Window = "34E76E81-EE4A-11D0-AE2E-00A0C90FFFC3")] | |||
[ProvideToolWindow(typeof(ServiceToolWindow), Transient = true, MultiInstances = true, Style = VsDockStyle.Tabbed, Window = TermWindow.TermWindowGuidString)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a case where we still need the old tool window? Couldn't it be implemented as a RendererToolWindow with a specific backend?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it can be implemented this way. I'll see if I can do that.
@dgriffen Updated PR as per your feedback. |
@@ -35,8 +35,7 @@ namespace Microsoft.VisualStudio.Terminal | |||
[Guid(TermWindowPackage.PackageGuidString)] | |||
[SuppressMessage("StyleCop.CSharp.DocumentationRules", "SA1650:ElementDocumentationMustBeSpelledCorrectly", Justification = "pkgdef, VS and vsixmanifest are valid VS terms")] | |||
[ProvideMenuResource("Menus.ctmenu", 1)] | |||
[ProvideToolWindow(typeof(TermWindow), Style = VsDockStyle.Tabbed, Window = "34E76E81-EE4A-11D0-AE2E-00A0C90FFFC3")] | |||
[ProvideToolWindow(typeof(ServiceToolWindow), Transient = true, MultiInstances = true, Style = VsDockStyle.Tabbed, Window = TermWindow.TermWindowGuidString)] | |||
[ProvideToolWindow(typeof(TermWindow), Transient = true, MultiInstances = true, Style = VsDockStyle.Tabbed, Window = "34E76E81-EE4A-11D0-AE2E-00A0C90FFFC3")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm concerned about the implications of only having one tool window here. The original suggestion was just to remove the duplication of the renderer and the service window. The reason there were two windows to begin with was that a multi-instance window would not persist across sessions nor remember its last position if you closed and reopened it. The two-window solution allowed there to be a "main" terminal window that was accessible from a shortcut and menu command and that all of the temporary windows would be able to dock to its location, allowing the user to have a preference on their terminal location.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. Will fix
@dgriffen Updated again per your feedback. Fixed the window transient state for embedded terminal window. |
Looks good to me! I'll merge this and then run through some testing to make sure everything still works as expected. How soon do you want a release so that you can begin consuming it in LiveShare? |
The sooner the better. I already have VSLS changes ready. |
I'll try and get something out this weekend then. |
@dgriffen, this is for #56 TerminalRenderer API
This PR adds support for
ITerminalRenderer
. Terminal renderer encapsulates terminal UI with xterm control on VS tool window, and delegates handling of terminal stdio streams and resizing to the consumer.There are two kinds of renderers: auto-fit and fixed size.
Auto-fit renderer behaves the same way as the normal terminal, always fitting its tool window. Whenever it is resized, it fires the
TerminalResized
event.Fixed size renderer starts with predefined size and always keeps this size, regardless of the tool window. This size later can be changed with
ITerminalRenderer.ResizeAsync()
. If the tool window is smaller than the fixed size renderer, the renderer is clipped. If the tool window is larger, empty space is filled with background color. Vertical scroll bar always appears on the right size of the tool window, unless the tool window is smaller and it clips the render. There are no double scroll bars.