2019-05-03 00:29:04 +02:00
|
|
|
// Copyright (c) Microsoft Corporation.
|
|
|
|
// Licensed under the MIT license.
|
|
|
|
|
|
|
|
#include "precomp.h"
|
|
|
|
#include <cpl_core.h>
|
|
|
|
|
|
|
|
#include "menu.hpp"
|
|
|
|
#include "icon.hpp"
|
|
|
|
#include "window.hpp"
|
|
|
|
|
2020-11-25 22:02:10 +01:00
|
|
|
#include "../../host/dbcs.h"
|
|
|
|
#include "../../host/getset.h"
|
|
|
|
#include "../../host/handle.h"
|
|
|
|
#include "../../host/misc.h"
|
|
|
|
#include "../../host/server.h"
|
|
|
|
#include "../../host/scrolling.hpp"
|
|
|
|
#include "../../host/telemetry.hpp"
|
|
|
|
|
|
|
|
#include "../inc/ServiceLocator.hpp"
|
2019-05-03 00:29:04 +02:00
|
|
|
|
|
|
|
using namespace Microsoft::Console::Interactivity::Win32;
|
|
|
|
|
|
|
|
CONST WCHAR gwszPropertiesDll[] = L"\\console.dll";
|
|
|
|
CONST WCHAR gwszRelativePropertiesDll[] = L".\\console.dll";
|
|
|
|
|
|
|
|
#pragma hdrstop
|
|
|
|
|
|
|
|
// Initialize static Menu variables.
|
|
|
|
Menu* Menu::s_Instance = nullptr;
|
|
|
|
|
|
|
|
#pragma region Public Methods
|
|
|
|
|
|
|
|
Menu::Menu(HMENU hMenu, HMENU hHeirMenu) :
|
|
|
|
_hMenu(hMenu),
|
|
|
|
_hHeirMenu(hHeirMenu)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
// Routine Description:
|
|
|
|
// - This routine allocates and initializes the system menu for the console
|
|
|
|
// Arguments:
|
|
|
|
// - hWnd - The handle to the console's window
|
|
|
|
// Return Value:
|
|
|
|
// - STATUS_SUCCESS or suitable NT error code
|
2019-06-11 22:27:09 +02:00
|
|
|
[[nodiscard]] NTSTATUS Menu::CreateInstance(HWND hWnd)
|
2019-05-03 00:29:04 +02:00
|
|
|
{
|
|
|
|
NTSTATUS status = STATUS_SUCCESS;
|
|
|
|
|
|
|
|
WCHAR ItemString[32];
|
|
|
|
|
|
|
|
// This gets the title bar menu.
|
2020-03-20 21:35:12 +01:00
|
|
|
HMENU hMenu = GetSystemMenu(hWnd, FALSE);
|
|
|
|
HMENU hHeirMenu = LoadMenuW(ServiceLocator::LocateGlobals().hInstance,
|
|
|
|
MAKEINTRESOURCE(ID_CONSOLE_SYSTEMMENU));
|
2019-05-03 00:29:04 +02:00
|
|
|
|
2019-06-11 22:27:09 +02:00
|
|
|
Menu* pNewMenu = new (std::nothrow) Menu(hMenu, hHeirMenu);
|
2019-05-03 00:29:04 +02:00
|
|
|
status = NT_TESTNULL(pNewMenu);
|
|
|
|
|
|
|
|
if (NT_SUCCESS(status))
|
|
|
|
{
|
2020-03-20 21:35:12 +01:00
|
|
|
int ItemLength;
|
2019-05-03 00:29:04 +02:00
|
|
|
// Load the submenu to the system menu.
|
|
|
|
if (hHeirMenu)
|
|
|
|
{
|
|
|
|
ItemLength = LoadStringW(ServiceLocator::LocateGlobals().hInstance,
|
|
|
|
ID_CONSOLE_EDIT,
|
|
|
|
ItemString,
|
|
|
|
ARRAYSIZE(ItemString));
|
|
|
|
if (ItemLength)
|
|
|
|
{
|
|
|
|
// Append the clipboard menu to system menu.
|
|
|
|
AppendMenuW(hMenu,
|
|
|
|
MF_POPUP | MF_STRING,
|
|
|
|
(UINT_PTR)hHeirMenu,
|
|
|
|
ItemString);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Edit the accelerators off of the standard items.
|
|
|
|
// - Edits the indicated control to one word.
|
|
|
|
// - Trim the Accelerator key text off of the end of the standard menu
|
|
|
|
// items because we don't support the accelerators.
|
|
|
|
ItemLength = LoadStringW(ServiceLocator::LocateGlobals().hInstance,
|
|
|
|
SC_CLOSE,
|
|
|
|
ItemString,
|
|
|
|
ARRAYSIZE(ItemString));
|
|
|
|
if (ItemLength != 0)
|
|
|
|
{
|
|
|
|
MENUITEMINFO mii = { 0 };
|
|
|
|
mii.cbSize = sizeof(mii);
|
|
|
|
mii.fMask = MIIM_STRING | MIIM_BITMAP;
|
|
|
|
mii.dwTypeData = ItemString;
|
|
|
|
mii.hbmpItem = HBMMENU_POPUP_CLOSE;
|
|
|
|
|
|
|
|
SetMenuItemInfoW(hMenu, SC_CLOSE, FALSE, &mii);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Add other items to the system menu.
|
|
|
|
ItemLength = LoadStringW(ServiceLocator::LocateGlobals().hInstance,
|
|
|
|
ID_CONSOLE_DEFAULTS,
|
|
|
|
ItemString,
|
|
|
|
ARRAYSIZE(ItemString));
|
|
|
|
if (ItemLength)
|
|
|
|
{
|
|
|
|
AppendMenuW(hMenu,
|
|
|
|
MF_STRING,
|
|
|
|
ID_CONSOLE_DEFAULTS,
|
|
|
|
ItemString);
|
|
|
|
}
|
|
|
|
|
|
|
|
ItemLength = LoadStringW(ServiceLocator::LocateGlobals().hInstance,
|
|
|
|
ID_CONSOLE_CONTROL,
|
|
|
|
ItemString,
|
|
|
|
ARRAYSIZE(ItemString));
|
|
|
|
if (ItemLength)
|
|
|
|
{
|
|
|
|
AppendMenuW(hMenu,
|
|
|
|
MF_STRING,
|
|
|
|
ID_CONSOLE_CONTROL,
|
|
|
|
ItemString);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Set the singleton instance.
|
|
|
|
Menu::s_Instance = pNewMenu;
|
|
|
|
}
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
Menu* Menu::Instance()
|
|
|
|
{
|
|
|
|
return Menu::s_Instance;
|
|
|
|
}
|
|
|
|
|
|
|
|
Menu::~Menu()
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
// Routine Description:
|
|
|
|
// - this initializes the system menu when a WM_INITMENU message is read.
|
|
|
|
void Menu::Initialize()
|
|
|
|
{
|
|
|
|
const CONSOLE_INFORMATION& gci = ServiceLocator::LocateGlobals().getConsoleInformation();
|
|
|
|
HMENU const hMenu = _hMenu;
|
|
|
|
HMENU const hHeirMenu = _hHeirMenu;
|
|
|
|
|
|
|
|
// If the console is iconic, disable Mark and Scroll.
|
|
|
|
if (gci.Flags & CONSOLE_IS_ICONIC)
|
|
|
|
{
|
|
|
|
EnableMenuItem(hHeirMenu, ID_CONSOLE_MARK, MF_GRAYED);
|
|
|
|
EnableMenuItem(hHeirMenu, ID_CONSOLE_SCROLL, MF_GRAYED);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
// if the console is not iconic
|
|
|
|
// if there are no scroll bars
|
|
|
|
// or we're in mark mode
|
|
|
|
// disable scroll
|
|
|
|
// else
|
|
|
|
// enable scroll
|
|
|
|
//
|
|
|
|
// if we're in scroll mode
|
|
|
|
// disable mark
|
|
|
|
// else
|
|
|
|
// enable mark
|
|
|
|
|
|
|
|
if (gci.GetActiveOutputBuffer().IsMaximizedBoth() || gci.Flags & CONSOLE_SELECTING)
|
|
|
|
{
|
|
|
|
EnableMenuItem(hHeirMenu, ID_CONSOLE_SCROLL, MF_GRAYED);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
EnableMenuItem(hHeirMenu, ID_CONSOLE_SCROLL, MF_ENABLED);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Scrolling::s_IsInScrollMode())
|
|
|
|
{
|
|
|
|
EnableMenuItem(hHeirMenu, ID_CONSOLE_SCROLL, MF_GRAYED);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
EnableMenuItem(hHeirMenu, ID_CONSOLE_SCROLL, MF_ENABLED);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we're selecting or scrolling, disable paste. Otherwise, enable it.
|
|
|
|
if (gci.Flags & (CONSOLE_SELECTING | CONSOLE_SCROLLING))
|
|
|
|
{
|
|
|
|
EnableMenuItem(hHeirMenu, ID_CONSOLE_PASTE, MF_GRAYED);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
EnableMenuItem(hHeirMenu, ID_CONSOLE_PASTE, MF_ENABLED);
|
|
|
|
}
|
|
|
|
|
|
|
|
// If app has active selection, enable copy. Otherwise, disable it.
|
|
|
|
if (gci.Flags & CONSOLE_SELECTING && Selection::Instance().IsAreaSelected())
|
|
|
|
{
|
|
|
|
EnableMenuItem(hHeirMenu, ID_CONSOLE_COPY, MF_ENABLED);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
EnableMenuItem(hHeirMenu, ID_CONSOLE_COPY, MF_GRAYED);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Enable move if not iconic.
|
|
|
|
if (gci.Flags & CONSOLE_IS_ICONIC)
|
|
|
|
{
|
|
|
|
EnableMenuItem(hMenu, SC_MOVE, MF_GRAYED);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
EnableMenuItem(hMenu, SC_MOVE, MF_ENABLED);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Enable settings.
|
|
|
|
EnableMenuItem(hMenu, ID_CONSOLE_CONTROL, MF_ENABLED);
|
|
|
|
}
|
|
|
|
|
|
|
|
#pragma endregion
|
|
|
|
|
|
|
|
#pragma region Public Static Methods
|
|
|
|
|
|
|
|
// Displays the properties dialog and updates the window state as necessary.
|
|
|
|
void Menu::s_ShowPropertiesDialog(HWND const hwnd, BOOL const Defaults)
|
|
|
|
{
|
|
|
|
CONSOLE_STATE_INFO StateInfo = { 0 };
|
|
|
|
if (!Defaults)
|
|
|
|
{
|
|
|
|
THROW_IF_FAILED(Menu::s_GetConsoleState(&StateInfo));
|
|
|
|
StateInfo.UpdateValues = FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
// The Property sheet is going to copy the data from the values passed in
|
|
|
|
// to it, and potentially overwrite StateInfo.*Title.
|
|
|
|
// However, we just allocated wchar_t[]'s for these values.
|
|
|
|
// Stash the pointers to the arrays we just allocated, so we can free those
|
|
|
|
// arrays correctly.
|
|
|
|
const wchar_t* const allocatedOriginalTitle = StateInfo.OriginalTitle;
|
|
|
|
const wchar_t* const allocatedLinkTitle = StateInfo.LinkTitle;
|
|
|
|
|
|
|
|
StateInfo.hWnd = hwnd;
|
|
|
|
StateInfo.Defaults = Defaults;
|
|
|
|
StateInfo.fIsV2Console = TRUE;
|
|
|
|
|
|
|
|
UnlockConsole();
|
|
|
|
|
|
|
|
// First try to find the console.dll next to the launched exe, else default to /windows/system32/console.dll
|
2020-03-20 21:35:12 +01:00
|
|
|
HANDLE hLibrary = LoadLibraryExW(gwszRelativePropertiesDll, nullptr, 0);
|
2019-05-03 00:29:04 +02:00
|
|
|
bool fLoadedDll = hLibrary != nullptr;
|
|
|
|
if (!fLoadedDll)
|
|
|
|
{
|
|
|
|
WCHAR wszFilePath[MAX_PATH + 1] = { 0 };
|
|
|
|
UINT const len = GetSystemDirectoryW(wszFilePath, ARRAYSIZE(wszFilePath));
|
|
|
|
if (len < ARRAYSIZE(wszFilePath))
|
|
|
|
{
|
|
|
|
if (SUCCEEDED(StringCchCatW(wszFilePath, ARRAYSIZE(wszFilePath) - len, gwszPropertiesDll)))
|
|
|
|
{
|
|
|
|
wszFilePath[ARRAYSIZE(wszFilePath) - 1] = UNICODE_NULL;
|
|
|
|
|
2020-03-20 21:35:12 +01:00
|
|
|
hLibrary = LoadLibraryExW(wszFilePath, nullptr, LOAD_WITH_ALTERED_SEARCH_PATH);
|
2019-05-03 00:29:04 +02:00
|
|
|
fLoadedDll = hLibrary != nullptr;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (fLoadedDll)
|
|
|
|
{
|
|
|
|
APPLET_PROC const pfnCplApplet = (APPLET_PROC)GetProcAddress((HMODULE)hLibrary, "CPlApplet");
|
|
|
|
if (pfnCplApplet != nullptr)
|
|
|
|
{
|
2019-06-11 22:27:09 +02:00
|
|
|
(*pfnCplApplet)(hwnd, CPL_INIT, 0, 0);
|
|
|
|
(*pfnCplApplet)(hwnd, CPL_DBLCLK, (LPARAM)&StateInfo, 0);
|
|
|
|
(*pfnCplApplet)(hwnd, CPL_EXIT, 0, 0);
|
2019-05-03 00:29:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
LOG_IF_WIN32_BOOL_FALSE(FreeLibrary((HMODULE)hLibrary));
|
|
|
|
}
|
|
|
|
|
|
|
|
LockConsole();
|
|
|
|
|
|
|
|
if (!Defaults && StateInfo.UpdateValues)
|
|
|
|
{
|
|
|
|
Menu::s_PropertiesUpdate(&StateInfo);
|
|
|
|
}
|
|
|
|
|
|
|
|
// s_GetConsoleState may have created new wchar_t[]s for the title and link title.
|
|
|
|
// delete them before they're leaked.
|
|
|
|
if (allocatedOriginalTitle != nullptr)
|
|
|
|
{
|
|
|
|
delete[] allocatedOriginalTitle;
|
|
|
|
}
|
|
|
|
if (allocatedLinkTitle != nullptr)
|
|
|
|
{
|
|
|
|
delete[] allocatedLinkTitle;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-06-11 22:27:09 +02:00
|
|
|
[[nodiscard]] HRESULT Menu::s_GetConsoleState(CONSOLE_STATE_INFO* const pStateInfo)
|
2019-05-03 00:29:04 +02:00
|
|
|
{
|
|
|
|
const CONSOLE_INFORMATION& gci = ServiceLocator::LocateGlobals().getConsoleInformation();
|
|
|
|
const SCREEN_INFORMATION& ScreenInfo = gci.GetActiveOutputBuffer();
|
|
|
|
pStateInfo->ScreenBufferSize = ScreenInfo.GetBufferSize().Dimensions();
|
|
|
|
pStateInfo->WindowSize = ScreenInfo.GetViewport().Dimensions();
|
|
|
|
|
|
|
|
const RECT rcWindow = ServiceLocator::LocateConsoleWindow<Window>()->GetWindowRect();
|
|
|
|
pStateInfo->WindowPosX = rcWindow.left;
|
|
|
|
pStateInfo->WindowPosY = rcWindow.top;
|
|
|
|
|
|
|
|
const FontInfo& currentFont = ScreenInfo.GetCurrentFont();
|
|
|
|
pStateInfo->FontFamily = currentFont.GetFamily();
|
|
|
|
pStateInfo->FontSize = currentFont.GetUnscaledSize();
|
|
|
|
pStateInfo->FontWeight = currentFont.GetWeight();
|
Allow FontInfo{,Base,Desired} to store a font name > 32 wch (#3107)
We now truncate the font name as it goes out to GDI APIs, in console API
servicing, and in the propsheet.
I attempted to defer truncating the font to as far up the stack as
possible, so as to make FontInfo usable for the broadest set of cases.
There were a couple questions that came up: I know that `Settings` gets
memset (memsat?) by the registry deserializer, and perhaps that's
another place for us to tackle. Right now, this pull request enables
fonts whose names are >= 32 characters _in Windows Terminal only_, but
the underpinnings are there for conhost as well. We'd need to explicitly
break at the API, or perhaps return a failure or log something to
telemetry.
* Should we log truncation at the API boundary to telemetry?
-> Later; followup filed (#3123)
* Should we fix Settings here, or later?
-> Later; followup filed (#3123)
* `TrueTypeFontList` is built out of things in winconp, the private
console header. Concern about interop structures.
-> Not used for interop, followup filed to clean it up (#3123)
* Is `unsigned int` right for codepage? For width?
-> Yes: codepage became UINT (from WORD) when we moved from Win16 to
Win32
This commit also includes a workaround for #3170. Growing
CONSOLE_INFORMATION made us lose the struct layout lottery during
release builds, and this was an expedient fix.
Closes #602.
Related to #3123.
2019-10-15 06:23:45 +02:00
|
|
|
LOG_IF_FAILED(StringCchCopyW(pStateInfo->FaceName, ARRAYSIZE(pStateInfo->FaceName), currentFont.GetFaceName().data()));
|
2019-05-03 00:29:04 +02:00
|
|
|
|
|
|
|
const Cursor& cursor = ScreenInfo.GetTextBuffer().GetCursor();
|
|
|
|
pStateInfo->CursorSize = cursor.GetSize();
|
Consolidate the color palette APIs (#11784)
This PR merges the default colors and cursor color into the main color
table, enabling us to simplify the `ConGetSet` and `ITerminalApi`
interfaces, with just two methods required for getting and setting any
form of color palette entry.
The is a follow-up to the color table standardization in #11602, and a
another small step towards de-duplicating `AdaptDispatch` and
`TerminalDispatch` for issue #3849. It should also make it easier to
support color queries (#3718) and a configurable bold color (#5682) in
the future.
On the conhost side, default colors could originally be either indexed
positions in the 16-color table, or separate standalone RGB values. With
the new system, the default colors will always be in the color table, so
we just need to track their index positions.
To make this work, those positions need to be calculated at startup
based on the loaded registry/shortcut settings, and updated when
settings are changed (this is handled in
`CalculateDefaultColorIndices`). But the plus side is that it's now much
easier to lookup the default color values for rendering.
For now the default colors in Windows Terminal use hardcoded positions,
because it doesn't need indexed default colors like conhost. But in the
future I'd like to extend the index handling to both terminals, so we
can eventually support the VT525 indexed color operations.
As for the cursor color, that was previously stored in the `Cursor`
class, which meant that it needed to be copied around in various places
where cursors were being instantiated. Now that it's managed separately
in the color table, a lot of that code is no longer required.
## Validation
Some of the unit test initialization code needed to be updated to setup
the color table and default index values as required for the new system.
There were also some adjustments needed to account for API changes, in
particular for methods that now take index values for the default colors
in place of COLORREFs. But for the most part, the essential behavior of
the tests remains unchanged.
I've also run a variety of manual tests looking at the legacy console
APIs as well as the various VT color sequences, and checking that
everything works as expected when color schemes are changed, both in
Windows Terminal and conhost, and in the latter case with both indexed
colors and RGB values.
Closes #11768
2021-11-23 19:28:55 +01:00
|
|
|
pStateInfo->CursorColor = gci.GetColorTableEntry(TextColor::CURSOR_COLOR);
|
2019-05-03 00:29:04 +02:00
|
|
|
pStateInfo->CursorType = static_cast<unsigned int>(cursor.GetType());
|
|
|
|
|
|
|
|
// Retrieve small icon for use in displaying the dialog
|
|
|
|
LOG_IF_FAILED(Icon::Instance().GetIcons(nullptr, &pStateInfo->hIcon));
|
|
|
|
|
|
|
|
pStateInfo->QuickEdit = !!(gci.Flags & CONSOLE_QUICK_EDIT_MODE);
|
|
|
|
pStateInfo->AutoPosition = !!(gci.Flags & CONSOLE_AUTO_POSITION);
|
|
|
|
pStateInfo->InsertMode = gci.GetInsertMode();
|
|
|
|
pStateInfo->ScreenAttributes = gci.GetFillAttribute();
|
|
|
|
pStateInfo->PopupAttributes = gci.GetPopupFillAttribute();
|
|
|
|
|
|
|
|
// Ensure that attributes are only describing colors to the properties dialog
|
|
|
|
WI_ClearAllFlags(pStateInfo->ScreenAttributes, ~(FG_ATTRS | BG_ATTRS));
|
|
|
|
WI_ClearAllFlags(pStateInfo->PopupAttributes, ~(FG_ATTRS | BG_ATTRS));
|
|
|
|
|
|
|
|
pStateInfo->HistoryBufferSize = gci.GetHistoryBufferSize();
|
|
|
|
pStateInfo->NumberOfHistoryBuffers = gci.GetNumberOfHistoryBuffers();
|
|
|
|
pStateInfo->HistoryNoDup = !!(gci.Flags & CONSOLE_HISTORY_NODUP);
|
|
|
|
|
Fix SGR indexed colors to distinguish Indexed256 color (and more) (#5834)
This PR introduces a new `ColorType` to allow us to distinguish between
`SGR` indexed colors from the 16 color table, the lower half of which
can be brightened, and the ISO/ITU indexed colors from the 256 color
table, which have a fixed brightness. Retaining the distinction between
these two types will enable us to forward the correct `SGR` sequences to
conpty when addressing issue #2661.
The other benefit of retaining the color index (which we didn't
previously do for ISO/ITU colors) is that it ensures that the colors are
updated correctly when the color scheme is changed.
## References
* This is another step towards fixing the conpty narrowing bugs in issue
#2661.
* This is technically a fix for issue #5384, but that won't be apparent
until #2661 is complete.
## PR Checklist
* [x] Closes #1223
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already.
## Detailed Description of the Pull Request / Additional comments
The first part of this PR was the introduction of a new `ColorType` in
the `TextColor` class. Instead of just the one `IsIndex` type, there is
now an `IsIndex16` and an `IsIndex256`. `IsIndex16` covers the eight
original ANSI colors set with `SGR 3x` and `SGR 4x`, as well as the
brighter aixterm variants set with `SGR 9x` and `SGR 10x`. `IsIndex256`
covers the 256 ISO/ITU indexed colors set with `SGR 38;5` and `SGR
48;5`.
There are two reasons for this distinction. The first is that the ANSI
colors have the potential to be brightened by the `SGR 1` bold
attribute, while the ISO/ITO color do not. The second reason is that
when forwarding an attributes through conpty, we want to try and
preserve the original SGR sequence that generated each color (to the
extent that that is possible). By having the two separate types, we can
map the `IsIndex16` colors back to ANSI/aixterm values, and `IsIndex256`
to the ISO/ITU sequences.
In addition to the VT colors, we also have to deal with the legacy
colors set by the Windows console APIs, but we don't really need a
separate type for those. It seemed most appropriate to me to store them
as `IsIndex256` colors, since it doesn't make sense to have them
brightened by the `SGR 1` attribute (which is what would happen if they
were stored as `IsIndex16`). If a console app wanted a bright color it
would have selected one, so we shouldn't be messing with that choice.
The second part of the PR was the unification of the two color tables.
Originally we had a 16 color table for the legacy colors, and a separate
table for the 256 ISO/ITU colors. These have now been merged into one,
so color table lookups no longer need to decide which of the two tables
they should be referencing. I've also updated all the methods that took
a color table as a parameter to use a `basic_string_view` instead of
separate pointer and length variables, which I think makes them a lot
easier and safer to work with.
With this new architecture in place, I could now update the
`AdaptDispatch` SGR implementation to store the ISO/ITU indexed colors
as `IsIndex256` values, where before they were mapped to RGB values
(which prevented them reflecting any color scheme changes). I could also
update the `TerminalDispatch` implementation to differentiate between
the two index types, so that the `SGR 1` brightening would only be
applied to the ANSI colors.
I've also done a bit of code refactoring to try and minimise any direct
access to the color tables, getting rid of a lot of places that were
copying tables with `memmove` operations. I'm hoping this will make it
easier for us to update the code in the future if we want to reorder the
table entries (which is likely a requirement for unifying the
`AdaptDispatch` and `TerminalDispatch` implementations).
## Validation Steps Performed
For testing, I've just updated the existing unit tests to account for
the API changes. The `TextColorTests` required an extra parameter
specifying the index type when setting an index. And the `AdapterTest`
and `ScreenBufferTests` required the use of the new `SetIndexedXXX`
methods in order to be explicit about the index type, instead of relying
on the `TextAttribute` constructor and the old `SetForeground` and
`SetBackground` methods which didn't have a way to differentiate index
types.
I've manually tested the various console APIs
(`SetConsoleTextAttribute`, `ReadConsoleOutputAttribute`, and
`ReadConsoleOutput`), to make sure they are still setting and reading
the attributes as well as they used to. And I've tested the
`SetConsoleScreenBufferInfoEx` and `GetConsoleScreenBufferInfoEx` APIs
to make sure they can read and write the color table correctly. I've
also tested the color table in the properties dialog, made sure it was
saved and restored from the registry correctly, and similarly saved and
restored from a shortcut link.
Note that there are still a bunch of issues with the color table APIs,
but no new problems have been introduced by the changes in this PR, as
far as I could tell.
I've also done a bunch of manual tests of `OSC 4` to make sure it's
updating all the colors correctly (at least in conhost), and confirmed
that the test case in issue #1223 now works as expected.
2020-05-28 00:34:45 +02:00
|
|
|
for (size_t i = 0; i < std::size(pStateInfo->ColorTable); i++)
|
|
|
|
{
|
Standardize the color table order (#11602)
## Summary of the Pull Request
In the original implementation, we used two different orderings for the color tables. The WT color table used ANSI order, while the conhost color table used a Windows-specific order. This PR standardizes on the ANSI color order everywhere, so the usage of indexed colors is consistent across both parts of the code base, which will hopefully allow more of the code to be shared one day.
## References
This is another small step towards de-duplicating `AdaptDispatch` and `TerminalDispatch` for issue #3849, and is essentially a followup to the SGR dispatch refactoring in PR #6728.
## PR Checklist
* [x] Closes #11461
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number where discussion took place: #11461
## Detailed Description of the Pull Request / Additional comments
Conhost still needs to deal with legacy attributes using Windows color order, so those values now need to be transposed to ANSI colors order when creating a `TextAttribute` object. This is done with a simple mapping table, which also handles the translation of the default color entries, so it's actually slightly faster than the original code.
And when converting `TextAttribute` values back to legacy console attributes, we were already using a mapping table to handle the narrowing of 256-color values down to 16 colors, so we just needed to adjust that table to account for the translation from ANSI to Windows, and then could make use of the same table for both 256-color and 16-color values.
There are also a few places in conhost that read from or write to the color tables, and those now need to transpose the index values. I've addressed this by creating separate `SetLegacyColorTableEntry` and `GetLegacyColorTableEntry` methods in the `Settings` class which take care of the mapping, so it's now clearer in which cases the code is dealing with legacy values, and which are ANSI values.
These methods are used in the `SetConsoleScreenBufferInfoEx` and `GetConsoleScreenBufferInfoEx` APIs, as well as a few place where color preferences are handled (the registry, shortcut links, and the properties dialog), none of which are particularly sensitive to performance. However, we also use the legacy table when looking up the default colors for rendering (which happens a lot), so I've refactored that code so the default color calculations now only occur once per frame.
The plus side of all of this is that the VT code doesn't need to do the index translation anymore, so we can finally get rid of all the calls to `XTermToWindowsIndex`, and we no longer need a separate color table initialization method for conhost, so I was able to merge a number of color initialization methods into one. We also no longer need to translate from legacy values to ANSI when generating VT sequences for conpty.
The one exception to that is the 16-color VT renderer, which uses the `TextColor::GetLegacyIndex` method to approximate 16-color equivalents for RGB and 256-color values. Since that method returns a legacy index, it still needs to be translated to ANSI before it can be used in a VT sequence. But this should be no worse than it was before.
One more special case is conhost's secret _Color Selection_ feature. That uses `Ctrl`+Number and `Alt`+Number key sequences to highlight parts of the buffer, and the mapping from number to color is based on the Windows color order. So that mapping now needs to be transposed, but that's also not performance sensitive.
The only thing that I haven't bothered to update is the trace logging code in the `Telemetry` class, which logs the first 16 entries in the color table. Those entries are now going to be in a different order, but I didn't think that would be of great concern to anyone.
## Validation Steps Performed
A lot of unit tests needed to be updated to use ANSI color constants when setting indexed colors, where before they might have been expecting values in Windows order. But this replaced a wild mix of different constants, sometimes having to use bit shifting, as well as values mapped with `XTermToWindowsIndex`, so I think the tests are a whole lot clearer now. Only a few cases have been left with literal numbers where that seemed more appropriate.
In addition to getting the unit tests working, I've also manually tested the behaviour of all the console APIs which I thought could be affected by these changes, and confirmed that they produced the same results in the new code as they did in the original implementation.
This includes:
- `WriteConsoleOutput`
- `ReadConsoleOutput`
- `SetConsoleTextAttribute` with `WriteConsoleOutputCharacter`
- `FillConsoleOutputAttribute` and `FillConsoleOutputCharacter`
- `ScrollConsoleScreenBuffer`
- `GetConsoleScreenBufferInfo`
- `GetConsoleScreenBufferInfoEx`
- `SetConsoleScreenBufferInfoEx`
I've also manually tested changing colors via the console properties menu, the registry, and shortcut links, including setting default colors and popup colors. And I've tested that the "Quirks Mode" is still working as expected in PowerShell.
In terms of performance, I wrote a little test app that filled a 80x9999 buffer with random color combinations using `WriteConsoleOutput`, which I figured was likely to be the most performance sensitive call, and I think it now actually performs slightly better than the original implementation.
I've also tested similar code - just filling the visible window - with SGR VT sequences of various types, and the performance seems about the same as it was before.
2021-11-04 23:13:22 +01:00
|
|
|
pStateInfo->ColorTable[i] = gci.GetLegacyColorTableEntry(i);
|
Fix SGR indexed colors to distinguish Indexed256 color (and more) (#5834)
This PR introduces a new `ColorType` to allow us to distinguish between
`SGR` indexed colors from the 16 color table, the lower half of which
can be brightened, and the ISO/ITU indexed colors from the 256 color
table, which have a fixed brightness. Retaining the distinction between
these two types will enable us to forward the correct `SGR` sequences to
conpty when addressing issue #2661.
The other benefit of retaining the color index (which we didn't
previously do for ISO/ITU colors) is that it ensures that the colors are
updated correctly when the color scheme is changed.
## References
* This is another step towards fixing the conpty narrowing bugs in issue
#2661.
* This is technically a fix for issue #5384, but that won't be apparent
until #2661 is complete.
## PR Checklist
* [x] Closes #1223
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already.
## Detailed Description of the Pull Request / Additional comments
The first part of this PR was the introduction of a new `ColorType` in
the `TextColor` class. Instead of just the one `IsIndex` type, there is
now an `IsIndex16` and an `IsIndex256`. `IsIndex16` covers the eight
original ANSI colors set with `SGR 3x` and `SGR 4x`, as well as the
brighter aixterm variants set with `SGR 9x` and `SGR 10x`. `IsIndex256`
covers the 256 ISO/ITU indexed colors set with `SGR 38;5` and `SGR
48;5`.
There are two reasons for this distinction. The first is that the ANSI
colors have the potential to be brightened by the `SGR 1` bold
attribute, while the ISO/ITO color do not. The second reason is that
when forwarding an attributes through conpty, we want to try and
preserve the original SGR sequence that generated each color (to the
extent that that is possible). By having the two separate types, we can
map the `IsIndex16` colors back to ANSI/aixterm values, and `IsIndex256`
to the ISO/ITU sequences.
In addition to the VT colors, we also have to deal with the legacy
colors set by the Windows console APIs, but we don't really need a
separate type for those. It seemed most appropriate to me to store them
as `IsIndex256` colors, since it doesn't make sense to have them
brightened by the `SGR 1` attribute (which is what would happen if they
were stored as `IsIndex16`). If a console app wanted a bright color it
would have selected one, so we shouldn't be messing with that choice.
The second part of the PR was the unification of the two color tables.
Originally we had a 16 color table for the legacy colors, and a separate
table for the 256 ISO/ITU colors. These have now been merged into one,
so color table lookups no longer need to decide which of the two tables
they should be referencing. I've also updated all the methods that took
a color table as a parameter to use a `basic_string_view` instead of
separate pointer and length variables, which I think makes them a lot
easier and safer to work with.
With this new architecture in place, I could now update the
`AdaptDispatch` SGR implementation to store the ISO/ITU indexed colors
as `IsIndex256` values, where before they were mapped to RGB values
(which prevented them reflecting any color scheme changes). I could also
update the `TerminalDispatch` implementation to differentiate between
the two index types, so that the `SGR 1` brightening would only be
applied to the ANSI colors.
I've also done a bit of code refactoring to try and minimise any direct
access to the color tables, getting rid of a lot of places that were
copying tables with `memmove` operations. I'm hoping this will make it
easier for us to update the code in the future if we want to reorder the
table entries (which is likely a requirement for unifying the
`AdaptDispatch` and `TerminalDispatch` implementations).
## Validation Steps Performed
For testing, I've just updated the existing unit tests to account for
the API changes. The `TextColorTests` required an extra parameter
specifying the index type when setting an index. And the `AdapterTest`
and `ScreenBufferTests` required the use of the new `SetIndexedXXX`
methods in order to be explicit about the index type, instead of relying
on the `TextAttribute` constructor and the old `SetForeground` and
`SetBackground` methods which didn't have a way to differentiate index
types.
I've manually tested the various console APIs
(`SetConsoleTextAttribute`, `ReadConsoleOutputAttribute`, and
`ReadConsoleOutput`), to make sure they are still setting and reading
the attributes as well as they used to. And I've tested the
`SetConsoleScreenBufferInfoEx` and `GetConsoleScreenBufferInfoEx` APIs
to make sure they can read and write the color table correctly. I've
also tested the color table in the properties dialog, made sure it was
saved and restored from the registry correctly, and similarly saved and
restored from a shortcut link.
Note that there are still a bunch of issues with the color table APIs,
but no new problems have been introduced by the changes in this PR, as
far as I could tell.
I've also done a bunch of manual tests of `OSC 4` to make sure it's
updating all the colors correctly (at least in conhost), and confirmed
that the test case in issue #1223 now works as expected.
2020-05-28 00:34:45 +02:00
|
|
|
}
|
2019-05-03 00:29:04 +02:00
|
|
|
|
|
|
|
// Create mutable copies of the titles so the propsheet can do something with them.
|
|
|
|
if (gci.GetOriginalTitle().length() > 0)
|
|
|
|
{
|
2019-06-11 22:27:09 +02:00
|
|
|
pStateInfo->OriginalTitle = new (std::nothrow) wchar_t[gci.GetOriginalTitle().length() + 1]{ UNICODE_NULL };
|
2019-05-03 00:29:04 +02:00
|
|
|
RETURN_IF_NULL_ALLOC(pStateInfo->OriginalTitle);
|
|
|
|
gci.GetOriginalTitle().copy(pStateInfo->OriginalTitle, gci.GetOriginalTitle().length());
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
pStateInfo->OriginalTitle = nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (gci.GetLinkTitle().length() > 0)
|
|
|
|
{
|
2019-06-11 22:27:09 +02:00
|
|
|
pStateInfo->LinkTitle = new (std::nothrow) wchar_t[gci.GetLinkTitle().length() + 1]{ UNICODE_NULL };
|
2019-05-03 00:29:04 +02:00
|
|
|
RETURN_IF_NULL_ALLOC(pStateInfo->LinkTitle);
|
|
|
|
gci.GetLinkTitle().copy(pStateInfo->LinkTitle, gci.GetLinkTitle().length());
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
pStateInfo->LinkTitle = nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
pStateInfo->CodePage = gci.OutputCP;
|
|
|
|
|
|
|
|
// begin console v2 properties
|
|
|
|
pStateInfo->fIsV2Console = TRUE;
|
|
|
|
pStateInfo->fWrapText = gci.GetWrapText();
|
|
|
|
pStateInfo->fFilterOnPaste = !!gci.GetFilterOnPaste();
|
|
|
|
pStateInfo->fCtrlKeyShortcutsDisabled = gci.GetCtrlKeyShortcutsDisabled();
|
|
|
|
pStateInfo->fLineSelection = gci.GetLineSelection();
|
|
|
|
pStateInfo->bWindowTransparency = ServiceLocator::LocateConsoleWindow<Window>()->GetWindowOpacity();
|
|
|
|
|
|
|
|
pStateInfo->InterceptCopyPaste = gci.GetInterceptCopyPaste();
|
|
|
|
|
Improve the propagation of color attributes over ConPTY (#6506)
This PR reimplements the VT rendering engines to do a better job of
preserving the original color types when propagating attributes over
ConPTY. For the 16-color renderers it provides better support for
default colors and improves the efficiency of the color narrowing
conversions. It also fixes problems with the ordering of character
renditions that could result in attributes being dropped.
Originally the base renderer would calculate the RGB color values and
legacy/extended attributes up front, passing that data on to the active
engine's `UpdateDrawingBrushes` method. With this new implementation,
the renderer now just passes through the original `TextAttribute` along
with an `IRenderData` interface, and leaves it to the engines to extract
the information they need.
The GDI and DirectX engines now have to lookup the RGB colors themselves
(via simple `IRenderData` calls), but have no need for the other
attributes. The VT engines extract the information that they need from
the `TextAttribute`, instead of having to reverse engineer it from
`COLORREF`s.
The process for the 256-color Xterm engine starts with a check for
default colors. If both foreground and background are default, it
outputs a SGR 0 reset, and clears the `_lastTextAttribute` completely to
make sure any reset state is reapplied. With that out the way, the
foreground and background are updated (if changed) in one of 4 ways.
They can either be a default value (SGR 39 and 49), a 16-color index
(using ANSI or AIX sequences), a 256-color index, or a 24-bit RGB value
(both using SGR 38 and 48 sequences).
Then once the colors are accounted for, there is a separate step that
handles the character rendition attributes (bold, italics, underline,
etc.) This step must come _after_ the color sequences, in case a SGR
reset is required, which would otherwise have cleared any character
rendition attributes if it came last (which is what happened in the
original implementation).
The process for the 16-color engines is a little different. The target
client in this case (Windows telnet) is incapable of setting default
colors individually, so we need to output an SGR 0 reset if _either_
color has changed to default. With that out the way, we use the
`TextColor::GetLegacyIndex` method to obtain an approximate 16-color
index for each color, and apply the bold attribute by brightening the
foreground index (setting bit 8) if the color type permits that.
However, since Windows telnet only supports the 8 basic ANSI colors, the
best we can do for bright colors is to output an SGR 1 attribute to get
a bright foreground. There is nothing we can do about a bright
background, so after that we just have to drop the high bit from the
colors. If the resulting index values have changed from what they were
before, we then output ANSI 8-color SGR sequences to update them.
As with the 256-color engine, there is also a final step to handle the
character rendition attributes. But in this case, the only supported
attributes are underline and reversed video.
Since the VT engines no longer depend on the active color table and
default color values, there was quite a lot of code that could now be
removed. This included the `IDefaultColorProvider` interface and
implementations, the `Find(Nearest)TableIndex` functions, and also the
associated HLS conversion and difference calculations.
VALIDATION
Other than simple API parameter changes, the majority of updates
required in the unit tests were to correct assumptions about the way the
colors should be rendered, which were the source of the narrowing bugs
this PR was trying to fix. Like passing white on black to the
`UpdateDrawingBrushes` API, and expecting it to output the default `SGR
0` sequence, or passing an RGB color and expecting an indexed SGR
sequence.
In addition to that, I've added some VT renderer tests to make sure the
rendition attributes (bold, underline, etc) are correctly retained when
a default color update causes an `SGR 0` sequence to be generated (the
source of bug #3076). And I've extended the VT renderer color tests
(both 256-color and 16-color) to make sure we're covering all of the
different color types (default, RGB, and both forms of indexed colors).
I've also tried to manually verify that all of the test cases in the
linked bug reports (and their associated duplicates) are now fixed when
this PR is applied.
Closes #2661
Closes #3076
Closes #3717
Closes #5384
Closes #5864
This is only a partial fix for #293, but I suspect the remaining cases
are unfixable.
2020-07-01 20:10:36 +02:00
|
|
|
// Get the properties from the settings
|
Consolidate the color palette APIs (#11784)
This PR merges the default colors and cursor color into the main color
table, enabling us to simplify the `ConGetSet` and `ITerminalApi`
interfaces, with just two methods required for getting and setting any
form of color palette entry.
The is a follow-up to the color table standardization in #11602, and a
another small step towards de-duplicating `AdaptDispatch` and
`TerminalDispatch` for issue #3849. It should also make it easier to
support color queries (#3718) and a configurable bold color (#5682) in
the future.
On the conhost side, default colors could originally be either indexed
positions in the 16-color table, or separate standalone RGB values. With
the new system, the default colors will always be in the color table, so
we just need to track their index positions.
To make this work, those positions need to be calculated at startup
based on the loaded registry/shortcut settings, and updated when
settings are changed (this is handled in
`CalculateDefaultColorIndices`). But the plus side is that it's now much
easier to lookup the default color values for rendering.
For now the default colors in Windows Terminal use hardcoded positions,
because it doesn't need indexed default colors like conhost. But in the
future I'd like to extend the index handling to both terminals, so we
can eventually support the VT525 indexed color operations.
As for the cursor color, that was previously stored in the `Cursor`
class, which meant that it needed to be copied around in various places
where cursors were being instantiated. Now that it's managed separately
in the color table, a lot of that code is no longer required.
## Validation
Some of the unit test initialization code needed to be updated to setup
the color table and default index values as required for the new system.
There were also some adjustments needed to account for API changes, in
particular for methods that now take index values for the default colors
in place of COLORREFs. But for the most part, the essential behavior of
the tests remains unchanged.
I've also run a variety of manual tests looking at the legacy console
APIs as well as the various VT color sequences, and checking that
everything works as expected when color schemes are changed, both in
Windows Terminal and conhost, and in the latter case with both indexed
colors and RGB values.
Closes #11768
2021-11-23 19:28:55 +01:00
|
|
|
pStateInfo->DefaultForeground = gci.GetColorTableEntry(TextColor::DEFAULT_FOREGROUND);
|
|
|
|
pStateInfo->DefaultBackground = gci.GetColorTableEntry(TextColor::DEFAULT_BACKGROUND);
|
2019-05-03 00:29:04 +02:00
|
|
|
|
|
|
|
pStateInfo->TerminalScrolling = gci.IsTerminalScrolling();
|
|
|
|
// end console v2 properties
|
|
|
|
return S_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
HMENU Menu::s_GetMenuHandle()
|
|
|
|
{
|
|
|
|
if (Menu::s_Instance)
|
|
|
|
{
|
|
|
|
return Menu::s_Instance->_hMenu;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
HMENU Menu::s_GetHeirMenuHandle()
|
|
|
|
{
|
|
|
|
if (Menu::s_Instance)
|
|
|
|
{
|
|
|
|
return Menu::s_Instance->_hHeirMenu;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#pragma endregion
|
|
|
|
|
|
|
|
#pragma region Private Methods
|
|
|
|
|
|
|
|
// Updates the console state from information sent by the properties dialog box.
|
|
|
|
void Menu::s_PropertiesUpdate(PCONSOLE_STATE_INFO pStateInfo)
|
|
|
|
{
|
|
|
|
CONSOLE_INFORMATION& gci = ServiceLocator::LocateGlobals().getConsoleInformation();
|
|
|
|
SCREEN_INFORMATION& ScreenInfo = gci.GetActiveOutputBuffer();
|
|
|
|
|
|
|
|
if (gci.OutputCP != pStateInfo->CodePage)
|
|
|
|
{
|
|
|
|
gci.OutputCP = pStateInfo->CodePage;
|
|
|
|
|
|
|
|
SetConsoleCPInfo(TRUE);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (gci.CP != pStateInfo->CodePage)
|
|
|
|
{
|
|
|
|
gci.CP = pStateInfo->CodePage;
|
|
|
|
|
|
|
|
SetConsoleCPInfo(FALSE);
|
|
|
|
}
|
|
|
|
|
|
|
|
// begin V2 console properties
|
|
|
|
|
|
|
|
// NOTE: We must set the wrap state before further manipulating the buffer/window.
|
|
|
|
// If we do not, the user will get a different result than the preview (e.g. we'll resize without scroll bars first then turn off wrapping.)
|
|
|
|
gci.SetWrapText(!!pStateInfo->fWrapText);
|
|
|
|
gci.SetFilterOnPaste(!!pStateInfo->fFilterOnPaste);
|
|
|
|
gci.SetCtrlKeyShortcutsDisabled(!!pStateInfo->fCtrlKeyShortcutsDisabled);
|
|
|
|
gci.SetLineSelection(!!pStateInfo->fLineSelection);
|
|
|
|
Selection::Instance().SetLineSelection(!!gci.GetLineSelection());
|
|
|
|
|
|
|
|
ServiceLocator::LocateConsoleWindow<Window>()->SetWindowOpacity(pStateInfo->bWindowTransparency);
|
|
|
|
ServiceLocator::LocateConsoleWindow<Window>()->ApplyWindowOpacity();
|
|
|
|
// end V2 console properties
|
|
|
|
|
|
|
|
// Apply font information (must come before all character calculations for window/buffer size).
|
Allow FontInfo{,Base,Desired} to store a font name > 32 wch (#3107)
We now truncate the font name as it goes out to GDI APIs, in console API
servicing, and in the propsheet.
I attempted to defer truncating the font to as far up the stack as
possible, so as to make FontInfo usable for the broadest set of cases.
There were a couple questions that came up: I know that `Settings` gets
memset (memsat?) by the registry deserializer, and perhaps that's
another place for us to tackle. Right now, this pull request enables
fonts whose names are >= 32 characters _in Windows Terminal only_, but
the underpinnings are there for conhost as well. We'd need to explicitly
break at the API, or perhaps return a failure or log something to
telemetry.
* Should we log truncation at the API boundary to telemetry?
-> Later; followup filed (#3123)
* Should we fix Settings here, or later?
-> Later; followup filed (#3123)
* `TrueTypeFontList` is built out of things in winconp, the private
console header. Concern about interop structures.
-> Not used for interop, followup filed to clean it up (#3123)
* Is `unsigned int` right for codepage? For width?
-> Yes: codepage became UINT (from WORD) when we moved from Win16 to
Win32
This commit also includes a workaround for #3170. Growing
CONSOLE_INFORMATION made us lose the struct layout lottery during
release builds, and this was an expedient fix.
Closes #602.
Related to #3123.
2019-10-15 06:23:45 +02:00
|
|
|
FontInfo fiNewFont(pStateInfo->FaceName, gsl::narrow_cast<unsigned char>(pStateInfo->FontFamily), pStateInfo->FontWeight, pStateInfo->FontSize, pStateInfo->CodePage);
|
2019-05-03 00:29:04 +02:00
|
|
|
|
|
|
|
ScreenInfo.UpdateFont(&fiNewFont);
|
|
|
|
|
|
|
|
const FontInfo& fontApplied = ScreenInfo.GetCurrentFont();
|
|
|
|
|
|
|
|
// Now make sure internal font state reflects the font chosen
|
|
|
|
gci.SetFontFamily(fontApplied.GetFamily());
|
|
|
|
gci.SetFontSize(fontApplied.GetUnscaledSize());
|
|
|
|
gci.SetFontWeight(fontApplied.GetWeight());
|
Allow FontInfo{,Base,Desired} to store a font name > 32 wch (#3107)
We now truncate the font name as it goes out to GDI APIs, in console API
servicing, and in the propsheet.
I attempted to defer truncating the font to as far up the stack as
possible, so as to make FontInfo usable for the broadest set of cases.
There were a couple questions that came up: I know that `Settings` gets
memset (memsat?) by the registry deserializer, and perhaps that's
another place for us to tackle. Right now, this pull request enables
fonts whose names are >= 32 characters _in Windows Terminal only_, but
the underpinnings are there for conhost as well. We'd need to explicitly
break at the API, or perhaps return a failure or log something to
telemetry.
* Should we log truncation at the API boundary to telemetry?
-> Later; followup filed (#3123)
* Should we fix Settings here, or later?
-> Later; followup filed (#3123)
* `TrueTypeFontList` is built out of things in winconp, the private
console header. Concern about interop structures.
-> Not used for interop, followup filed to clean it up (#3123)
* Is `unsigned int` right for codepage? For width?
-> Yes: codepage became UINT (from WORD) when we moved from Win16 to
Win32
This commit also includes a workaround for #3170. Growing
CONSOLE_INFORMATION made us lose the struct layout lottery during
release builds, and this was an expedient fix.
Closes #602.
Related to #3123.
2019-10-15 06:23:45 +02:00
|
|
|
gci.SetFaceName(fontApplied.GetFaceName());
|
2019-05-03 00:29:04 +02:00
|
|
|
|
|
|
|
// Set the cursor properties in the Settings
|
|
|
|
const auto cursorType = static_cast<CursorType>(pStateInfo->CursorType);
|
|
|
|
gci.SetCursorType(cursorType);
|
Consolidate the color palette APIs (#11784)
This PR merges the default colors and cursor color into the main color
table, enabling us to simplify the `ConGetSet` and `ITerminalApi`
interfaces, with just two methods required for getting and setting any
form of color palette entry.
The is a follow-up to the color table standardization in #11602, and a
another small step towards de-duplicating `AdaptDispatch` and
`TerminalDispatch` for issue #3849. It should also make it easier to
support color queries (#3718) and a configurable bold color (#5682) in
the future.
On the conhost side, default colors could originally be either indexed
positions in the 16-color table, or separate standalone RGB values. With
the new system, the default colors will always be in the color table, so
we just need to track their index positions.
To make this work, those positions need to be calculated at startup
based on the loaded registry/shortcut settings, and updated when
settings are changed (this is handled in
`CalculateDefaultColorIndices`). But the plus side is that it's now much
easier to lookup the default color values for rendering.
For now the default colors in Windows Terminal use hardcoded positions,
because it doesn't need indexed default colors like conhost. But in the
future I'd like to extend the index handling to both terminals, so we
can eventually support the VT525 indexed color operations.
As for the cursor color, that was previously stored in the `Cursor`
class, which meant that it needed to be copied around in various places
where cursors were being instantiated. Now that it's managed separately
in the color table, a lot of that code is no longer required.
## Validation
Some of the unit test initialization code needed to be updated to setup
the color table and default index values as required for the new system.
There were also some adjustments needed to account for API changes, in
particular for methods that now take index values for the default colors
in place of COLORREFs. But for the most part, the essential behavior of
the tests remains unchanged.
I've also run a variety of manual tests looking at the legacy console
APIs as well as the various VT color sequences, and checking that
everything works as expected when color schemes are changed, both in
Windows Terminal and conhost, and in the latter case with both indexed
colors and RGB values.
Closes #11768
2021-11-23 19:28:55 +01:00
|
|
|
gci.SetColorTableEntry(TextColor::CURSOR_COLOR, pStateInfo->CursorColor);
|
2019-05-03 00:29:04 +02:00
|
|
|
|
|
|
|
// Then also apply them to the buffer's cursor
|
|
|
|
ScreenInfo.SetCursorInformation(pStateInfo->CursorSize,
|
|
|
|
ScreenInfo.GetTextBuffer().GetCursor().IsVisible());
|
|
|
|
ScreenInfo.SetCursorType(cursorType, true);
|
|
|
|
|
|
|
|
gci.SetTerminalScrolling(pStateInfo->TerminalScrolling);
|
|
|
|
|
|
|
|
{
|
|
|
|
// Requested window in characters
|
|
|
|
COORD coordWindow = pStateInfo->WindowSize;
|
|
|
|
|
|
|
|
// Requested buffer in characters.
|
|
|
|
COORD coordBuffer = pStateInfo->ScreenBufferSize;
|
|
|
|
|
|
|
|
// First limit the window so it cannot be bigger than the monitor.
|
|
|
|
// Maximum number of characters we could fit on the given monitor.
|
|
|
|
COORD const coordLargest = ScreenInfo.GetLargestWindowSizeInCharacters();
|
|
|
|
|
|
|
|
coordWindow.X = std::min(coordLargest.X, coordWindow.X);
|
|
|
|
coordWindow.Y = std::min(coordLargest.Y, coordWindow.Y);
|
|
|
|
|
|
|
|
if (gci.GetWrapText())
|
|
|
|
{
|
|
|
|
// Then if wrap text is on, the buffer width gets fixed to the window width value.
|
|
|
|
coordBuffer.X = coordWindow.X;
|
|
|
|
|
|
|
|
// However, we're not done. The "max window size" is if we had no scroll bar.
|
|
|
|
// We need to adjust slightly more if there's space reserved for a vertical scroll bar
|
|
|
|
// which happens when the buffer Y is taller than the window Y.
|
|
|
|
if (coordBuffer.Y > coordWindow.Y)
|
|
|
|
{
|
|
|
|
// Since we need a scroll bar in the Y direction, clamp the buffer width to make sure that
|
|
|
|
// it is leaving appropriate space for a scroll bar.
|
|
|
|
COORD const coordScrollBars = ScreenInfo.GetScrollBarSizesInCharacters();
|
|
|
|
SHORT const sMaxBufferWidthWithScroll = coordLargest.X - coordScrollBars.X;
|
|
|
|
|
|
|
|
coordBuffer.X = std::min(coordBuffer.X, sMaxBufferWidthWithScroll);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Now adjust the buffer size first to whatever we want it to be if it's different than before.
|
|
|
|
const COORD coordScreenBufferSize = ScreenInfo.GetBufferSize().Dimensions();
|
|
|
|
if (coordBuffer.X != coordScreenBufferSize.X ||
|
|
|
|
coordBuffer.Y != coordScreenBufferSize.Y)
|
|
|
|
{
|
|
|
|
CommandLine* const pCommandLine = &CommandLine::Instance();
|
|
|
|
|
|
|
|
pCommandLine->Hide(FALSE);
|
|
|
|
|
|
|
|
LOG_IF_FAILED(ScreenInfo.ResizeScreenBuffer(coordBuffer, TRUE));
|
|
|
|
|
|
|
|
pCommandLine->Show();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Finally, restrict window size to the maximum possible size for the given buffer now that it's processed.
|
|
|
|
COORD const coordMaxForBuffer = ScreenInfo.GetMaxWindowSizeInCharacters();
|
|
|
|
|
|
|
|
coordWindow.X = std::min(coordWindow.X, coordMaxForBuffer.X);
|
|
|
|
coordWindow.Y = std::min(coordWindow.Y, coordMaxForBuffer.Y);
|
|
|
|
|
|
|
|
// Then finish by updating the window. This will update the window size,
|
|
|
|
// as well as the screen buffer's viewport.
|
|
|
|
ServiceLocator::LocateConsoleWindow<Window>()->UpdateWindowSize(coordWindow);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pStateInfo->QuickEdit)
|
|
|
|
{
|
|
|
|
gci.Flags |= CONSOLE_QUICK_EDIT_MODE;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
gci.Flags &= ~CONSOLE_QUICK_EDIT_MODE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pStateInfo->AutoPosition)
|
|
|
|
{
|
|
|
|
gci.Flags |= CONSOLE_AUTO_POSITION;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
gci.Flags &= ~CONSOLE_AUTO_POSITION;
|
|
|
|
|
|
|
|
POINT pt;
|
|
|
|
pt.x = pStateInfo->WindowPosX;
|
|
|
|
pt.y = pStateInfo->WindowPosY;
|
|
|
|
|
|
|
|
ServiceLocator::LocateConsoleWindow<Window>()->UpdateWindowPosition(pt);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (gci.GetInsertMode() != !!pStateInfo->InsertMode)
|
|
|
|
{
|
|
|
|
ScreenInfo.SetCursorDBMode(false);
|
|
|
|
gci.SetInsertMode(pStateInfo->InsertMode != FALSE);
|
|
|
|
if (gci.HasPendingCookedRead())
|
|
|
|
{
|
|
|
|
gci.CookedReadData().SetInsertMode(gci.GetInsertMode());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Fix SGR indexed colors to distinguish Indexed256 color (and more) (#5834)
This PR introduces a new `ColorType` to allow us to distinguish between
`SGR` indexed colors from the 16 color table, the lower half of which
can be brightened, and the ISO/ITU indexed colors from the 256 color
table, which have a fixed brightness. Retaining the distinction between
these two types will enable us to forward the correct `SGR` sequences to
conpty when addressing issue #2661.
The other benefit of retaining the color index (which we didn't
previously do for ISO/ITU colors) is that it ensures that the colors are
updated correctly when the color scheme is changed.
## References
* This is another step towards fixing the conpty narrowing bugs in issue
#2661.
* This is technically a fix for issue #5384, but that won't be apparent
until #2661 is complete.
## PR Checklist
* [x] Closes #1223
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already.
## Detailed Description of the Pull Request / Additional comments
The first part of this PR was the introduction of a new `ColorType` in
the `TextColor` class. Instead of just the one `IsIndex` type, there is
now an `IsIndex16` and an `IsIndex256`. `IsIndex16` covers the eight
original ANSI colors set with `SGR 3x` and `SGR 4x`, as well as the
brighter aixterm variants set with `SGR 9x` and `SGR 10x`. `IsIndex256`
covers the 256 ISO/ITU indexed colors set with `SGR 38;5` and `SGR
48;5`.
There are two reasons for this distinction. The first is that the ANSI
colors have the potential to be brightened by the `SGR 1` bold
attribute, while the ISO/ITO color do not. The second reason is that
when forwarding an attributes through conpty, we want to try and
preserve the original SGR sequence that generated each color (to the
extent that that is possible). By having the two separate types, we can
map the `IsIndex16` colors back to ANSI/aixterm values, and `IsIndex256`
to the ISO/ITU sequences.
In addition to the VT colors, we also have to deal with the legacy
colors set by the Windows console APIs, but we don't really need a
separate type for those. It seemed most appropriate to me to store them
as `IsIndex256` colors, since it doesn't make sense to have them
brightened by the `SGR 1` attribute (which is what would happen if they
were stored as `IsIndex16`). If a console app wanted a bright color it
would have selected one, so we shouldn't be messing with that choice.
The second part of the PR was the unification of the two color tables.
Originally we had a 16 color table for the legacy colors, and a separate
table for the 256 ISO/ITU colors. These have now been merged into one,
so color table lookups no longer need to decide which of the two tables
they should be referencing. I've also updated all the methods that took
a color table as a parameter to use a `basic_string_view` instead of
separate pointer and length variables, which I think makes them a lot
easier and safer to work with.
With this new architecture in place, I could now update the
`AdaptDispatch` SGR implementation to store the ISO/ITU indexed colors
as `IsIndex256` values, where before they were mapped to RGB values
(which prevented them reflecting any color scheme changes). I could also
update the `TerminalDispatch` implementation to differentiate between
the two index types, so that the `SGR 1` brightening would only be
applied to the ANSI colors.
I've also done a bit of code refactoring to try and minimise any direct
access to the color tables, getting rid of a lot of places that were
copying tables with `memmove` operations. I'm hoping this will make it
easier for us to update the code in the future if we want to reorder the
table entries (which is likely a requirement for unifying the
`AdaptDispatch` and `TerminalDispatch` implementations).
## Validation Steps Performed
For testing, I've just updated the existing unit tests to account for
the API changes. The `TextColorTests` required an extra parameter
specifying the index type when setting an index. And the `AdapterTest`
and `ScreenBufferTests` required the use of the new `SetIndexedXXX`
methods in order to be explicit about the index type, instead of relying
on the `TextAttribute` constructor and the old `SetForeground` and
`SetBackground` methods which didn't have a way to differentiate index
types.
I've manually tested the various console APIs
(`SetConsoleTextAttribute`, `ReadConsoleOutputAttribute`, and
`ReadConsoleOutput`), to make sure they are still setting and reading
the attributes as well as they used to. And I've tested the
`SetConsoleScreenBufferInfoEx` and `GetConsoleScreenBufferInfoEx` APIs
to make sure they can read and write the color table correctly. I've
also tested the color table in the properties dialog, made sure it was
saved and restored from the registry correctly, and similarly saved and
restored from a shortcut link.
Note that there are still a bunch of issues with the color table APIs,
but no new problems have been introduced by the changes in this PR, as
far as I could tell.
I've also done a bunch of manual tests of `OSC 4` to make sure it's
updating all the colors correctly (at least in conhost), and confirmed
that the test case in issue #1223 now works as expected.
2020-05-28 00:34:45 +02:00
|
|
|
for (size_t i = 0; i < std::size(pStateInfo->ColorTable); i++)
|
|
|
|
{
|
Standardize the color table order (#11602)
## Summary of the Pull Request
In the original implementation, we used two different orderings for the color tables. The WT color table used ANSI order, while the conhost color table used a Windows-specific order. This PR standardizes on the ANSI color order everywhere, so the usage of indexed colors is consistent across both parts of the code base, which will hopefully allow more of the code to be shared one day.
## References
This is another small step towards de-duplicating `AdaptDispatch` and `TerminalDispatch` for issue #3849, and is essentially a followup to the SGR dispatch refactoring in PR #6728.
## PR Checklist
* [x] Closes #11461
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number where discussion took place: #11461
## Detailed Description of the Pull Request / Additional comments
Conhost still needs to deal with legacy attributes using Windows color order, so those values now need to be transposed to ANSI colors order when creating a `TextAttribute` object. This is done with a simple mapping table, which also handles the translation of the default color entries, so it's actually slightly faster than the original code.
And when converting `TextAttribute` values back to legacy console attributes, we were already using a mapping table to handle the narrowing of 256-color values down to 16 colors, so we just needed to adjust that table to account for the translation from ANSI to Windows, and then could make use of the same table for both 256-color and 16-color values.
There are also a few places in conhost that read from or write to the color tables, and those now need to transpose the index values. I've addressed this by creating separate `SetLegacyColorTableEntry` and `GetLegacyColorTableEntry` methods in the `Settings` class which take care of the mapping, so it's now clearer in which cases the code is dealing with legacy values, and which are ANSI values.
These methods are used in the `SetConsoleScreenBufferInfoEx` and `GetConsoleScreenBufferInfoEx` APIs, as well as a few place where color preferences are handled (the registry, shortcut links, and the properties dialog), none of which are particularly sensitive to performance. However, we also use the legacy table when looking up the default colors for rendering (which happens a lot), so I've refactored that code so the default color calculations now only occur once per frame.
The plus side of all of this is that the VT code doesn't need to do the index translation anymore, so we can finally get rid of all the calls to `XTermToWindowsIndex`, and we no longer need a separate color table initialization method for conhost, so I was able to merge a number of color initialization methods into one. We also no longer need to translate from legacy values to ANSI when generating VT sequences for conpty.
The one exception to that is the 16-color VT renderer, which uses the `TextColor::GetLegacyIndex` method to approximate 16-color equivalents for RGB and 256-color values. Since that method returns a legacy index, it still needs to be translated to ANSI before it can be used in a VT sequence. But this should be no worse than it was before.
One more special case is conhost's secret _Color Selection_ feature. That uses `Ctrl`+Number and `Alt`+Number key sequences to highlight parts of the buffer, and the mapping from number to color is based on the Windows color order. So that mapping now needs to be transposed, but that's also not performance sensitive.
The only thing that I haven't bothered to update is the trace logging code in the `Telemetry` class, which logs the first 16 entries in the color table. Those entries are now going to be in a different order, but I didn't think that would be of great concern to anyone.
## Validation Steps Performed
A lot of unit tests needed to be updated to use ANSI color constants when setting indexed colors, where before they might have been expecting values in Windows order. But this replaced a wild mix of different constants, sometimes having to use bit shifting, as well as values mapped with `XTermToWindowsIndex`, so I think the tests are a whole lot clearer now. Only a few cases have been left with literal numbers where that seemed more appropriate.
In addition to getting the unit tests working, I've also manually tested the behaviour of all the console APIs which I thought could be affected by these changes, and confirmed that they produced the same results in the new code as they did in the original implementation.
This includes:
- `WriteConsoleOutput`
- `ReadConsoleOutput`
- `SetConsoleTextAttribute` with `WriteConsoleOutputCharacter`
- `FillConsoleOutputAttribute` and `FillConsoleOutputCharacter`
- `ScrollConsoleScreenBuffer`
- `GetConsoleScreenBufferInfo`
- `GetConsoleScreenBufferInfoEx`
- `SetConsoleScreenBufferInfoEx`
I've also manually tested changing colors via the console properties menu, the registry, and shortcut links, including setting default colors and popup colors. And I've tested that the "Quirks Mode" is still working as expected in PowerShell.
In terms of performance, I wrote a little test app that filled a 80x9999 buffer with random color combinations using `WriteConsoleOutput`, which I figured was likely to be the most performance sensitive call, and I think it now actually performs slightly better than the original implementation.
I've also tested similar code - just filling the visible window - with SGR VT sequences of various types, and the performance seems about the same as it was before.
2021-11-04 23:13:22 +01:00
|
|
|
gci.SetLegacyColorTableEntry(i, pStateInfo->ColorTable[i]);
|
Fix SGR indexed colors to distinguish Indexed256 color (and more) (#5834)
This PR introduces a new `ColorType` to allow us to distinguish between
`SGR` indexed colors from the 16 color table, the lower half of which
can be brightened, and the ISO/ITU indexed colors from the 256 color
table, which have a fixed brightness. Retaining the distinction between
these two types will enable us to forward the correct `SGR` sequences to
conpty when addressing issue #2661.
The other benefit of retaining the color index (which we didn't
previously do for ISO/ITU colors) is that it ensures that the colors are
updated correctly when the color scheme is changed.
## References
* This is another step towards fixing the conpty narrowing bugs in issue
#2661.
* This is technically a fix for issue #5384, but that won't be apparent
until #2661 is complete.
## PR Checklist
* [x] Closes #1223
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already.
## Detailed Description of the Pull Request / Additional comments
The first part of this PR was the introduction of a new `ColorType` in
the `TextColor` class. Instead of just the one `IsIndex` type, there is
now an `IsIndex16` and an `IsIndex256`. `IsIndex16` covers the eight
original ANSI colors set with `SGR 3x` and `SGR 4x`, as well as the
brighter aixterm variants set with `SGR 9x` and `SGR 10x`. `IsIndex256`
covers the 256 ISO/ITU indexed colors set with `SGR 38;5` and `SGR
48;5`.
There are two reasons for this distinction. The first is that the ANSI
colors have the potential to be brightened by the `SGR 1` bold
attribute, while the ISO/ITO color do not. The second reason is that
when forwarding an attributes through conpty, we want to try and
preserve the original SGR sequence that generated each color (to the
extent that that is possible). By having the two separate types, we can
map the `IsIndex16` colors back to ANSI/aixterm values, and `IsIndex256`
to the ISO/ITU sequences.
In addition to the VT colors, we also have to deal with the legacy
colors set by the Windows console APIs, but we don't really need a
separate type for those. It seemed most appropriate to me to store them
as `IsIndex256` colors, since it doesn't make sense to have them
brightened by the `SGR 1` attribute (which is what would happen if they
were stored as `IsIndex16`). If a console app wanted a bright color it
would have selected one, so we shouldn't be messing with that choice.
The second part of the PR was the unification of the two color tables.
Originally we had a 16 color table for the legacy colors, and a separate
table for the 256 ISO/ITU colors. These have now been merged into one,
so color table lookups no longer need to decide which of the two tables
they should be referencing. I've also updated all the methods that took
a color table as a parameter to use a `basic_string_view` instead of
separate pointer and length variables, which I think makes them a lot
easier and safer to work with.
With this new architecture in place, I could now update the
`AdaptDispatch` SGR implementation to store the ISO/ITU indexed colors
as `IsIndex256` values, where before they were mapped to RGB values
(which prevented them reflecting any color scheme changes). I could also
update the `TerminalDispatch` implementation to differentiate between
the two index types, so that the `SGR 1` brightening would only be
applied to the ANSI colors.
I've also done a bit of code refactoring to try and minimise any direct
access to the color tables, getting rid of a lot of places that were
copying tables with `memmove` operations. I'm hoping this will make it
easier for us to update the code in the future if we want to reorder the
table entries (which is likely a requirement for unifying the
`AdaptDispatch` and `TerminalDispatch` implementations).
## Validation Steps Performed
For testing, I've just updated the existing unit tests to account for
the API changes. The `TextColorTests` required an extra parameter
specifying the index type when setting an index. And the `AdapterTest`
and `ScreenBufferTests` required the use of the new `SetIndexedXXX`
methods in order to be explicit about the index type, instead of relying
on the `TextAttribute` constructor and the old `SetForeground` and
`SetBackground` methods which didn't have a way to differentiate index
types.
I've manually tested the various console APIs
(`SetConsoleTextAttribute`, `ReadConsoleOutputAttribute`, and
`ReadConsoleOutput`), to make sure they are still setting and reading
the attributes as well as they used to. And I've tested the
`SetConsoleScreenBufferInfoEx` and `GetConsoleScreenBufferInfoEx` APIs
to make sure they can read and write the color table correctly. I've
also tested the color table in the properties dialog, made sure it was
saved and restored from the registry correctly, and similarly saved and
restored from a shortcut link.
Note that there are still a bunch of issues with the color table APIs,
but no new problems have been introduced by the changes in this PR, as
far as I could tell.
I've also done a bunch of manual tests of `OSC 4` to make sure it's
updating all the colors correctly (at least in conhost), and confirmed
that the test case in issue #1223 now works as expected.
2020-05-28 00:34:45 +02:00
|
|
|
}
|
2019-05-03 00:29:04 +02:00
|
|
|
|
|
|
|
// Ensure that attributes only contain color specification.
|
|
|
|
WI_ClearAllFlags(pStateInfo->ScreenAttributes, ~(FG_ATTRS | BG_ATTRS));
|
|
|
|
WI_ClearAllFlags(pStateInfo->PopupAttributes, ~(FG_ATTRS | BG_ATTRS));
|
|
|
|
|
|
|
|
// Place our new legacy fill attributes in gci
|
|
|
|
// (recall they are already persisted to the reg/link by the propsheet
|
|
|
|
// when it was closed)
|
|
|
|
gci.SetFillAttribute(pStateInfo->ScreenAttributes);
|
|
|
|
gci.SetPopupFillAttribute(pStateInfo->PopupAttributes);
|
|
|
|
// Store our updated Default Color values
|
Consolidate the color palette APIs (#11784)
This PR merges the default colors and cursor color into the main color
table, enabling us to simplify the `ConGetSet` and `ITerminalApi`
interfaces, with just two methods required for getting and setting any
form of color palette entry.
The is a follow-up to the color table standardization in #11602, and a
another small step towards de-duplicating `AdaptDispatch` and
`TerminalDispatch` for issue #3849. It should also make it easier to
support color queries (#3718) and a configurable bold color (#5682) in
the future.
On the conhost side, default colors could originally be either indexed
positions in the 16-color table, or separate standalone RGB values. With
the new system, the default colors will always be in the color table, so
we just need to track their index positions.
To make this work, those positions need to be calculated at startup
based on the loaded registry/shortcut settings, and updated when
settings are changed (this is handled in
`CalculateDefaultColorIndices`). But the plus side is that it's now much
easier to lookup the default color values for rendering.
For now the default colors in Windows Terminal use hardcoded positions,
because it doesn't need indexed default colors like conhost. But in the
future I'd like to extend the index handling to both terminals, so we
can eventually support the VT525 indexed color operations.
As for the cursor color, that was previously stored in the `Cursor`
class, which meant that it needed to be copied around in various places
where cursors were being instantiated. Now that it's managed separately
in the color table, a lot of that code is no longer required.
## Validation
Some of the unit test initialization code needed to be updated to setup
the color table and default index values as required for the new system.
There were also some adjustments needed to account for API changes, in
particular for methods that now take index values for the default colors
in place of COLORREFs. But for the most part, the essential behavior of
the tests remains unchanged.
I've also run a variety of manual tests looking at the legacy console
APIs as well as the various VT color sequences, and checking that
everything works as expected when color schemes are changed, both in
Windows Terminal and conhost, and in the latter case with both indexed
colors and RGB values.
Closes #11768
2021-11-23 19:28:55 +01:00
|
|
|
gci.SetColorTableEntry(TextColor::DEFAULT_FOREGROUND, pStateInfo->DefaultForeground);
|
|
|
|
gci.SetColorTableEntry(TextColor::DEFAULT_BACKGROUND, pStateInfo->DefaultBackground);
|
2019-05-03 00:29:04 +02:00
|
|
|
|
Improve conpty rendering of default colors in legacy apps (#6698)
Essentially what this does is map the default legacy foreground and
background attributes (typically white on black) to the `IsDefault`
color type in the `TextColor` class. As a result, we can now initialize
the buffer for "legacy" shells (like PowerShell and cmd.exe) with
default colors, instead of white on black. This fixes the startup
rendering in conpty clients, which expect an initial default background
color. It also makes these colors update appropriately when the default
palette values change.
One complication in getting this to work, is that the console permits
users to change which color indices are designated as defaults, so we
can't assume they'll always be white on black. This means that the
legacy-to-`TextAttribute` conversion will need access to those default
values.
Unfortunately the defaults are stored in the conhost `Settings` class
(the `_wFillAttribute` field), which isn't easily accessible to all the
code that needs to construct a `TextAttribute` from a legacy value. The
`OutputCellIterator` is particularly problematic, because some iterator
types need to generate a new `TextAttribute` on every iteration.
So after trying a couple of different approaches, I decided that the
least worst option would be to add a pair of static properties for the
legacy defaults in the `TextAttribute` class itself, then refresh those
values from the `Settings` class whenever the defaults changed (this
only happens on startup, or when the conhost _Properties_ dialog is
edited).
And once the `TextAttribute` class had access to those defaults, it was
fairly easy to adapt the constructor to handle the conversion of default
values to the `IsDefault` color type. I could also then simplify the
`TextAttribute::GetLegacyAttributes` method which does the reverse
mapping, and which previously required the default values to be passed
in as a parameter
VALIDATION
I had to make one small change to the `TestRoundtripExhaustive` unit
test which assumed that all legacy attributes would convert to legacy
color types, which is no longer the case, but otherwise all the existing
tests passed as is. I added a new unit test verifying that the default
legacy attributes correctly mapped to default color types, and the
default color types were mapped back to the correct legacy attributes.
I've manually confirmed that this fixed the issue raised in #5952,
namely that the conhost screen is cleared with the correct default
colors, and also that it is correctly refreshed when changing the
palette from the properties dialog. And I've combined this PR with
#6506, and confirmed that the PowerShell and the cmd shell renderings in
Windows Terminal are at least improved, if not always perfect.
This is a prerequisite for PR #6506
Closes #5952
2020-07-01 20:08:30 +02:00
|
|
|
// Make sure the updated fill attributes are passed on to the TextAttribute class.
|
|
|
|
TextAttribute::SetLegacyDefaultAttributes(pStateInfo->ScreenAttributes);
|
Consolidate the color palette APIs (#11784)
This PR merges the default colors and cursor color into the main color
table, enabling us to simplify the `ConGetSet` and `ITerminalApi`
interfaces, with just two methods required for getting and setting any
form of color palette entry.
The is a follow-up to the color table standardization in #11602, and a
another small step towards de-duplicating `AdaptDispatch` and
`TerminalDispatch` for issue #3849. It should also make it easier to
support color queries (#3718) and a configurable bold color (#5682) in
the future.
On the conhost side, default colors could originally be either indexed
positions in the 16-color table, or separate standalone RGB values. With
the new system, the default colors will always be in the color table, so
we just need to track their index positions.
To make this work, those positions need to be calculated at startup
based on the loaded registry/shortcut settings, and updated when
settings are changed (this is handled in
`CalculateDefaultColorIndices`). But the plus side is that it's now much
easier to lookup the default color values for rendering.
For now the default colors in Windows Terminal use hardcoded positions,
because it doesn't need indexed default colors like conhost. But in the
future I'd like to extend the index handling to both terminals, so we
can eventually support the VT525 indexed color operations.
As for the cursor color, that was previously stored in the `Cursor`
class, which meant that it needed to be copied around in various places
where cursors were being instantiated. Now that it's managed separately
in the color table, a lot of that code is no longer required.
## Validation
Some of the unit test initialization code needed to be updated to setup
the color table and default index values as required for the new system.
There were also some adjustments needed to account for API changes, in
particular for methods that now take index values for the default colors
in place of COLORREFs. But for the most part, the essential behavior of
the tests remains unchanged.
I've also run a variety of manual tests looking at the legacy console
APIs as well as the various VT color sequences, and checking that
everything works as expected when color schemes are changed, both in
Windows Terminal and conhost, and in the latter case with both indexed
colors and RGB values.
Closes #11768
2021-11-23 19:28:55 +01:00
|
|
|
// And recalculate the position of the default colors in the color table.
|
|
|
|
gci.CalculateDefaultColorIndices();
|
Improve conpty rendering of default colors in legacy apps (#6698)
Essentially what this does is map the default legacy foreground and
background attributes (typically white on black) to the `IsDefault`
color type in the `TextColor` class. As a result, we can now initialize
the buffer for "legacy" shells (like PowerShell and cmd.exe) with
default colors, instead of white on black. This fixes the startup
rendering in conpty clients, which expect an initial default background
color. It also makes these colors update appropriately when the default
palette values change.
One complication in getting this to work, is that the console permits
users to change which color indices are designated as defaults, so we
can't assume they'll always be white on black. This means that the
legacy-to-`TextAttribute` conversion will need access to those default
values.
Unfortunately the defaults are stored in the conhost `Settings` class
(the `_wFillAttribute` field), which isn't easily accessible to all the
code that needs to construct a `TextAttribute` from a legacy value. The
`OutputCellIterator` is particularly problematic, because some iterator
types need to generate a new `TextAttribute` on every iteration.
So after trying a couple of different approaches, I decided that the
least worst option would be to add a pair of static properties for the
legacy defaults in the `TextAttribute` class itself, then refresh those
values from the `Settings` class whenever the defaults changed (this
only happens on startup, or when the conhost _Properties_ dialog is
edited).
And once the `TextAttribute` class had access to those defaults, it was
fairly easy to adapt the constructor to handle the conversion of default
values to the `IsDefault` color type. I could also then simplify the
`TextAttribute::GetLegacyAttributes` method which does the reverse
mapping, and which previously required the default values to be passed
in as a parameter
VALIDATION
I had to make one small change to the `TestRoundtripExhaustive` unit
test which assumed that all legacy attributes would convert to legacy
color types, which is no longer the case, but otherwise all the existing
tests passed as is. I added a new unit test verifying that the default
legacy attributes correctly mapped to default color types, and the
default color types were mapped back to the correct legacy attributes.
I've manually confirmed that this fixed the issue raised in #5952,
namely that the conhost screen is cleared with the correct default
colors, and also that it is correctly refreshed when changing the
palette from the properties dialog. And I've combined this PR with
#6506, and confirmed that the PowerShell and the cmd shell renderings in
Windows Terminal are at least improved, if not always perfect.
This is a prerequisite for PR #6506
Closes #5952
2020-07-01 20:08:30 +02:00
|
|
|
|
2019-05-03 00:29:04 +02:00
|
|
|
// Set the screen info's default text attributes to defaults -
|
Improve conpty rendering of default colors in legacy apps (#6698)
Essentially what this does is map the default legacy foreground and
background attributes (typically white on black) to the `IsDefault`
color type in the `TextColor` class. As a result, we can now initialize
the buffer for "legacy" shells (like PowerShell and cmd.exe) with
default colors, instead of white on black. This fixes the startup
rendering in conpty clients, which expect an initial default background
color. It also makes these colors update appropriately when the default
palette values change.
One complication in getting this to work, is that the console permits
users to change which color indices are designated as defaults, so we
can't assume they'll always be white on black. This means that the
legacy-to-`TextAttribute` conversion will need access to those default
values.
Unfortunately the defaults are stored in the conhost `Settings` class
(the `_wFillAttribute` field), which isn't easily accessible to all the
code that needs to construct a `TextAttribute` from a legacy value. The
`OutputCellIterator` is particularly problematic, because some iterator
types need to generate a new `TextAttribute` on every iteration.
So after trying a couple of different approaches, I decided that the
least worst option would be to add a pair of static properties for the
legacy defaults in the `TextAttribute` class itself, then refresh those
values from the `Settings` class whenever the defaults changed (this
only happens on startup, or when the conhost _Properties_ dialog is
edited).
And once the `TextAttribute` class had access to those defaults, it was
fairly easy to adapt the constructor to handle the conversion of default
values to the `IsDefault` color type. I could also then simplify the
`TextAttribute::GetLegacyAttributes` method which does the reverse
mapping, and which previously required the default values to be passed
in as a parameter
VALIDATION
I had to make one small change to the `TestRoundtripExhaustive` unit
test which assumed that all legacy attributes would convert to legacy
color types, which is no longer the case, but otherwise all the existing
tests passed as is. I added a new unit test verifying that the default
legacy attributes correctly mapped to default color types, and the
default color types were mapped back to the correct legacy attributes.
I've manually confirmed that this fixed the issue raised in #5952,
namely that the conhost screen is cleared with the correct default
colors, and also that it is correctly refreshed when changing the
palette from the properties dialog. And I've combined this PR with
#6506, and confirmed that the PowerShell and the cmd shell renderings in
Windows Terminal are at least improved, if not always perfect.
This is a prerequisite for PR #6506
Closes #5952
2020-07-01 20:08:30 +02:00
|
|
|
ScreenInfo.SetDefaultAttributes({}, TextAttribute{ gci.GetPopupFillAttribute() });
|
2019-05-03 00:29:04 +02:00
|
|
|
|
|
|
|
CommandHistory::s_ResizeAll(pStateInfo->HistoryBufferSize);
|
|
|
|
gci.SetNumberOfHistoryBuffers(pStateInfo->NumberOfHistoryBuffers);
|
|
|
|
if (pStateInfo->HistoryNoDup)
|
|
|
|
{
|
|
|
|
gci.Flags |= CONSOLE_HISTORY_NODUP;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
gci.Flags &= ~CONSOLE_HISTORY_NODUP;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Since edit keys are global state only stored once in the registry, post the message to the queue to reload
|
|
|
|
// those properties specifically from the registry in case they were changed.
|
|
|
|
ServiceLocator::LocateConsoleWindow<Window>()->PostUpdateExtendedEditKeys();
|
|
|
|
|
|
|
|
gci.ConsoleIme.RefreshAreaAttributes();
|
|
|
|
|
|
|
|
gci.SetInterceptCopyPaste(!!pStateInfo->InterceptCopyPaste);
|
|
|
|
}
|
|
|
|
|
|
|
|
#pragma endregion
|