2019-05-03 00:29:04 +02:00
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
# pragma once
# include "TermControl.g.h"
2019-08-20 00:59:01 +02:00
# include "CopyToClipboardEventArgs.g.h"
2019-05-03 00:29:04 +02:00
# include "PasteFromClipboardEventArgs.g.h"
2020-09-03 19:52:39 +02:00
# include "OpenHyperlinkEventArgs.g.h"
2019-05-03 00:29:04 +02:00
# include <winrt/Microsoft.Terminal.TerminalConnection.h>
# include "../../renderer/base/Renderer.hpp"
# include "../../renderer/dx/DxRenderer.hpp"
2019-12-11 22:52:49 +01:00
# include "../../renderer/uia/UiaRenderer.hpp"
2019-05-03 00:29:04 +02:00
# include "../../cascadia/TerminalCore/Terminal.hpp"
Search - add search box control and implement search experience (#3590)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
This is the PR for feature Search: #605
This PR includes the newly introduced SearchBoxControl in TermControl dir, which is the search bar for the search experience. And the codes that enable Search in Windows Terminal.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
The PR that migrates the Conhost search module: https://github.com/microsoft/terminal/pull/3279
Spec (still actively updating): https://github.com/microsoft/terminal/pull/3299
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #605
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
These functionalities are included in the search experience.
1. Search in Terminal text buffer.
2. Automatic wrap-around.
3. Search up or down switch by clicking different buttons.
4. Search case sensitively/insensitively by clicking a button. S. Move the search box to the top/bottom by clicking a button.
6. Close by clicking 'X'.
7. Open search by ctrl + F.
When the searchbox is open, the user could still interact with the terminal by clicking the terminal input area.
While I already have the search functionalities, currently there are still some known to-do works and I will keep updating my PR:
1. Optimize the search box UI, this includes:
1) Theme adaptation. The search box background and font color
should change according to the theme,
2) Add background. Currently the elements in search box are all
transparent. However, we need a background.
3) Move button should be highlighted once clicked.
2. Accessibility: search process should be able to performed without mouse. Once the search box is focused, the user should be able to navigate between all interactive elements on the searchbox using keyboard.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
To test:
1. checkout this branch.
2. Build the project.
3. Start Windows Terminal and press Ctrl+F
4. The search box should appear on the top right corner.
2019-12-17 16:52:37 +01:00
# include "../buffer/out/search.h"
Add a Windows.UI.Text.Core IME overlay to TerminalControl (#1919)
TerminalControl doesn't use any of the built in text input and edit
controls provided by XAML for text input, which means TermianlControl
needs to communicate with the Text Services Framework (TSF) in order to
provide Input Method Editor (IME) support. Just like the rest of
Terminal we get to take advantage of newer APIs (Windows.UI.Text.Core)
namespace to provide support vs. the old TSF 1.0.
Windows.UI.Text.Core handles communication between a text edit control
and the text services primarily through a CoreTextEditContext object.
This change introduces a new UserControl TSFInputControl which is a
custom EditControl similar to the CustomEditControl sample[1].
TSFInputControl is similar (overlay with IME text) to how old console
(conimeinfo) handled IME.
# Details
TSFInputControl is a Windows.UI.Xaml.Controls.UserControl
TSFInputControl contains a Canvas control for absolution positioning a
TextBlock control within its containing control (TerminalControl).
The TextBlock control is used for displaying candidate text from the
IME. When the user makes a choice in the IME the TextBlock is cleared
and the text is written to the Terminal buffer like normal text.
TSFInputControl creates an instance of the CoreTextEditContext and
attaches appropriate event handlers to CoreTextEditContext in order to
interact with the IME.
A good write-up on how to interact with CoreTextEditContext can be found
here[2].
## Text Updates
Text updates from the IME come in on the TextUpdating event handler,
text updates are stored in an internal buffer (_inputBuffer).
## Completed Text
Once a user selects a text in the IME, the CompositionCompleted handler
is invoked. The input buffer (_inputBuffer) is written to the Terminal
buffer, _inputBuffer is cleared and Canvas and TextBlock controls are
hidden until the user starts a composition session again.
## Positioning
Telling the IME where to properly position itself was the hardest part
of this change. The IME expects to know it's location in screen
coordinates as supposed to client coordinates. This is pretty easy if
you are a pure UWP, but since we are hosted inside a XAMLIsland the
client to screen coordinate translation is a little harder.
### Calculating Screen Coordinates
1. Obtaining the Window position in Screen coordinates.
2. Determining the Client coordinate of the cursor.
3. Converting the Client coordinate of the cursor to Screen coordinates.
4. Offsetting the X and Y coordinate of the cursor by the position of
the TerminalControl within the window (tabs if present, margins, etc..).
5. Applying any scale factor of the display.
Once we have the right position in screen coordinates, this is supplied
in the LayoutBounds of the CoreTextLayoutRequestedEventArgs which lets
the IME know where to position itself on the Screen.
## Font Information/Cursor/Writing to Terminal
3 events were added to the TSFInputControl to create a loosely-coupled
implementation between the TerminalControl and the TSFInputControl.
These events are used for obtaining Font information from the
TerminalControl, getting the Cursor position and writing to the terminal
buffer.
## Known Issues
- Width of TextBlock is hardcoded to 200 pixels and most likely should
adjust to the available width of the current input line on the console
(#3640)
- Entering text in the middle of an existing set of text has TextBlock
render under existing text. Current Console behavior here isn't good
experience either (writes over text)
- Text input at edges of window is clipped versus wrapping around to
next line. This isn't any worse than the original command line, but
Terminal should be better (#3657)
## Future Considerations
Ideally, we'd be able to interact with the console buffer directly and
replace characters as the user types.
## Validation
General steps to try functionality
- Open Console
- Switch to Simplified Chinese (Shortcut: Windows+Spacebar)
- Switch to Chinese mode on language bar
Scenarios validated:
- As user types unformatted candidates appear on command line and IME
renders in correct position under unformatted characters.
- User can dismiss IME and text doesn't appear on command line
- Switch back to English mode, functions like normal
- New tab has proper behavior
- Switching between tabs has proper behavior
- Switching away from Terminal Window with IME present causes IME to
disappear
[1]: https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/CustomEditControl
[2]: https://docs.microsoft.com/en-us/windows/uwp/design/input/custom-text-input
Closes #459
Closes #2213
Closes #3641
2019-11-22 01:25:50 +01:00
# include "cppwinrt_utils.h"
Search - add search box control and implement search experience (#3590)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
This is the PR for feature Search: #605
This PR includes the newly introduced SearchBoxControl in TermControl dir, which is the search bar for the search experience. And the codes that enable Search in Windows Terminal.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
The PR that migrates the Conhost search module: https://github.com/microsoft/terminal/pull/3279
Spec (still actively updating): https://github.com/microsoft/terminal/pull/3299
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #605
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
These functionalities are included in the search experience.
1. Search in Terminal text buffer.
2. Automatic wrap-around.
3. Search up or down switch by clicking different buttons.
4. Search case sensitively/insensitively by clicking a button. S. Move the search box to the top/bottom by clicking a button.
6. Close by clicking 'X'.
7. Open search by ctrl + F.
When the searchbox is open, the user could still interact with the terminal by clicking the terminal input area.
While I already have the search functionalities, currently there are still some known to-do works and I will keep updating my PR:
1. Optimize the search box UI, this includes:
1) Theme adaptation. The search box background and font color
should change according to the theme,
2) Add background. Currently the elements in search box are all
transparent. However, we need a background.
3) Move button should be highlighted once clicked.
2. Accessibility: search process should be able to performed without mouse. Once the search box is focused, the user should be able to navigate between all interactive elements on the searchbox using keyboard.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
To test:
1. checkout this branch.
2. Build the project.
3. Start Windows Terminal and press Ctrl+F
4. The search box should appear on the top right corner.
2019-12-17 16:52:37 +01:00
# include "SearchBoxControl.h"
2020-06-12 21:51:37 +02:00
# include "ThrottledFunc.h"
2019-05-03 00:29:04 +02:00
2020-08-08 01:21:09 +02:00
namespace Microsoft : : Console : : VirtualTerminal
{
struct MouseButtonState ;
}
2019-05-03 00:29:04 +02:00
namespace winrt : : Microsoft : : Terminal : : TerminalControl : : implementation
{
2019-08-20 00:59:01 +02:00
struct CopyToClipboardEventArgs :
public CopyToClipboardEventArgsT < CopyToClipboardEventArgs >
{
public :
Add copyFormatting keybinding arg and array support (#6004)
Adds array support for the existing `copyFormatting` global setting.
This allows users to define which formats they would specifically like
to be copied.
A boolean value is still accepted and is translated to the following:
- `false` --> `"none"` or `[]`
- `true` --> `"all"` or `["html", "rtf"]`
This also adds `copyFormatting` as a keybinding arg for `copy`. As with
the global setting, a boolean value and array value is accepted.
CopyFormat is a WinRT enum where each accepted format is a flag.
Currently accepted formats include `html`, and `rtf`. A boolean value is
accepted and converted. `true` is a conjunction of all the formats.
`false` only includes plain text.
For the global setting, `null` is not accepted. We already have a
default value from before so no worries there.
For the keybinding arg, `null` (the default value) means that we just do
what the global arg says to do. Overall, the `copyFormatting` keybinding
arg is an override of the global setting **when using that keybinding**.
References #5212 - Spec for formatted copying
References #2690 - disable html copy
Validated behavior with every combination of values below:
- `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` }
- `copyFormatting` copy arg:
{ `null`, `true`, `false`, `[]`, `[, "html"]`}
Closes #4191
Closes #5262
2020-08-15 03:02:24 +02:00
CopyToClipboardEventArgs ( hstring text ) :
_text ( text ) ,
_html ( ) ,
_rtf ( ) ,
_formats ( static_cast < CopyFormat > ( 0 ) ) { }
CopyToClipboardEventArgs ( hstring text , hstring html , hstring rtf , Windows : : Foundation : : IReference < CopyFormat > formats ) :
2019-08-20 00:59:01 +02:00
_text ( text ) ,
2019-11-13 21:13:22 +01:00
_html ( html ) ,
Add copyFormatting keybinding arg and array support (#6004)
Adds array support for the existing `copyFormatting` global setting.
This allows users to define which formats they would specifically like
to be copied.
A boolean value is still accepted and is translated to the following:
- `false` --> `"none"` or `[]`
- `true` --> `"all"` or `["html", "rtf"]`
This also adds `copyFormatting` as a keybinding arg for `copy`. As with
the global setting, a boolean value and array value is accepted.
CopyFormat is a WinRT enum where each accepted format is a flag.
Currently accepted formats include `html`, and `rtf`. A boolean value is
accepted and converted. `true` is a conjunction of all the formats.
`false` only includes plain text.
For the global setting, `null` is not accepted. We already have a
default value from before so no worries there.
For the keybinding arg, `null` (the default value) means that we just do
what the global arg says to do. Overall, the `copyFormatting` keybinding
arg is an override of the global setting **when using that keybinding**.
References #5212 - Spec for formatted copying
References #2690 - disable html copy
Validated behavior with every combination of values below:
- `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` }
- `copyFormatting` copy arg:
{ `null`, `true`, `false`, `[]`, `[, "html"]`}
Closes #4191
Closes #5262
2020-08-15 03:02:24 +02:00
_rtf ( rtf ) ,
_formats ( formats ) { }
2019-08-20 00:59:01 +02:00
hstring Text ( ) { return _text ; } ;
hstring Html ( ) { return _html ; } ;
2019-11-13 21:13:22 +01:00
hstring Rtf ( ) { return _rtf ; } ;
Add copyFormatting keybinding arg and array support (#6004)
Adds array support for the existing `copyFormatting` global setting.
This allows users to define which formats they would specifically like
to be copied.
A boolean value is still accepted and is translated to the following:
- `false` --> `"none"` or `[]`
- `true` --> `"all"` or `["html", "rtf"]`
This also adds `copyFormatting` as a keybinding arg for `copy`. As with
the global setting, a boolean value and array value is accepted.
CopyFormat is a WinRT enum where each accepted format is a flag.
Currently accepted formats include `html`, and `rtf`. A boolean value is
accepted and converted. `true` is a conjunction of all the formats.
`false` only includes plain text.
For the global setting, `null` is not accepted. We already have a
default value from before so no worries there.
For the keybinding arg, `null` (the default value) means that we just do
what the global arg says to do. Overall, the `copyFormatting` keybinding
arg is an override of the global setting **when using that keybinding**.
References #5212 - Spec for formatted copying
References #2690 - disable html copy
Validated behavior with every combination of values below:
- `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` }
- `copyFormatting` copy arg:
{ `null`, `true`, `false`, `[]`, `[, "html"]`}
Closes #4191
Closes #5262
2020-08-15 03:02:24 +02:00
Windows : : Foundation : : IReference < CopyFormat > Formats ( ) { return _formats ; } ;
2019-08-20 00:59:01 +02:00
private :
hstring _text ;
hstring _html ;
2019-11-13 21:13:22 +01:00
hstring _rtf ;
Add copyFormatting keybinding arg and array support (#6004)
Adds array support for the existing `copyFormatting` global setting.
This allows users to define which formats they would specifically like
to be copied.
A boolean value is still accepted and is translated to the following:
- `false` --> `"none"` or `[]`
- `true` --> `"all"` or `["html", "rtf"]`
This also adds `copyFormatting` as a keybinding arg for `copy`. As with
the global setting, a boolean value and array value is accepted.
CopyFormat is a WinRT enum where each accepted format is a flag.
Currently accepted formats include `html`, and `rtf`. A boolean value is
accepted and converted. `true` is a conjunction of all the formats.
`false` only includes plain text.
For the global setting, `null` is not accepted. We already have a
default value from before so no worries there.
For the keybinding arg, `null` (the default value) means that we just do
what the global arg says to do. Overall, the `copyFormatting` keybinding
arg is an override of the global setting **when using that keybinding**.
References #5212 - Spec for formatted copying
References #2690 - disable html copy
Validated behavior with every combination of values below:
- `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` }
- `copyFormatting` copy arg:
{ `null`, `true`, `false`, `[]`, `[, "html"]`}
Closes #4191
Closes #5262
2020-08-15 03:02:24 +02:00
Windows : : Foundation : : IReference < CopyFormat > _formats ;
2019-08-20 00:59:01 +02:00
} ;
2019-05-03 00:29:04 +02:00
struct PasteFromClipboardEventArgs :
public PasteFromClipboardEventArgsT < PasteFromClipboardEventArgs >
{
public :
2019-06-11 22:27:09 +02:00
PasteFromClipboardEventArgs ( std : : function < void ( std : : wstring ) > clipboardDataHandler ) :
m_clipboardDataHandler ( clipboardDataHandler ) { }
2019-05-03 00:29:04 +02:00
void HandleClipboardData ( hstring value )
{
m_clipboardDataHandler ( static_cast < std : : wstring > ( value ) ) ;
} ;
private :
std : : function < void ( std : : wstring ) > m_clipboardDataHandler ;
} ;
2020-09-03 19:52:39 +02:00
struct OpenHyperlinkEventArgs :
public OpenHyperlinkEventArgsT < OpenHyperlinkEventArgs >
{
public :
OpenHyperlinkEventArgs ( hstring uri ) :
_uri ( uri ) { }
hstring Uri ( ) { return _uri ; } ;
private :
hstring _uri ;
} ;
2019-05-03 00:29:04 +02:00
struct TermControl : TermControlT < TermControl >
{
2020-08-07 16:46:52 +02:00
TermControl ( IControlSettings settings , TerminalConnection : : ITerminalConnection connection ) ;
2019-05-03 00:29:04 +02:00
2020-08-07 16:46:52 +02:00
winrt : : fire_and_forget UpdateSettings ( IControlSettings newSettings ) ;
2019-05-03 00:29:04 +02:00
hstring Title ( ) ;
2020-02-28 01:37:56 +01:00
hstring GetProfileName ( ) const ;
2019-08-17 00:43:51 +02:00
Add copyFormatting keybinding arg and array support (#6004)
Adds array support for the existing `copyFormatting` global setting.
This allows users to define which formats they would specifically like
to be copied.
A boolean value is still accepted and is translated to the following:
- `false` --> `"none"` or `[]`
- `true` --> `"all"` or `["html", "rtf"]`
This also adds `copyFormatting` as a keybinding arg for `copy`. As with
the global setting, a boolean value and array value is accepted.
CopyFormat is a WinRT enum where each accepted format is a flag.
Currently accepted formats include `html`, and `rtf`. A boolean value is
accepted and converted. `true` is a conjunction of all the formats.
`false` only includes plain text.
For the global setting, `null` is not accepted. We already have a
default value from before so no worries there.
For the keybinding arg, `null` (the default value) means that we just do
what the global arg says to do. Overall, the `copyFormatting` keybinding
arg is an override of the global setting **when using that keybinding**.
References #5212 - Spec for formatted copying
References #2690 - disable html copy
Validated behavior with every combination of values below:
- `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` }
- `copyFormatting` copy arg:
{ `null`, `true`, `false`, `[]`, `[, "html"]`}
Closes #4191
Closes #5262
2020-08-15 03:02:24 +02:00
bool CopySelectionToClipboard ( bool singleLine , const Windows : : Foundation : : IReference < CopyFormat > & formats ) ;
2019-06-25 21:17:02 +02:00
void PasteTextFromClipboard ( ) ;
2019-05-03 00:29:04 +02:00
void Close ( ) ;
Enable resizing the panes with the keyboard. (#1207)
Adds the ability to resize panes with the keyboard.
This is accomplished by making the Column/RowDefinitions for a Pane use `GridLengthHelper::FromPixels` to set their size. We store a pair of floats that represents the relative amount that each pane takes out of the parent pane. When the window is resized, we use that percentage to figure out the new size of each child in pixels, and manually size each column.
Then, when the user presses the keybindings for resizePane{Left/Right/Up/Down}, we'll adjust those percentages, and resize the rows/cols as appropriate.
Currently, each pane adjusts the width/height by 5% of the total size at a time. I am not in love with this, but it works for now. I think when we get support for keybindings with arbitrary arg blobs, then we could do either a percent movement, or a number of characters at a time. The number of characters one would be trickier, because we'd have to get the focused control, and get the number of pixels per character, as adjacent panes might not have the same font sizes.
2019-07-10 15:27:12 +02:00
Windows : : Foundation : : Size CharacterDimensions ( ) const ;
2020-02-27 01:35:16 +01:00
Windows : : Foundation : : Size MinimumSize ( ) ;
float SnapDimensionToGrid ( const bool widthOrHeight , const float dimension ) ;
2019-05-03 00:29:04 +02:00
void ScrollViewport ( int viewTop ) ;
int GetScrollOffset ( ) ;
2019-05-15 15:21:14 +02:00
int GetViewHeight ( ) const ;
2019-05-03 00:29:04 +02:00
2019-09-30 15:18:05 +02:00
void AdjustFontSize ( int fontSizeDelta ) ;
2019-11-25 18:35:10 +01:00
void ResetFontSize ( ) ;
2019-09-30 15:18:05 +02:00
2020-08-12 15:46:53 +02:00
void SendInput ( const winrt : : hstring & input ) ;
2020-07-02 01:17:43 +02:00
void ToggleRetroEffect ( ) ;
2020-03-27 00:25:11 +01:00
winrt : : fire_and_forget RenderEngineSwapChainChanged ( ) ;
void _AttachDxgiSwapChainToXaml ( IDXGISwapChain1 * swapChain ) ;
2020-04-14 22:11:47 +02:00
winrt : : fire_and_forget _RendererEnteredErrorState ( ) ;
void _RenderRetryButton_Click ( IInspectable const & button , IInspectable const & args ) ;
Search - add search box control and implement search experience (#3590)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
This is the PR for feature Search: #605
This PR includes the newly introduced SearchBoxControl in TermControl dir, which is the search bar for the search experience. And the codes that enable Search in Windows Terminal.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
The PR that migrates the Conhost search module: https://github.com/microsoft/terminal/pull/3279
Spec (still actively updating): https://github.com/microsoft/terminal/pull/3299
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #605
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
These functionalities are included in the search experience.
1. Search in Terminal text buffer.
2. Automatic wrap-around.
3. Search up or down switch by clicking different buttons.
4. Search case sensitively/insensitively by clicking a button. S. Move the search box to the top/bottom by clicking a button.
6. Close by clicking 'X'.
7. Open search by ctrl + F.
When the searchbox is open, the user could still interact with the terminal by clicking the terminal input area.
While I already have the search functionalities, currently there are still some known to-do works and I will keep updating my PR:
1. Optimize the search box UI, this includes:
1) Theme adaptation. The search box background and font color
should change according to the theme,
2) Add background. Currently the elements in search box are all
transparent. However, we need a background.
3) Move button should be highlighted once clicked.
2. Accessibility: search process should be able to performed without mouse. Once the search box is focused, the user should be able to navigate between all interactive elements on the searchbox using keyboard.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
To test:
1. checkout this branch.
2. Build the project.
3. Start Windows Terminal and press Ctrl+F
4. The search box should appear on the top right corner.
2019-12-17 16:52:37 +01:00
void CreateSearchBoxControl ( ) ;
2020-08-15 01:44:39 +02:00
bool OnDirectKeyEvent ( const uint32_t vkey , const uint8_t scanCode , const bool down ) ;
2020-03-05 21:35:46 +01:00
2020-08-08 01:21:09 +02:00
bool OnMouseWheel ( const Windows : : Foundation : : Point location , const int32_t delta , const bool leftButtonDown , const bool midButtonDown , const bool rightButtonDown ) ;
Manually pass mouse wheel messages to TermControls (#5131)
## Summary of the Pull Request
As we've learned in #979, not all touchpads are created equal. Some of them have bad drivers that makes scrolling inactive windows not work. For whatever reason, these devices think the Terminal is all one giant inactive window, so we don't get the mouse wheel events through the XAML stack. We do however get the event as a `WM_MOUSEWHEEL` on those devices (a message we don't get on devices with normally functioning trackpads).
This PR attempts to take that `WM_MOUSEWHEEL` and manually dispatch it to the `TermControl`, so we can at least scroll the terminal content.
Unfortunately, this solution is not very general purpose. This only works to scroll controls that manually implement our own `IMouseWheelListener` interface. As we add more controls, we'll need to continue manually implementing this interface, until the underlying XAML Islands bug is fixed. **I don't love this**. I'd rather have a better solution, but it seems that we can't synthesize a more general-purpose `PointerWheeled` event that could get routed through the XAML tree as normal.
## References
* #2606 and microsoft/microsoft-ui-xaml#2101 - these bugs are also tracking a similar "inactive windows" / "scaled mouse events" issue in XAML
## PR Checklist
* [x] Closes #979
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
I've also added a `til::point` conversion _to_ `winrt::Windows::Foundation::Point`, and some scaling operators for `point`
## Validation Steps Performed
* It works on my HP Spectre 2017 with a synaptics trackpad
- I also made sure to test that `tmux` works in panes on this laptop
* It works on my slaptop, and DOESN'T follow this hack codepath on this machine.
2020-04-01 18:58:16 +02:00
2020-10-28 21:24:43 +01:00
void UpdatePatternLocations ( ) ;
2019-05-03 00:29:04 +02:00
~ TermControl ( ) ;
Accessibility: TermControl Automation Peer (#2083)
Builds on the work of #1691 and #1915
Let's start with the easy change:
- `TermControl`'s `controlRoot` was removed. `TermControl` is a `UserControl`
now.
Ok. Now we've got a story to tell here....
### TermControlAP - the Automation Peer
Here's an in-depth guide on custom automation peers:
https://docs.microsoft.com/en-us/windows/uwp/design/accessibility/custom-automation-peers
We have a custom XAML element (TermControl). So XAML can't really hold our
hands and determine an accessible behavior for us. So this automation peer is
responsible for enabling that interaction.
We made it a FrameworkElementAutomationPeer to get as much accessibility as
possible from it just being a XAML element (i.e.: where are we on the screen?
what are my dimensions?). This is recommended. Any functions with "Core" at the
end, are overwritten here to tweak this automation peer into what we really
need.
But what kind of interactions can a user expect from this XAML element?
Introducing ControlPatterns! There's a ton of interfaces that just define "what
can I do". Thankfully, we already know that we're supposed to be
`ScreenInfoUiaProvider` and that was an `ITextProvider`, so let's just make the
TermControlAP an `ITextProvider` too.
So now we have a way to define what accessible actions can be performed on us,
but what should those actions do? Well let's just use the automation providers
from ConHost that are now in a shared space! (Note: this is a great place to
stop and get some coffee. We're about to hop into the .cpp file in the next
section)
### Wrapping our shared Automation Providers
Unfortunately, we can't just use the automation providers from ConHost. Or, at
least not just hook them up as easily as we wish. ConHost's UIA Providers were
written using UIAutomationCore and ITextRangeProiuder. XAML's interfaces
ITextProvider and ITextRangeProvider are lined up to be exactly the same.
So we need to wrap our ConHost UIA Providers (UIAutomationCore) with the XAML
ones. We had two providers, so that means we have two wrappers.
#### TermControlAP (XAML) <----> ScreenInfoUiaProvider (UIAutomationCore)
Each of the functions in the pragma region `ITextProvider` for
TermControlAP.cpp is just wrapping what we do in `ScreenInfoUiaProvider`, and
returning an acceptable version of it.
Most of `ScreenInfoUiaProvider`'s functions return `UiaTextRange`s. So we need
to wrap that too. That's this next section...
#### XamlUiaTextRange (XAML) <----> UiaTextRange (UIAutomationCore)
Same idea. We're wrapping everything that we could do with `UiaTextRange` and
putting it inside of `XamlUiaTextRange`.
### Additional changes to `UiaTextRange` and `ScreenInfoUiaProvider`
If you don't know what I just said, please read this background:
- #1691: how accessibility works and the general responsibility of these two
classes
- #1915: how we pulled these Accessibility Providers into a shared area
TL;DR: `ScreenInfoUiaProvider` lets you interact with the displayed text.
`UiaTextRange` is specific ranges of text in the display and navigate the text.
Thankfully, we didn't do many changes here. I feel like some of it is hacked
together but now that we have a somewhat working system, making changes
shouldn't be too hard...I hope.
#### UiaTextRange
We don't have access to the window handle. We really only need it to draw the
bounding rects using WinUser's `ScreenToClient()` and `ClientToScreen()`. I
need to figure out how to get around this.
In the meantime, I made the window handle optional. And if we don't have
one....well, we need to figure that out. But other than that, we have a
`UiaTextRange`.
#### ScreenInfoUiaProvider
At some point, we need to hook up this automation provider to the
WindowUiaProvider. This should help with navigation of the UIA Tree and make
everything just look waaaay better. For now, let's just do the same approach
and make the pUiaParent optional.
This one's the one I'm not that proud of, but it works. We need the parent to
get a bounding rect of the terminal. While we figure out how to attach the
WindowUiaProvider, we should at the very least be able to get a bunch of info
from our xaml automation peer. So, I've added a _getBoundingRect optional
function. This is what's called when we don't have a WindowUiaProvider as our
parent.
## Validation Steps Performed
I've been using inspect.exe to see the UIA tree.
I was able to interact with the terminal mostly fine. A few known issues below.
Unfortunately, I tried running Narrator on this and it didn't seem to like it
(by that I mean WT crashed). Then again, I don't really know how to use
narrator other than "click on object" --> "listen voice". I feel like there's a
way to get the other interactions with narrator, but I'll be looking into more
of that soon. I bet if I fix the two issues below, Narrator will be happy.
## Miscellaneous Known Issues
- `GetSelection()` and `GetVisibleRanges()` crashes. I need to debug through
these. I want to include them in this PR.
Fixes #1353.
2019-07-31 01:43:10 +02:00
Windows : : UI : : Xaml : : Automation : : Peers : : AutomationPeer OnCreateAutomationPeer ( ) ;
2019-08-19 20:03:45 +02:00
: : Microsoft : : Console : : Types : : IUiaData * GetUiaData ( ) const ;
2019-08-21 02:50:34 +02:00
const FontInfo GetActualFont ( ) const ;
2020-02-27 01:35:16 +01:00
const Windows : : UI : : Xaml : : Thickness GetPadding ( ) ;
Accessibility: TermControl Automation Peer (#2083)
Builds on the work of #1691 and #1915
Let's start with the easy change:
- `TermControl`'s `controlRoot` was removed. `TermControl` is a `UserControl`
now.
Ok. Now we've got a story to tell here....
### TermControlAP - the Automation Peer
Here's an in-depth guide on custom automation peers:
https://docs.microsoft.com/en-us/windows/uwp/design/accessibility/custom-automation-peers
We have a custom XAML element (TermControl). So XAML can't really hold our
hands and determine an accessible behavior for us. So this automation peer is
responsible for enabling that interaction.
We made it a FrameworkElementAutomationPeer to get as much accessibility as
possible from it just being a XAML element (i.e.: where are we on the screen?
what are my dimensions?). This is recommended. Any functions with "Core" at the
end, are overwritten here to tweak this automation peer into what we really
need.
But what kind of interactions can a user expect from this XAML element?
Introducing ControlPatterns! There's a ton of interfaces that just define "what
can I do". Thankfully, we already know that we're supposed to be
`ScreenInfoUiaProvider` and that was an `ITextProvider`, so let's just make the
TermControlAP an `ITextProvider` too.
So now we have a way to define what accessible actions can be performed on us,
but what should those actions do? Well let's just use the automation providers
from ConHost that are now in a shared space! (Note: this is a great place to
stop and get some coffee. We're about to hop into the .cpp file in the next
section)
### Wrapping our shared Automation Providers
Unfortunately, we can't just use the automation providers from ConHost. Or, at
least not just hook them up as easily as we wish. ConHost's UIA Providers were
written using UIAutomationCore and ITextRangeProiuder. XAML's interfaces
ITextProvider and ITextRangeProvider are lined up to be exactly the same.
So we need to wrap our ConHost UIA Providers (UIAutomationCore) with the XAML
ones. We had two providers, so that means we have two wrappers.
#### TermControlAP (XAML) <----> ScreenInfoUiaProvider (UIAutomationCore)
Each of the functions in the pragma region `ITextProvider` for
TermControlAP.cpp is just wrapping what we do in `ScreenInfoUiaProvider`, and
returning an acceptable version of it.
Most of `ScreenInfoUiaProvider`'s functions return `UiaTextRange`s. So we need
to wrap that too. That's this next section...
#### XamlUiaTextRange (XAML) <----> UiaTextRange (UIAutomationCore)
Same idea. We're wrapping everything that we could do with `UiaTextRange` and
putting it inside of `XamlUiaTextRange`.
### Additional changes to `UiaTextRange` and `ScreenInfoUiaProvider`
If you don't know what I just said, please read this background:
- #1691: how accessibility works and the general responsibility of these two
classes
- #1915: how we pulled these Accessibility Providers into a shared area
TL;DR: `ScreenInfoUiaProvider` lets you interact with the displayed text.
`UiaTextRange` is specific ranges of text in the display and navigate the text.
Thankfully, we didn't do many changes here. I feel like some of it is hacked
together but now that we have a somewhat working system, making changes
shouldn't be too hard...I hope.
#### UiaTextRange
We don't have access to the window handle. We really only need it to draw the
bounding rects using WinUser's `ScreenToClient()` and `ClientToScreen()`. I
need to figure out how to get around this.
In the meantime, I made the window handle optional. And if we don't have
one....well, we need to figure that out. But other than that, we have a
`UiaTextRange`.
#### ScreenInfoUiaProvider
At some point, we need to hook up this automation provider to the
WindowUiaProvider. This should help with navigation of the UIA Tree and make
everything just look waaaay better. For now, let's just do the same approach
and make the pUiaParent optional.
This one's the one I'm not that proud of, but it works. We need the parent to
get a bounding rect of the terminal. While we figure out how to attach the
WindowUiaProvider, we should at the very least be able to get a bunch of info
from our xaml automation peer. So, I've added a _getBoundingRect optional
function. This is what's called when we don't have a WindowUiaProvider as our
parent.
## Validation Steps Performed
I've been using inspect.exe to see the UIA tree.
I was able to interact with the terminal mostly fine. A few known issues below.
Unfortunately, I tried running Narrator on this and it didn't seem to like it
(by that I mean WT crashed). Then again, I don't really know how to use
narrator other than "click on object" --> "listen voice". I feel like there's a
way to get the other interactions with narrator, but I'll be looking into more
of that soon. I bet if I fix the two issues below, Narrator will be happy.
## Miscellaneous Known Issues
- `GetSelection()` and `GetVisibleRanges()` crashes. I need to debug through
these. I want to include them in this PR.
Fixes #1353.
2019-07-31 01:43:10 +02:00
2019-11-25 23:22:29 +01:00
TerminalConnection : : ConnectionState ConnectionState ( ) const ;
2020-08-10 18:21:56 +02:00
IControlSettings Settings ( ) const ;
2019-11-25 23:22:29 +01:00
2020-08-07 16:46:52 +02:00
static Windows : : Foundation : : Size GetProposedDimensions ( IControlSettings const & settings , const uint32_t dpi ) ;
Add support for running a `wt` commandline in the curent window WITH A KEYBINDING (#6537)
## Summary of the Pull Request
Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_.
## References
* Related to #4472
* Related to #5400 - I need this for the commandline mode of the Command Palette
* Related to #5970
## PR Checklist
* [x] Closes oh, there's not actually an issue for this.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - yes it does
## Detailed Description of the Pull Request / Additional comments
One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again.
We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up.
This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out.
This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized.
## Validation Steps Performed
This was what the json blob I was using for testing evolved into
```json
{
"command": {
"action":"wt",
"commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0",
},
"keys": ["ctrl+shift+n"]
}
```
I also added some tests.
# TODO
* [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process?
- Probably should just do nothing for the empty string
2020-07-17 23:05:29 +02:00
static Windows : : Foundation : : Size GetProposedDimensions ( const winrt : : Windows : : Foundation : : Size & initialSizeInChars ,
const int32_t & fontSize ,
const winrt : : Windows : : UI : : Text : : FontWeight & fontWeight ,
const winrt : : hstring & fontFace ,
2020-08-07 16:46:52 +02:00
const ScrollbarState & scrollState ,
Add support for running a `wt` commandline in the curent window WITH A KEYBINDING (#6537)
## Summary of the Pull Request
Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_.
## References
* Related to #4472
* Related to #5400 - I need this for the commandline mode of the Command Palette
* Related to #5970
## PR Checklist
* [x] Closes oh, there's not actually an issue for this.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - yes it does
## Detailed Description of the Pull Request / Additional comments
One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again.
We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up.
This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out.
This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized.
## Validation Steps Performed
This was what the json blob I was using for testing evolved into
```json
{
"command": {
"action":"wt",
"commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0",
},
"keys": ["ctrl+shift+n"]
}
```
I also added some tests.
# TODO
* [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process?
- Probably should just do nothing for the empty string
2020-07-17 23:05:29 +02:00
const winrt : : hstring & padding ,
const uint32_t dpi ) ;
2019-05-03 00:29:04 +02:00
2020-08-08 01:07:42 +02:00
Windows : : Foundation : : IReference < winrt : : Windows : : UI : : Color > TabColor ( ) noexcept ;
2019-06-11 22:27:09 +02:00
// clang-format off
2019-05-03 00:29:04 +02:00
// -------------------------------- WinRT Events ---------------------------------
DECLARE_EVENT ( TitleChanged , _titleChangedHandlers , TerminalControl : : TitleChangedEventArgs ) ;
2020-01-08 22:19:23 +01:00
DECLARE_EVENT ( FontSizeChanged , _fontSizeChangedHandlers , TerminalControl : : FontSizeChangedEventArgs ) ;
2019-05-03 00:29:04 +02:00
DECLARE_EVENT ( ScrollPositionChanged , _scrollPositionChangedHandlers , TerminalControl : : ScrollPositionChangedEventArgs ) ;
2019-08-20 00:59:01 +02:00
DECLARE_EVENT_WITH_TYPED_EVENT_HANDLER ( PasteFromClipboard , _clipboardPasteHandlers , TerminalControl : : TermControl , TerminalControl : : PasteFromClipboardEventArgs ) ;
DECLARE_EVENT_WITH_TYPED_EVENT_HANDLER ( CopyToClipboard , _clipboardCopyHandlers , TerminalControl : : TermControl , TerminalControl : : CopyToClipboardEventArgs ) ;
2020-09-03 19:52:39 +02:00
DECLARE_EVENT_WITH_TYPED_EVENT_HANDLER ( OpenHyperlink , _openHyperlinkHandlers , TerminalControl : : TermControl , TerminalControl : : OpenHyperlinkEventArgs ) ;
2019-11-25 23:22:29 +01:00
2020-10-01 03:00:06 +02:00
TYPED_EVENT ( WarningBell , IInspectable , IInspectable ) ;
2019-11-25 23:22:29 +01:00
TYPED_EVENT ( ConnectionStateChanged , TerminalControl : : TermControl , IInspectable ) ;
2020-01-27 16:34:12 +01:00
TYPED_EVENT ( Initialized , TerminalControl : : TermControl , Windows : : UI : : Xaml : : RoutedEventArgs ) ;
2020-08-08 01:07:42 +02:00
TYPED_EVENT ( TabColorChanged , IInspectable , IInspectable ) ;
2019-06-11 22:27:09 +02:00
// clang-format on
2019-05-03 00:29:04 +02:00
private :
2020-02-27 01:35:16 +01:00
friend struct TermControlT < TermControl > ; // friend our parent so it can bind private event handlers
2019-05-03 00:29:04 +02:00
TerminalConnection : : ITerminalConnection _connection ;
bool _initializedTerminal ;
Search - add search box control and implement search experience (#3590)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
This is the PR for feature Search: #605
This PR includes the newly introduced SearchBoxControl in TermControl dir, which is the search bar for the search experience. And the codes that enable Search in Windows Terminal.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
The PR that migrates the Conhost search module: https://github.com/microsoft/terminal/pull/3279
Spec (still actively updating): https://github.com/microsoft/terminal/pull/3299
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #605
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
These functionalities are included in the search experience.
1. Search in Terminal text buffer.
2. Automatic wrap-around.
3. Search up or down switch by clicking different buttons.
4. Search case sensitively/insensitively by clicking a button. S. Move the search box to the top/bottom by clicking a button.
6. Close by clicking 'X'.
7. Open search by ctrl + F.
When the searchbox is open, the user could still interact with the terminal by clicking the terminal input area.
While I already have the search functionalities, currently there are still some known to-do works and I will keep updating my PR:
1. Optimize the search box UI, this includes:
1) Theme adaptation. The search box background and font color
should change according to the theme,
2) Add background. Currently the elements in search box are all
transparent. However, we need a background.
3) Move button should be highlighted once clicked.
2. Accessibility: search process should be able to performed without mouse. Once the search box is focused, the user should be able to navigate between all interactive elements on the searchbox using keyboard.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
To test:
1. checkout this branch.
2. Build the project.
3. Start Windows Terminal and press Ctrl+F
4. The search box should appear on the top right corner.
2019-12-17 16:52:37 +01:00
winrt : : com_ptr < SearchBoxControl > _searchBox ;
2019-05-03 00:29:04 +02:00
event_token _connectionOutputEventToken ;
2019-11-25 23:22:29 +01:00
TerminalConnection : : ITerminalConnection : : StateChanged_revoker _connectionStateChangedRevoker ;
2019-05-03 00:29:04 +02:00
2019-05-21 23:07:03 +02:00
std : : unique_ptr < : : Microsoft : : Terminal : : Core : : Terminal > _terminal ;
2019-05-03 00:29:04 +02:00
std : : unique_ptr < : : Microsoft : : Console : : Render : : Renderer > _renderer ;
std : : unique_ptr < : : Microsoft : : Console : : Render : : DxEngine > _renderEngine ;
2019-12-11 22:52:49 +01:00
std : : unique_ptr < : : Microsoft : : Console : : Render : : UiaEngine > _uiaEngine ;
2019-05-03 00:29:04 +02:00
2020-08-07 16:46:52 +02:00
IControlSettings _settings ;
2019-05-20 21:05:58 +02:00
bool _focused ;
2019-06-11 21:37:20 +02:00
std : : atomic < bool > _closing ;
2019-05-03 00:29:04 +02:00
FontInfoDesired _desiredFont ;
FontInfo _actualFont ;
2020-06-23 23:05:40 +02:00
std : : shared_ptr < ThrottledFunc < > > _tsfTryRedrawCanvas ;
2020-10-28 21:24:43 +01:00
std : : shared_ptr < ThrottledFunc < > > _updatePatternLocations ;
2020-06-12 21:51:37 +02:00
struct ScrollBarUpdate
{
std : : optional < double > newValue ;
double newMaximum ;
double newMinimum ;
double newViewportSize ;
} ;
std : : shared_ptr < ThrottledFunc < ScrollBarUpdate > > _updateScrollBar ;
bool _isInternalScrollBarUpdate ;
2020-01-06 18:39:02 +01:00
2020-07-14 03:38:11 +02:00
unsigned int _rowsToScroll ;
2019-05-03 00:29:04 +02:00
2019-07-24 18:37:17 +02:00
// Auto scroll occurs when user, while selecting, drags cursor outside viewport. View is then scrolled to 'follow' the cursor.
double _autoScrollVelocity ;
std : : optional < Windows : : UI : : Input : : PointerPoint > _autoScrollingPointerPoint ;
Windows : : UI : : Xaml : : DispatcherTimer _autoScrollTimer ;
std : : optional < std : : chrono : : high_resolution_clock : : time_point > _lastAutoScrollUpdateTime ;
2019-05-03 00:29:04 +02:00
// storage location for the leading surrogate of a utf-16 surrogate pair
std : : optional < wchar_t > _leadingSurrogate ;
2019-05-14 03:25:54 +02:00
std : : optional < Windows : : UI : : Xaml : : DispatcherTimer > _cursorTimer ;
Add support for the "blink" graphic rendition attribute (#7490)
This PR adds support for the _blink_ graphic rendition attribute. When a
character is output with this attribute set, it "blinks" at a regular
interval, by cycling its color between the normal rendition and a dimmer
shade of that color.
The majority of the blinking mechanism is encapsulated in a new
`BlinkingState` class, which is shared between the Terminal and Conhost
implementations. This class keeps track of the position in the blinking
cycle, which determines whether characters are rendered as normal or
faint.
In Windows Terminal, the state is stored in the `Terminal` class, and in
Conhost it's stored in the `CONSOLE_INFORMATION` class. In both cases,
the `IsBlinkingFaint` method is used to determine the current blinking
rendition, and that is passed on as a parameter to the
`TextAttribute::CalculateRgbColors` method when these classes are
looking up attribute colors.
Prior to calculating the colors, the current attribute is also passed to
the `RecordBlinkingUsage` method, which keeps track of whether there are
actually any blink attributes in use. This is used to determine whether
the screen needs to be refreshed when the blinking cycle toggles between
the normal and faint renditions.
The refresh itself is handled by the `ToggleBlinkingRendition` method,
which is triggered by a timer. In Conhost this is just piggybacking on
the existing cursor blink timer, but in Windows Terminal it needs to
have its own separate timer, since the cursor timer is reset whenever a
key is pressed, which is not something we want for attribute blinking.
Although the `ToggleBlinkingRendition` is called at the same rate as the
cursor blinking, we actually only want the cells to blink at half that
frequency. We thus have a counter that cycles through four phases, and
blinking is rendered as faint for two of those four. Then every two
cycles - when the state changes - a redraw is triggered, but only if
there are actually blinking attributes in use (as previously recorded).
As mentioned earlier, the blinking frequency is based on the cursor
blink rate, so that means it'll automatically be disabled if a user has
set their cursor blink rate to none. It can also be disabled by turning
off the _Show animations in Windows_ option. In Conhost these settings
take effect immediately, but in Windows Terminal they only apply when a
new tab is opened.
This PR also adds partial support for the `SGR 6` _rapid blink_
attribute. This is not used by DEC terminals, but was defined in the
ECMA/ANSI standards. It's not widely supported, but many terminals just
it implement it as an alias for the regular `SGR 5` blink attribute, so
that's what I've done here too.
## Validation Steps Performed
I've checked the _Graphic rendition test pattern_ in Vttest, and
compared our representation of the blink attribute to that of an actual
DEC VT220 terminal as seen on [YouTube]. With the right color scheme
it's a reasonably close match.
[YouTube]: https://www.youtube.com/watch?v=03Pz5AmxbE4&t=1m55s
Closes #7388
2020-09-22 01:21:33 +02:00
std : : optional < Windows : : UI : : Xaml : : DispatcherTimer > _blinkTimer ;
2019-05-14 03:25:54 +02:00
2019-05-03 00:29:04 +02:00
// If this is set, then we assume we are in the middle of panning the
// viewport via touch input.
std : : optional < winrt : : Windows : : Foundation : : Point > _touchAnchor ;
2020-09-10 23:59:56 +02:00
// Track the last cell we hovered over (used in pointerMovedHandler)
COORD _lastHoveredCell ;
// Track the last hyperlink ID we hovered over
uint16_t _lastHoveredId ;
2020-10-28 21:24:43 +01:00
std : : optional < interval_tree : : IntervalTree < til : : point , size_t > : : interval > _lastHoveredInterval ;
2019-07-12 01:06:18 +02:00
using Timestamp = uint64_t ;
// imported from WinUser
// Used for PointerPoint.Timestamp Property (https://docs.microsoft.com/en-us/uwp/api/windows.ui.input.pointerpoint.timestamp#Windows_UI_Input_PointerPoint_Timestamp)
Timestamp _multiClickTimer ;
unsigned int _multiClickCounter ;
2020-03-25 22:09:49 +01:00
Timestamp _lastMouseClickTimestamp ;
2019-07-12 01:06:18 +02:00
std : : optional < winrt : : Windows : : Foundation : : Point > _lastMouseClickPos ;
2020-03-25 22:09:49 +01:00
std : : optional < winrt : : Windows : : Foundation : : Point > _singleClickTouchdownPos ;
// This field tracks whether the selection has changed meaningfully
// since it was last copied. It's generally used to prevent copyOnSelect
// from firing when the pointer _just happens_ to be released over the
// terminal.
bool _selectionNeedsToBeCopied ;
2019-07-12 01:06:18 +02:00
2019-10-15 07:41:43 +02:00
winrt : : Windows : : UI : : Xaml : : Controls : : SwapChainPanel : : LayoutUpdated_revoker _layoutUpdatedRevoker ;
2019-06-11 21:37:20 +02:00
2019-05-03 00:29:04 +02:00
void _ApplyUISettings ( ) ;
2020-07-14 03:38:11 +02:00
void _UpdateSystemParameterSettings ( ) noexcept ;
2019-05-29 20:35:46 +02:00
void _InitializeBackgroundBrush ( ) ;
2020-05-16 00:43:00 +02:00
winrt : : fire_and_forget _BackgroundColorChanged ( const COLORREF color ) ;
2019-10-15 07:41:43 +02:00
bool _InitializeTerminal ( ) ;
2020-01-08 22:19:23 +01:00
void _UpdateFont ( const bool initialUpdate = false ) ;
Search - add search box control and implement search experience (#3590)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
This is the PR for feature Search: #605
This PR includes the newly introduced SearchBoxControl in TermControl dir, which is the search bar for the search experience. And the codes that enable Search in Windows Terminal.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
The PR that migrates the Conhost search module: https://github.com/microsoft/terminal/pull/3279
Spec (still actively updating): https://github.com/microsoft/terminal/pull/3299
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #605
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
These functionalities are included in the search experience.
1. Search in Terminal text buffer.
2. Automatic wrap-around.
3. Search up or down switch by clicking different buttons.
4. Search case sensitively/insensitively by clicking a button. S. Move the search box to the top/bottom by clicking a button.
6. Close by clicking 'X'.
7. Open search by ctrl + F.
When the searchbox is open, the user could still interact with the terminal by clicking the terminal input area.
While I already have the search functionalities, currently there are still some known to-do works and I will keep updating my PR:
1. Optimize the search box UI, this includes:
1) Theme adaptation. The search box background and font color
should change according to the theme,
2) Add background. Currently the elements in search box are all
transparent. However, we need a background.
3) Move button should be highlighted once clicked.
2. Accessibility: search process should be able to performed without mouse. Once the search box is focused, the user should be able to navigate between all interactive elements on the searchbox using keyboard.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
To test:
1. checkout this branch.
2. Build the project.
3. Start Windows Terminal and press Ctrl+F
4. The search box should appear on the top right corner.
2019-12-17 16:52:37 +01:00
void _SetFontSize ( int fontSize ) ;
2020-02-27 01:35:16 +01:00
void _TappedHandler ( Windows : : Foundation : : IInspectable const & sender , Windows : : UI : : Xaml : : Input : : TappedRoutedEventArgs const & e ) ;
2020-01-08 22:19:23 +01:00
void _KeyDownHandler ( Windows : : Foundation : : IInspectable const & sender , Windows : : UI : : Xaml : : Input : : KeyRoutedEventArgs const & e ) ;
2020-06-09 00:31:28 +02:00
void _KeyUpHandler ( Windows : : Foundation : : IInspectable const & sender , Windows : : UI : : Xaml : : Input : : KeyRoutedEventArgs const & e ) ;
2019-05-03 00:29:04 +02:00
void _CharacterHandler ( Windows : : Foundation : : IInspectable const & sender , Windows : : UI : : Xaml : : Input : : CharacterReceivedRoutedEventArgs const & e ) ;
2019-06-18 02:27:17 +02:00
void _PointerPressedHandler ( Windows : : Foundation : : IInspectable const & sender , Windows : : UI : : Xaml : : Input : : PointerRoutedEventArgs const & e ) ;
void _PointerMovedHandler ( Windows : : Foundation : : IInspectable const & sender , Windows : : UI : : Xaml : : Input : : PointerRoutedEventArgs const & e ) ;
2019-05-03 00:29:04 +02:00
void _PointerReleasedHandler ( Windows : : Foundation : : IInspectable const & sender , Windows : : UI : : Xaml : : Input : : PointerRoutedEventArgs const & e ) ;
void _MouseWheelHandler ( Windows : : Foundation : : IInspectable const & sender , Windows : : UI : : Xaml : : Input : : PointerRoutedEventArgs const & e ) ;
void _ScrollbarChangeHandler ( Windows : : Foundation : : IInspectable const & sender , Windows : : UI : : Xaml : : Controls : : Primitives : : RangeBaseValueChangedEventArgs const & e ) ;
2019-05-14 03:25:54 +02:00
void _GotFocusHandler ( Windows : : Foundation : : IInspectable const & sender , Windows : : UI : : Xaml : : RoutedEventArgs const & e ) ;
void _LostFocusHandler ( Windows : : Foundation : : IInspectable const & sender , Windows : : UI : : Xaml : : RoutedEventArgs const & e ) ;
2020-03-27 00:25:11 +01:00
winrt : : fire_and_forget _DragDropHandler ( Windows : : Foundation : : IInspectable const & sender , Windows : : UI : : Xaml : : DragEventArgs const e ) ;
2020-01-30 21:13:57 +01:00
void _DragOverHandler ( Windows : : Foundation : : IInspectable const & sender , Windows : : UI : : Xaml : : DragEventArgs const & e ) ;
2020-09-03 19:52:39 +02:00
void _HyperlinkHandler ( const std : : wstring_view uri ) ;
2019-05-03 00:29:04 +02:00
2020-03-27 00:25:11 +01:00
void _CursorTimerTick ( Windows : : Foundation : : IInspectable const & sender , Windows : : Foundation : : IInspectable const & e ) ;
Add support for the "blink" graphic rendition attribute (#7490)
This PR adds support for the _blink_ graphic rendition attribute. When a
character is output with this attribute set, it "blinks" at a regular
interval, by cycling its color between the normal rendition and a dimmer
shade of that color.
The majority of the blinking mechanism is encapsulated in a new
`BlinkingState` class, which is shared between the Terminal and Conhost
implementations. This class keeps track of the position in the blinking
cycle, which determines whether characters are rendered as normal or
faint.
In Windows Terminal, the state is stored in the `Terminal` class, and in
Conhost it's stored in the `CONSOLE_INFORMATION` class. In both cases,
the `IsBlinkingFaint` method is used to determine the current blinking
rendition, and that is passed on as a parameter to the
`TextAttribute::CalculateRgbColors` method when these classes are
looking up attribute colors.
Prior to calculating the colors, the current attribute is also passed to
the `RecordBlinkingUsage` method, which keeps track of whether there are
actually any blink attributes in use. This is used to determine whether
the screen needs to be refreshed when the blinking cycle toggles between
the normal and faint renditions.
The refresh itself is handled by the `ToggleBlinkingRendition` method,
which is triggered by a timer. In Conhost this is just piggybacking on
the existing cursor blink timer, but in Windows Terminal it needs to
have its own separate timer, since the cursor timer is reset whenever a
key is pressed, which is not something we want for attribute blinking.
Although the `ToggleBlinkingRendition` is called at the same rate as the
cursor blinking, we actually only want the cells to blink at half that
frequency. We thus have a counter that cycles through four phases, and
blinking is rendered as faint for two of those four. Then every two
cycles - when the state changes - a redraw is triggered, but only if
there are actually blinking attributes in use (as previously recorded).
As mentioned earlier, the blinking frequency is based on the cursor
blink rate, so that means it'll automatically be disabled if a user has
set their cursor blink rate to none. It can also be disabled by turning
off the _Show animations in Windows_ option. In Conhost these settings
take effect immediately, but in Windows Terminal they only apply when a
new tab is opened.
This PR also adds partial support for the `SGR 6` _rapid blink_
attribute. This is not used by DEC terminals, but was defined in the
ECMA/ANSI standards. It's not widely supported, but many terminals just
it implement it as an alias for the regular `SGR 5` blink attribute, so
that's what I've done here too.
## Validation Steps Performed
I've checked the _Graphic rendition test pattern_ in Vttest, and
compared our representation of the blink attribute to that of an actual
DEC VT220 terminal as seen on [YouTube]. With the right color scheme
it's a reasonably close match.
[YouTube]: https://www.youtube.com/watch?v=03Pz5AmxbE4&t=1m55s
Closes #7388
2020-09-22 01:21:33 +02:00
void _BlinkTimerTick ( Windows : : Foundation : : IInspectable const & sender , Windows : : Foundation : : IInspectable const & e ) ;
2019-07-24 18:37:17 +02:00
void _SetEndSelectionPointAtCursor ( Windows : : Foundation : : Point const & cursorPosition ) ;
2020-08-12 15:46:53 +02:00
void _SendInputToConnection ( const winrt : : hstring & wstr ) ;
void _SendInputToConnection ( std : : wstring_view wstr ) ;
Replacing \r\n line endings with \r line endings (#3449)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#1091
#1094
#2390
#3314
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #1091
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Combination of the PRs #1094, #2390, and #3314, especially as discussed in #3314.
In short, this changes line endings from Windows-space \r\n to the more universal \r.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Copied and pasted text into the terminal without the patch, line endings were doubled.
With the patch, line endings weren't doubled.
--------------------
* Replacing \r\n line endings with \r line endings
* Fixing Formatting
2019-11-06 15:02:55 +01:00
void _SendPastedTextToConnection ( const std : : wstring & wstr ) ;
2019-05-03 00:29:04 +02:00
void _SwapChainSizeChanged ( Windows : : Foundation : : IInspectable const & sender , Windows : : UI : : Xaml : : SizeChangedEventArgs const & e ) ;
void _SwapChainScaleChanged ( Windows : : UI : : Xaml : : Controls : : SwapChainPanel const & sender , Windows : : Foundation : : IInspectable const & args ) ;
2020-04-30 02:05:29 +02:00
void _DoResizeUnderLock ( const double newWidth , const double newHeight ) ;
void _RefreshSizeUnderLock ( ) ;
2020-10-01 03:00:06 +02:00
void _TerminalWarningBell ( ) ;
2019-05-03 00:29:04 +02:00
void _TerminalTitleChanged ( const std : : wstring_view & wstr ) ;
2020-08-08 01:07:42 +02:00
void _TerminalTabColorChanged ( const std : : optional < til : : color > color ) ;
2020-06-30 03:55:40 +02:00
void _CopyToClipboard ( const std : : wstring_view & wstr ) ;
2020-06-12 21:51:37 +02:00
void _TerminalScrollPositionChanged ( const int viewTop , const int viewHeight , const int bufferSize ) ;
2020-06-23 23:05:40 +02:00
void _TerminalCursorPositionChanged ( ) ;
2019-05-03 00:29:04 +02:00
Manually pass mouse wheel messages to TermControls (#5131)
## Summary of the Pull Request
As we've learned in #979, not all touchpads are created equal. Some of them have bad drivers that makes scrolling inactive windows not work. For whatever reason, these devices think the Terminal is all one giant inactive window, so we don't get the mouse wheel events through the XAML stack. We do however get the event as a `WM_MOUSEWHEEL` on those devices (a message we don't get on devices with normally functioning trackpads).
This PR attempts to take that `WM_MOUSEWHEEL` and manually dispatch it to the `TermControl`, so we can at least scroll the terminal content.
Unfortunately, this solution is not very general purpose. This only works to scroll controls that manually implement our own `IMouseWheelListener` interface. As we add more controls, we'll need to continue manually implementing this interface, until the underlying XAML Islands bug is fixed. **I don't love this**. I'd rather have a better solution, but it seems that we can't synthesize a more general-purpose `PointerWheeled` event that could get routed through the XAML tree as normal.
## References
* #2606 and microsoft/microsoft-ui-xaml#2101 - these bugs are also tracking a similar "inactive windows" / "scaled mouse events" issue in XAML
## PR Checklist
* [x] Closes #979
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
I've also added a `til::point` conversion _to_ `winrt::Windows::Foundation::Point`, and some scaling operators for `point`
## Validation Steps Performed
* It works on my HP Spectre 2017 with a synaptics trackpad
- I also made sure to test that `tmux` works in panes on this laptop
* It works on my slaptop, and DOESN'T follow this hack codepath on this machine.
2020-04-01 18:58:16 +02:00
void _MouseScrollHandler ( const double mouseDelta , const Windows : : Foundation : : Point point , const bool isLeftButtonPressed ) ;
2019-05-03 00:29:04 +02:00
void _MouseZoomHandler ( const double delta ) ;
void _MouseTransparencyHandler ( const double delta ) ;
2020-08-08 01:21:09 +02:00
bool _DoMouseWheel ( const Windows : : Foundation : : Point point , const : : Microsoft : : Terminal : : Core : : ControlKeyStates modifiers , const int32_t delta , const : : Microsoft : : Console : : VirtualTerminal : : TerminalInput : : MouseButtonState state ) ;
2019-05-03 00:29:04 +02:00
2019-06-18 02:27:17 +02:00
bool _CapturePointer ( Windows : : Foundation : : IInspectable const & sender , Windows : : UI : : Xaml : : Input : : PointerRoutedEventArgs const & e ) ;
bool _ReleasePointerCapture ( Windows : : Foundation : : IInspectable const & sender , Windows : : UI : : Xaml : : Input : : PointerRoutedEventArgs const & e ) ;
2019-07-24 18:37:17 +02:00
void _TryStartAutoScroll ( Windows : : UI : : Input : : PointerPoint const & pointerPoint , const double scrollVelocity ) ;
void _TryStopAutoScroll ( const uint32_t pointerId ) ;
void _UpdateAutoScroll ( Windows : : Foundation : : IInspectable const & sender , Windows : : Foundation : : IInspectable const & e ) ;
2019-06-12 03:47:27 +02:00
static Windows : : UI : : Xaml : : Thickness _ParseThicknessFromPadding ( const hstring padding ) ;
2019-05-03 00:29:04 +02:00
2020-06-09 00:31:28 +02:00
void _KeyHandler ( Windows : : UI : : Xaml : : Input : : KeyRoutedEventArgs const & e , const bool keyDown ) ;
2019-07-16 20:09:29 +02:00
: : Microsoft : : Terminal : : Core : : ControlKeyStates _GetPressedModifierKeys ( ) const ;
2020-10-20 01:55:56 +02:00
bool _TryHandleKeyBinding ( const WORD vkey , const WORD scanCode , : : Microsoft : : Terminal : : Core : : ControlKeyStates modifiers ) const ;
void _ClearKeyboardState ( const WORD vkey , const WORD scanCode ) const noexcept ;
2020-06-09 00:31:28 +02:00
bool _TrySendKeyEvent ( const WORD vkey , const WORD scanCode , : : Microsoft : : Terminal : : Core : : ControlKeyStates modifiers , const bool keyDown ) ;
2020-03-13 01:44:28 +01:00
bool _TrySendMouseEvent ( Windows : : UI : : Input : : PointerPoint const & point ) ;
bool _CanSendVTMouseInput ( ) ;
2019-05-03 00:29:04 +02:00
2019-05-22 18:34:20 +02:00
const COORD _GetTerminalPosition ( winrt : : Windows : : Foundation : : Point cursorPosition ) ;
2019-07-12 01:06:18 +02:00
const unsigned int _NumberOfClicks ( winrt : : Windows : : Foundation : : Point clickPos , Timestamp clickTime ) ;
2019-07-24 18:37:17 +02:00
double _GetAutoScrollSpeed ( double cursorDistanceFromBorder ) const ;
Add a Windows.UI.Text.Core IME overlay to TerminalControl (#1919)
TerminalControl doesn't use any of the built in text input and edit
controls provided by XAML for text input, which means TermianlControl
needs to communicate with the Text Services Framework (TSF) in order to
provide Input Method Editor (IME) support. Just like the rest of
Terminal we get to take advantage of newer APIs (Windows.UI.Text.Core)
namespace to provide support vs. the old TSF 1.0.
Windows.UI.Text.Core handles communication between a text edit control
and the text services primarily through a CoreTextEditContext object.
This change introduces a new UserControl TSFInputControl which is a
custom EditControl similar to the CustomEditControl sample[1].
TSFInputControl is similar (overlay with IME text) to how old console
(conimeinfo) handled IME.
# Details
TSFInputControl is a Windows.UI.Xaml.Controls.UserControl
TSFInputControl contains a Canvas control for absolution positioning a
TextBlock control within its containing control (TerminalControl).
The TextBlock control is used for displaying candidate text from the
IME. When the user makes a choice in the IME the TextBlock is cleared
and the text is written to the Terminal buffer like normal text.
TSFInputControl creates an instance of the CoreTextEditContext and
attaches appropriate event handlers to CoreTextEditContext in order to
interact with the IME.
A good write-up on how to interact with CoreTextEditContext can be found
here[2].
## Text Updates
Text updates from the IME come in on the TextUpdating event handler,
text updates are stored in an internal buffer (_inputBuffer).
## Completed Text
Once a user selects a text in the IME, the CompositionCompleted handler
is invoked. The input buffer (_inputBuffer) is written to the Terminal
buffer, _inputBuffer is cleared and Canvas and TextBlock controls are
hidden until the user starts a composition session again.
## Positioning
Telling the IME where to properly position itself was the hardest part
of this change. The IME expects to know it's location in screen
coordinates as supposed to client coordinates. This is pretty easy if
you are a pure UWP, but since we are hosted inside a XAMLIsland the
client to screen coordinate translation is a little harder.
### Calculating Screen Coordinates
1. Obtaining the Window position in Screen coordinates.
2. Determining the Client coordinate of the cursor.
3. Converting the Client coordinate of the cursor to Screen coordinates.
4. Offsetting the X and Y coordinate of the cursor by the position of
the TerminalControl within the window (tabs if present, margins, etc..).
5. Applying any scale factor of the display.
Once we have the right position in screen coordinates, this is supplied
in the LayoutBounds of the CoreTextLayoutRequestedEventArgs which lets
the IME know where to position itself on the Screen.
## Font Information/Cursor/Writing to Terminal
3 events were added to the TSFInputControl to create a loosely-coupled
implementation between the TerminalControl and the TSFInputControl.
These events are used for obtaining Font information from the
TerminalControl, getting the Cursor position and writing to the terminal
buffer.
## Known Issues
- Width of TextBlock is hardcoded to 200 pixels and most likely should
adjust to the available width of the current input line on the console
(#3640)
- Entering text in the middle of an existing set of text has TextBlock
render under existing text. Current Console behavior here isn't good
experience either (writes over text)
- Text input at edges of window is clipped versus wrapping around to
next line. This isn't any worse than the original command line, but
Terminal should be better (#3657)
## Future Considerations
Ideally, we'd be able to interact with the console buffer directly and
replace characters as the user types.
## Validation
General steps to try functionality
- Open Console
- Switch to Simplified Chinese (Shortcut: Windows+Spacebar)
- Switch to Chinese mode on language bar
Scenarios validated:
- As user types unformatted candidates appear on command line and IME
renders in correct position under unformatted characters.
- User can dismiss IME and text doesn't appear on command line
- Switch back to English mode, functions like normal
- New tab has proper behavior
- Switching between tabs has proper behavior
- Switching away from Terminal Window with IME present causes IME to
disappear
[1]: https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/CustomEditControl
[2]: https://docs.microsoft.com/en-us/windows/uwp/design/input/custom-text-input
Closes #459
Closes #2213
Closes #3641
2019-11-22 01:25:50 +01:00
2019-12-21 02:35:31 +01:00
void _Search ( const winrt : : hstring & text , const bool goForward , const bool caseSensitive ) ;
Search - add search box control and implement search experience (#3590)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
This is the PR for feature Search: #605
This PR includes the newly introduced SearchBoxControl in TermControl dir, which is the search bar for the search experience. And the codes that enable Search in Windows Terminal.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
The PR that migrates the Conhost search module: https://github.com/microsoft/terminal/pull/3279
Spec (still actively updating): https://github.com/microsoft/terminal/pull/3299
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #605
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
These functionalities are included in the search experience.
1. Search in Terminal text buffer.
2. Automatic wrap-around.
3. Search up or down switch by clicking different buttons.
4. Search case sensitively/insensitively by clicking a button. S. Move the search box to the top/bottom by clicking a button.
6. Close by clicking 'X'.
7. Open search by ctrl + F.
When the searchbox is open, the user could still interact with the terminal by clicking the terminal input area.
While I already have the search functionalities, currently there are still some known to-do works and I will keep updating my PR:
1. Optimize the search box UI, this includes:
1) Theme adaptation. The search box background and font color
should change according to the theme,
2) Add background. Currently the elements in search box are all
transparent. However, we need a background.
3) Move button should be highlighted once clicked.
2. Accessibility: search process should be able to performed without mouse. Once the search box is focused, the user should be able to navigate between all interactive elements on the searchbox using keyboard.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
To test:
1. checkout this branch.
2. Build the project.
3. Start Windows Terminal and press Ctrl+F
4. The search box should appear on the top right corner.
2019-12-17 16:52:37 +01:00
void _CloseSearchBoxControl ( const winrt : : Windows : : Foundation : : IInspectable & sender , Windows : : UI : : Xaml : : RoutedEventArgs const & args ) ;
Add a Windows.UI.Text.Core IME overlay to TerminalControl (#1919)
TerminalControl doesn't use any of the built in text input and edit
controls provided by XAML for text input, which means TermianlControl
needs to communicate with the Text Services Framework (TSF) in order to
provide Input Method Editor (IME) support. Just like the rest of
Terminal we get to take advantage of newer APIs (Windows.UI.Text.Core)
namespace to provide support vs. the old TSF 1.0.
Windows.UI.Text.Core handles communication between a text edit control
and the text services primarily through a CoreTextEditContext object.
This change introduces a new UserControl TSFInputControl which is a
custom EditControl similar to the CustomEditControl sample[1].
TSFInputControl is similar (overlay with IME text) to how old console
(conimeinfo) handled IME.
# Details
TSFInputControl is a Windows.UI.Xaml.Controls.UserControl
TSFInputControl contains a Canvas control for absolution positioning a
TextBlock control within its containing control (TerminalControl).
The TextBlock control is used for displaying candidate text from the
IME. When the user makes a choice in the IME the TextBlock is cleared
and the text is written to the Terminal buffer like normal text.
TSFInputControl creates an instance of the CoreTextEditContext and
attaches appropriate event handlers to CoreTextEditContext in order to
interact with the IME.
A good write-up on how to interact with CoreTextEditContext can be found
here[2].
## Text Updates
Text updates from the IME come in on the TextUpdating event handler,
text updates are stored in an internal buffer (_inputBuffer).
## Completed Text
Once a user selects a text in the IME, the CompositionCompleted handler
is invoked. The input buffer (_inputBuffer) is written to the Terminal
buffer, _inputBuffer is cleared and Canvas and TextBlock controls are
hidden until the user starts a composition session again.
## Positioning
Telling the IME where to properly position itself was the hardest part
of this change. The IME expects to know it's location in screen
coordinates as supposed to client coordinates. This is pretty easy if
you are a pure UWP, but since we are hosted inside a XAMLIsland the
client to screen coordinate translation is a little harder.
### Calculating Screen Coordinates
1. Obtaining the Window position in Screen coordinates.
2. Determining the Client coordinate of the cursor.
3. Converting the Client coordinate of the cursor to Screen coordinates.
4. Offsetting the X and Y coordinate of the cursor by the position of
the TerminalControl within the window (tabs if present, margins, etc..).
5. Applying any scale factor of the display.
Once we have the right position in screen coordinates, this is supplied
in the LayoutBounds of the CoreTextLayoutRequestedEventArgs which lets
the IME know where to position itself on the Screen.
## Font Information/Cursor/Writing to Terminal
3 events were added to the TSFInputControl to create a loosely-coupled
implementation between the TerminalControl and the TSFInputControl.
These events are used for obtaining Font information from the
TerminalControl, getting the Cursor position and writing to the terminal
buffer.
## Known Issues
- Width of TextBlock is hardcoded to 200 pixels and most likely should
adjust to the available width of the current input line on the console
(#3640)
- Entering text in the middle of an existing set of text has TextBlock
render under existing text. Current Console behavior here isn't good
experience either (writes over text)
- Text input at edges of window is clipped versus wrapping around to
next line. This isn't any worse than the original command line, but
Terminal should be better (#3657)
## Future Considerations
Ideally, we'd be able to interact with the console buffer directly and
replace characters as the user types.
## Validation
General steps to try functionality
- Open Console
- Switch to Simplified Chinese (Shortcut: Windows+Spacebar)
- Switch to Chinese mode on language bar
Scenarios validated:
- As user types unformatted candidates appear on command line and IME
renders in correct position under unformatted characters.
- User can dismiss IME and text doesn't appear on command line
- Switch back to English mode, functions like normal
- New tab has proper behavior
- Switching between tabs has proper behavior
- Switching away from Terminal Window with IME present causes IME to
disappear
[1]: https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/CustomEditControl
[2]: https://docs.microsoft.com/en-us/windows/uwp/design/input/custom-text-input
Closes #459
Closes #2213
Closes #3641
2019-11-22 01:25:50 +01:00
// TSFInputControl Handlers
void _CompositionCompleted ( winrt : : hstring text ) ;
Search - add search box control and implement search experience (#3590)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
This is the PR for feature Search: #605
This PR includes the newly introduced SearchBoxControl in TermControl dir, which is the search bar for the search experience. And the codes that enable Search in Windows Terminal.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
The PR that migrates the Conhost search module: https://github.com/microsoft/terminal/pull/3279
Spec (still actively updating): https://github.com/microsoft/terminal/pull/3299
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #605
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
These functionalities are included in the search experience.
1. Search in Terminal text buffer.
2. Automatic wrap-around.
3. Search up or down switch by clicking different buttons.
4. Search case sensitively/insensitively by clicking a button. S. Move the search box to the top/bottom by clicking a button.
6. Close by clicking 'X'.
7. Open search by ctrl + F.
When the searchbox is open, the user could still interact with the terminal by clicking the terminal input area.
While I already have the search functionalities, currently there are still some known to-do works and I will keep updating my PR:
1. Optimize the search box UI, this includes:
1) Theme adaptation. The search box background and font color
should change according to the theme,
2) Add background. Currently the elements in search box are all
transparent. However, we need a background.
3) Move button should be highlighted once clicked.
2. Accessibility: search process should be able to performed without mouse. Once the search box is focused, the user should be able to navigate between all interactive elements on the searchbox using keyboard.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
To test:
1. checkout this branch.
2. Build the project.
3. Start Windows Terminal and press Ctrl+F
4. The search box should appear on the top right corner.
2019-12-17 16:52:37 +01:00
void _CurrentCursorPositionHandler ( const IInspectable & sender , const CursorPositionEventArgs & eventArgs ) ;
void _FontInfoHandler ( const IInspectable & sender , const FontInfoEventArgs & eventArgs ) ;
2020-04-09 02:20:51 +02:00
Don't wait for a connection to finish when a control is closed (#5303)
## Summary of the Pull Request
When a pane is closed by a connection, we want to wait until the connection is actually `Closed` before we fire the actual `Closed` event. If the connection didn't close gracefully, there are scenarios where we want to print a message to the screen.
However, when a pane is closed by the UI, we don't really care to wait for the connection to be completely closed. We can just do it whenever. So I've moved that call to be on a background thread.
## PR Checklist
* [x] Closes #1996
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
Previously we'd wait for the connection to close synchronously when closing tabs or panes. For misbehaving applications like `ssh.exe`, that could result in the `Close` needing to `WaitForSingleObject` _on the UI thread_. If the user closed the tab / pane either with a keybinding or with some other UI element, they don't really care to see the error message anymore. They just want the pane closed. So there's no need to wait for the actual connection to close - the app can just continue on with whatever it was doing.
## Validation Steps Performed
Messed around with closing tabs, panes, tabs with many panes, the entire window. Did this with keybindings, or by clicking on the 'x' on the tab, the 'x' on the window, or using middle-click.
I'm always scared of things like this, so there's a 50% chance this makes things horribly worse.
2020-04-10 01:27:56 +02:00
winrt : : fire_and_forget _AsyncCloseConnection ( ) ;
2019-05-03 00:29:04 +02:00
} ;
}
namespace winrt : : Microsoft : : Terminal : : TerminalControl : : factory_implementation
{
struct TermControl : TermControlT < TermControl , implementation : : TermControl >
{
} ;
}
