terminal/src/cascadia/WindowsTerminal/IslandWindow.cpp

1788 lines
67 KiB
C++
Raw Normal View History

// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#include "pch.h"
#include "IslandWindow.h"
#include "../types/inc/Viewport.hpp"
#include "resource.h"
#include "icon.h"
#include "NotificationIcon.h"
#include <dwmapi.h>
#include <TerminalThemeHelpers.h>
extern "C" IMAGE_DOS_HEADER __ImageBase;
using namespace winrt::Windows::UI;
using namespace winrt::Windows::UI::Composition;
using namespace winrt::Windows::UI::Xaml;
using namespace winrt::Windows::UI::Xaml::Hosting;
using namespace winrt::Windows::Foundation::Numerics;
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
using namespace winrt::Microsoft::Terminal::Settings::Model;
2021-04-29 00:13:28 +02:00
using namespace winrt::Microsoft::Terminal::Control;
Add `"monitor": "any"|"toCurrent"|"toMouse"` setting to globalSummon (#10092) #### ⚠️ this pr targets #9977 ## Summary of the Pull Request This adds support for part of the `monitor` property for `globalSummon`. It also goes a little off-spec: ```json "monitor": "any"|"toCurrent"|"toMouse" ``` * `monitor`: This controls the monitor that the window will be summoned from/to - `"any"`: Summon the MRU window, regardless of which monitor it's currently on. - `"toCurrent"`/omitted: (_default_): Summon the MRU window **TO** the monitor with the current **foreground** window. - [**NEW**] `"toMouse"`: Summon the MRU window **TO** the monitor where the **mouse** cursor is. When I was playing with this, It felt like `toMouse` was always what I wanted, not `toCurrent`. We can always just comment that out if we think that's contentious - I'm aware I didn't originally spec that. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-60325291 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated 😢 ## Detailed Description of the Pull Request / Additional comments I made `toMouse` the default because it felt better. fite-me.jpg ## Validation Steps Performed my ever evolving blob: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-17 14:57:08 +02:00
using namespace winrt::Microsoft::Terminal;
using namespace ::Microsoft::Console::Types;
using VirtualKeyModifiers = winrt::Windows::System::VirtualKeyModifiers;
#define XAML_HOSTING_WINDOW_CLASS_NAME L"CASCADIA_HOSTING_WINDOW_CLASS"
#define IDM_SYSTEM_MENU_BEGIN 0x1000
const UINT WM_TASKBARCREATED = RegisterWindowMessage(L"TaskbarCreated");
IslandWindow::IslandWindow() noexcept :
_interopWindowHandle{ nullptr },
_rootGrid{ nullptr },
_source{ nullptr },
_pfnCreateCallback{ nullptr }
{
}
IslandWindow::~IslandWindow()
{
_source.Close();
}
// Method Description:
// - Create the actual window that we'll use for the application.
// Arguments:
// - <none>
// Return Value:
// - <none>
void IslandWindow::MakeWindow() noexcept
{
WNDCLASS wc{};
wc.hCursor = LoadCursor(nullptr, IDC_ARROW);
wc.hInstance = reinterpret_cast<HINSTANCE>(&__ImageBase);
wc.lpszClassName = XAML_HOSTING_WINDOW_CLASS_NAME;
wc.style = CS_HREDRAW | CS_VREDRAW;
wc.lpfnWndProc = WndProc;
wc.hIcon = LoadIconW(wc.hInstance, MAKEINTRESOURCEW(IDI_APPICON));
RegisterClass(&wc);
WINRT_ASSERT(!_window);
// Create the window with the default size here - During the creation of the
2019-05-21 08:15:44 +02:00
// window, the system will give us a chance to set its size in WM_CREATE.
// WM_CREATE will be handled synchronously, before CreateWindow returns.
//
// We need WS_EX_NOREDIRECTIONBITMAP for vintage style opacity, GH#603
//
// WS_EX_LAYERED acts REAL WEIRD with TerminalTrySetTransparentBackground,
// but it works just fine when the window is in the TOPMOST group. But if
// you enable it always, activating the window will remove our DWM frame
// entirely. Weird.
WINRT_VERIFY(CreateWindowEx(WS_EX_NOREDIRECTIONBITMAP | (_alwaysOnTop ? WS_EX_TOPMOST : 0),
wc.lpszClassName,
L"Windows Terminal",
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
nullptr,
nullptr,
wc.hInstance,
this));
WINRT_ASSERT(_window);
}
// Method Description:
// - Called when no tab is remaining to close the window.
// Arguments:
// - <none>
// Return Value:
// - <none>
void IslandWindow::Close()
{
PostQuitMessage(0);
}
// Method Description:
// - Set a callback to be called when we process a WM_CREATE message. This gives
// the AppHost a chance to resize the window to the proper size.
// Arguments:
// - pfn: a function to be called during the handling of WM_CREATE. It takes two
// parameters:
// * HWND: the HWND of the window that's being created.
// * RECT: The position on the screen that the system has proposed for our
// window.
// Return Value:
// - <none>
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
void IslandWindow::SetCreateCallback(std::function<void(const HWND, const RECT, LaunchMode& launchMode)> pfn) noexcept
{
_pfnCreateCallback = pfn;
}
Snap to character grid when resizing window (#3181) When user resizes window, snap the size to align with the character grid (like e.g. putty, mintty and most unix terminals). Properly resolves arbitrary pane configuration (even with different font sizes and padding) trying to align each pane as close as possible. It also fixes terminal minimum size enforcement which was not quite well handled, especially with multiple panes. This PR does not however try to keep the terminals aligned at other user actions (e.g. font change or pane split). That is to be tracked by some other activity. Snapping is resolved in the pane tree, recursively, so it (hopefully) works for any possible layout. Along the way I had to clean up some things as so to make the resulting code not so cumbersome: 1. Pane.cpp: Replaced _firstPercent and _secondPercent with single _desiredSplitPosition to reduce invariants - these had to be kept in sync so their sum always gives 1 (and were not really a percent). The desired part refers to fact that since panes are aligned, there is usually some deviation from that ratio. 2. Pane.cpp: Fixed _GetMinSize() - it was improperly accounting for split direction 3. TerminalControl: Made dedicated member for padding instead of reading it from a control itself. This is because the winrt property functions turned out to be slow and this algorithm needs to access it many times. I also cached scrollbar width for the same reason. 4. AppHost: Moved window to client size resolution to virtual method, where IslandWindow and NonClientIslandWindow have their own implementations (as opposite to pointer casting). One problem with current implementation is I had to make a long call chain from the window that requests snapping to the (root) pane that implements it: IslandWindow -> AppHost's callback -> App -> TerminalPage -> Tab -> Pane. I don't know if this can be done better. ## Validation Steps Performed Spam split pane buttons, randomly change font sizes with ctrl+mouse wheel and drag the window back and forth. Closes #2834 Closes #2277
2020-01-08 22:19:23 +01:00
// Method Description:
// - Set a callback to be called when the window is being resized by user. For given
// requested window dimension (width or height, whichever border is dragged) it should
// return a resulting window dimension that is actually set. It is used to make the
// window 'snap' to the underling terminal's character grid.
// Arguments:
// - pfn: a function that transforms requested to actual window dimension.
// pfn's parameters:
// * widthOrHeight: whether the dimension is width (true) or height (false)
// * dimension: The requested dimension that comes from user dragging a border
// of the window. It is in pixels and represents only the client area.
// pfn's return value:
// * A dimension of client area that the window should resize to.
// Return Value:
// - <none>
void IslandWindow::SetSnapDimensionCallback(std::function<float(bool, float)> pfn) noexcept
{
_pfnSnapDimensionCallback = pfn;
}
// Method Description:
// - Handles a WM_CREATE message. Calls our create callback, if one's been set.
// Arguments:
// - wParam: unused
// - lParam: the lParam of a WM_CREATE, which is a pointer to a CREATESTRUCTW
// Return Value:
// - <none>
void IslandWindow::_HandleCreateWindow(const WPARAM, const LPARAM lParam) noexcept
{
// Get proposed window rect from create structure
CREATESTRUCTW* pcs = reinterpret_cast<CREATESTRUCTW*>(lParam);
RECT rc;
rc.left = pcs->x;
rc.top = pcs->y;
rc.right = rc.left + pcs->cx;
rc.bottom = rc.top + pcs->cy;
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
LaunchMode launchMode = LaunchMode::DefaultMode;
if (_pfnCreateCallback)
{
Enable setting an initial position and maximized launch (#2817) This PR includes the code changes that enable users to set an initial position (top left corner) and launch maximized. There are some corner cases: 1. Multiple monitors. The user should be able to set the initial position to any monitors attached. For the monitors on the left side of the major monitor, the initial position values are negative. 2. If the initial position is larger than the screen resolution and the window is off-screen, the current solution is to check if the top left corner of the window intersect with any monitors. If it is not, we set the initial position to the top left corner of the nearest monitor. 3. If the user wants to launch maximized and provides an initial position, we launch the maximized window on the monitor where the position is located. # Testing To test: 1. Check-out this branch and build on VS2019 2. Launch Terminal, and open Settings. Then close the terminal. 3. Add the following setting into Json settings file as part of "globals", just after "initialRows": "initialPosition": "1000, 1000", "launchMode": "default" My test data: I have already tested with the following variables: 1. showTabsInTitlebar true or false 2. The initial position of the top left corner of the window 3. Whether to launch maximized 4. The DPI of the monitor Test data combination: Non-client island window (showTabsInTitlebar true) 1. Three monitors with the same DPI (100%), left, middle and right, with the middle one as the primary, resolution: 1980 * 1200, 1920 * 1200, 1920 * 1080 launchMode: default In-Screen test: (0, 0), (1000, 500), (2000, 300), (-1000, 400), (-100, 200), (-2000, 100), (0, 1119) out-of-screen: (200, -200): initialize to (0, 0) (200, 1500): initialize to (0, 0) (2000, -200): initialize to (1920, 0) (2500, 2000): initialize to (1920, 0) (4000 100): initialize to (1920, 0) (-1000, -100): initialize to (-1920, 0) (-3000, 100): initialize to (-1920, 0) (10000, -10000): initialize to (1920, 0) (-10000, 10000): initialize to (-1920, 0) (0, -10000): initialize to (0, 0) (0, -1): initialize to (0, 0) (0, 1200): initialize to (0, 0) launch mode: maximize (100, 100) (-1000, 100): On the left monitor (0, -2000): On the primary monitor (10000, 10000): On the primary monitor 2. Left monitor 200% DPI, primary monitor 100% DPI In screen: (-1900, 100), (-3000, 100), (-1000, 100) our-of-screen: (-8000, 100): initialize at (-1920, 0) launch Maximized: (-100, 100): launch maximized on the left monitor correctly 3. Left monitor 100% DPI, primary monitor 200% DPI In-screen: (-1900, 100), (300, 100), (-800, 100), (-200, 100) out-of-screen: (-3000, 100): initialize at (-1920, 0) launch maximized: (100, 100), (-1000, 100) For client island window, the test data is the same as above. Issues: 1. If we set the initial position on the monitor with a different DPI as the primary monitor, and the window "lays" across two monitors, then the window still renders as it is on the primary monitor. The size of the window is correct. Closes #1043
2019-10-17 06:51:50 +02:00
_pfnCreateCallback(_window.get(), rc, launchMode);
}
Enable setting an initial position and maximized launch (#2817) This PR includes the code changes that enable users to set an initial position (top left corner) and launch maximized. There are some corner cases: 1. Multiple monitors. The user should be able to set the initial position to any monitors attached. For the monitors on the left side of the major monitor, the initial position values are negative. 2. If the initial position is larger than the screen resolution and the window is off-screen, the current solution is to check if the top left corner of the window intersect with any monitors. If it is not, we set the initial position to the top left corner of the nearest monitor. 3. If the user wants to launch maximized and provides an initial position, we launch the maximized window on the monitor where the position is located. # Testing To test: 1. Check-out this branch and build on VS2019 2. Launch Terminal, and open Settings. Then close the terminal. 3. Add the following setting into Json settings file as part of "globals", just after "initialRows": "initialPosition": "1000, 1000", "launchMode": "default" My test data: I have already tested with the following variables: 1. showTabsInTitlebar true or false 2. The initial position of the top left corner of the window 3. Whether to launch maximized 4. The DPI of the monitor Test data combination: Non-client island window (showTabsInTitlebar true) 1. Three monitors with the same DPI (100%), left, middle and right, with the middle one as the primary, resolution: 1980 * 1200, 1920 * 1200, 1920 * 1080 launchMode: default In-Screen test: (0, 0), (1000, 500), (2000, 300), (-1000, 400), (-100, 200), (-2000, 100), (0, 1119) out-of-screen: (200, -200): initialize to (0, 0) (200, 1500): initialize to (0, 0) (2000, -200): initialize to (1920, 0) (2500, 2000): initialize to (1920, 0) (4000 100): initialize to (1920, 0) (-1000, -100): initialize to (-1920, 0) (-3000, 100): initialize to (-1920, 0) (10000, -10000): initialize to (1920, 0) (-10000, 10000): initialize to (-1920, 0) (0, -10000): initialize to (0, 0) (0, -1): initialize to (0, 0) (0, 1200): initialize to (0, 0) launch mode: maximize (100, 100) (-1000, 100): On the left monitor (0, -2000): On the primary monitor (10000, 10000): On the primary monitor 2. Left monitor 200% DPI, primary monitor 100% DPI In screen: (-1900, 100), (-3000, 100), (-1000, 100) our-of-screen: (-8000, 100): initialize at (-1920, 0) launch Maximized: (-100, 100): launch maximized on the left monitor correctly 3. Left monitor 100% DPI, primary monitor 200% DPI In-screen: (-1900, 100), (300, 100), (-800, 100), (-200, 100) out-of-screen: (-3000, 100): initialize at (-1920, 0) launch maximized: (100, 100), (-1000, 100) For client island window, the test data is the same as above. Issues: 1. If we set the initial position on the monitor with a different DPI as the primary monitor, and the window "lays" across two monitors, then the window still renders as it is on the primary monitor. The size of the window is correct. Closes #1043
2019-10-17 06:51:50 +02:00
int nCmdShow = SW_SHOW;
if (launchMode == LaunchMode::MaximizedMode || launchMode == LaunchMode::MaximizedFocusMode)
Enable setting an initial position and maximized launch (#2817) This PR includes the code changes that enable users to set an initial position (top left corner) and launch maximized. There are some corner cases: 1. Multiple monitors. The user should be able to set the initial position to any monitors attached. For the monitors on the left side of the major monitor, the initial position values are negative. 2. If the initial position is larger than the screen resolution and the window is off-screen, the current solution is to check if the top left corner of the window intersect with any monitors. If it is not, we set the initial position to the top left corner of the nearest monitor. 3. If the user wants to launch maximized and provides an initial position, we launch the maximized window on the monitor where the position is located. # Testing To test: 1. Check-out this branch and build on VS2019 2. Launch Terminal, and open Settings. Then close the terminal. 3. Add the following setting into Json settings file as part of "globals", just after "initialRows": "initialPosition": "1000, 1000", "launchMode": "default" My test data: I have already tested with the following variables: 1. showTabsInTitlebar true or false 2. The initial position of the top left corner of the window 3. Whether to launch maximized 4. The DPI of the monitor Test data combination: Non-client island window (showTabsInTitlebar true) 1. Three monitors with the same DPI (100%), left, middle and right, with the middle one as the primary, resolution: 1980 * 1200, 1920 * 1200, 1920 * 1080 launchMode: default In-Screen test: (0, 0), (1000, 500), (2000, 300), (-1000, 400), (-100, 200), (-2000, 100), (0, 1119) out-of-screen: (200, -200): initialize to (0, 0) (200, 1500): initialize to (0, 0) (2000, -200): initialize to (1920, 0) (2500, 2000): initialize to (1920, 0) (4000 100): initialize to (1920, 0) (-1000, -100): initialize to (-1920, 0) (-3000, 100): initialize to (-1920, 0) (10000, -10000): initialize to (1920, 0) (-10000, 10000): initialize to (-1920, 0) (0, -10000): initialize to (0, 0) (0, -1): initialize to (0, 0) (0, 1200): initialize to (0, 0) launch mode: maximize (100, 100) (-1000, 100): On the left monitor (0, -2000): On the primary monitor (10000, 10000): On the primary monitor 2. Left monitor 200% DPI, primary monitor 100% DPI In screen: (-1900, 100), (-3000, 100), (-1000, 100) our-of-screen: (-8000, 100): initialize at (-1920, 0) launch Maximized: (-100, 100): launch maximized on the left monitor correctly 3. Left monitor 100% DPI, primary monitor 200% DPI In-screen: (-1900, 100), (300, 100), (-800, 100), (-200, 100) out-of-screen: (-3000, 100): initialize at (-1920, 0) launch maximized: (100, 100), (-1000, 100) For client island window, the test data is the same as above. Issues: 1. If we set the initial position on the monitor with a different DPI as the primary monitor, and the window "lays" across two monitors, then the window still renders as it is on the primary monitor. The size of the window is correct. Closes #1043
2019-10-17 06:51:50 +02:00
{
nCmdShow = SW_MAXIMIZE;
}
ShowWindow(_window.get(), nCmdShow);
UpdateWindow(_window.get());
UpdateWindowIconForActiveMetrics(_window.get());
}
Snap to character grid when resizing window (#3181) When user resizes window, snap the size to align with the character grid (like e.g. putty, mintty and most unix terminals). Properly resolves arbitrary pane configuration (even with different font sizes and padding) trying to align each pane as close as possible. It also fixes terminal minimum size enforcement which was not quite well handled, especially with multiple panes. This PR does not however try to keep the terminals aligned at other user actions (e.g. font change or pane split). That is to be tracked by some other activity. Snapping is resolved in the pane tree, recursively, so it (hopefully) works for any possible layout. Along the way I had to clean up some things as so to make the resulting code not so cumbersome: 1. Pane.cpp: Replaced _firstPercent and _secondPercent with single _desiredSplitPosition to reduce invariants - these had to be kept in sync so their sum always gives 1 (and were not really a percent). The desired part refers to fact that since panes are aligned, there is usually some deviation from that ratio. 2. Pane.cpp: Fixed _GetMinSize() - it was improperly accounting for split direction 3. TerminalControl: Made dedicated member for padding instead of reading it from a control itself. This is because the winrt property functions turned out to be slow and this algorithm needs to access it many times. I also cached scrollbar width for the same reason. 4. AppHost: Moved window to client size resolution to virtual method, where IslandWindow and NonClientIslandWindow have their own implementations (as opposite to pointer casting). One problem with current implementation is I had to make a long call chain from the window that requests snapping to the (root) pane that implements it: IslandWindow -> AppHost's callback -> App -> TerminalPage -> Tab -> Pane. I don't know if this can be done better. ## Validation Steps Performed Spam split pane buttons, randomly change font sizes with ctrl+mouse wheel and drag the window back and forth. Closes #2834 Closes #2277
2020-01-08 22:19:23 +01:00
// Method Description:
// - Handles a WM_SIZING message, which occurs when user drags a window border
// or corner. It intercepts this resize action and applies 'snapping' i.e.
// aligns the terminal's size to its cell grid. We're given the window size,
// which we then adjust based on the terminal's properties (like font size).
// Arguments:
// - wParam: Specifies which edge of the window is being dragged.
// - lParam: Pointer to the requested window rectangle (this is, the one that
// originates from current drag action). It also acts as the return value
// (it's a ref parameter).
// Return Value:
// - <none>
LRESULT IslandWindow::_OnSizing(const WPARAM wParam, const LPARAM lParam)
{
if (!_pfnSnapDimensionCallback)
{
// If we haven't been given the callback that would adjust the dimension,
// then we can't do anything, so just bail out.
Make the window name `_quake` special (#9785) ## Summary of the Pull Request This PR adds some special behavior to the window named "\_quake". * When creating the quake window, it ignores "initialRows" and "initialCols" and opens on the top half of the monitor. - It uses `initialPosition` to determine which monitor this is * It cannot be moved * It can only be vertically resized on the bottom border. * It's always in focus mode. - We should probably have an issue tracking "Allow showing tabs in focus mode"? Maybe? - This one element is maybe the one I'm least attached to When renaming a window to "\_quake", it adopts all those behaviors as well. It does not exit focus mode when leaving QM, nor does it resize back. That seemed unnecessary. ## References * As spec'ed in #9274 * See also #8888 ## PR Checklist * [x] In the pursuit of #653 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated, but I'm not gonna do any of that till quake mode is totally done. ## Detailed Description of the Pull Request / Additional comments Note that this doesn't do things like: * dropdown * global hotkey summon * summon to the current monitor * summon to the current desktop I'm doing #653 _very_ piecemeal, to try and make the PRs less egregious. ## Validation Steps Performed * validated that center on launch still works * validated that QM works on different monitors based on `initialPosition` * validated entering/exiting QM behaves as expected ## TODO! * [ ] When snapping the quake window between desktops with <kbd>win+shift+arrow</kbd>, the window doesn't horizontally re-size to the new monitor dimensions. It should.
2021-04-26 21:36:23 +02:00
return false;
Snap to character grid when resizing window (#3181) When user resizes window, snap the size to align with the character grid (like e.g. putty, mintty and most unix terminals). Properly resolves arbitrary pane configuration (even with different font sizes and padding) trying to align each pane as close as possible. It also fixes terminal minimum size enforcement which was not quite well handled, especially with multiple panes. This PR does not however try to keep the terminals aligned at other user actions (e.g. font change or pane split). That is to be tracked by some other activity. Snapping is resolved in the pane tree, recursively, so it (hopefully) works for any possible layout. Along the way I had to clean up some things as so to make the resulting code not so cumbersome: 1. Pane.cpp: Replaced _firstPercent and _secondPercent with single _desiredSplitPosition to reduce invariants - these had to be kept in sync so their sum always gives 1 (and were not really a percent). The desired part refers to fact that since panes are aligned, there is usually some deviation from that ratio. 2. Pane.cpp: Fixed _GetMinSize() - it was improperly accounting for split direction 3. TerminalControl: Made dedicated member for padding instead of reading it from a control itself. This is because the winrt property functions turned out to be slow and this algorithm needs to access it many times. I also cached scrollbar width for the same reason. 4. AppHost: Moved window to client size resolution to virtual method, where IslandWindow and NonClientIslandWindow have their own implementations (as opposite to pointer casting). One problem with current implementation is I had to make a long call chain from the window that requests snapping to the (root) pane that implements it: IslandWindow -> AppHost's callback -> App -> TerminalPage -> Tab -> Pane. I don't know if this can be done better. ## Validation Steps Performed Spam split pane buttons, randomly change font sizes with ctrl+mouse wheel and drag the window back and forth. Closes #2834 Closes #2277
2020-01-08 22:19:23 +01:00
}
LPRECT winRect = reinterpret_cast<LPRECT>(lParam);
// Find nearest monitor.
HMONITOR hmon = MonitorFromRect(winRect, MONITOR_DEFAULTTONEAREST);
// This API guarantees that dpix and dpiy will be equal, but neither is an
// optional parameter so give two UINTs.
UINT dpix = USER_DEFAULT_SCREEN_DPI;
UINT dpiy = USER_DEFAULT_SCREEN_DPI;
Make the window name `_quake` special (#9785) ## Summary of the Pull Request This PR adds some special behavior to the window named "\_quake". * When creating the quake window, it ignores "initialRows" and "initialCols" and opens on the top half of the monitor. - It uses `initialPosition` to determine which monitor this is * It cannot be moved * It can only be vertically resized on the bottom border. * It's always in focus mode. - We should probably have an issue tracking "Allow showing tabs in focus mode"? Maybe? - This one element is maybe the one I'm least attached to When renaming a window to "\_quake", it adopts all those behaviors as well. It does not exit focus mode when leaving QM, nor does it resize back. That seemed unnecessary. ## References * As spec'ed in #9274 * See also #8888 ## PR Checklist * [x] In the pursuit of #653 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated, but I'm not gonna do any of that till quake mode is totally done. ## Detailed Description of the Pull Request / Additional comments Note that this doesn't do things like: * dropdown * global hotkey summon * summon to the current monitor * summon to the current desktop I'm doing #653 _very_ piecemeal, to try and make the PRs less egregious. ## Validation Steps Performed * validated that center on launch still works * validated that QM works on different monitors based on `initialPosition` * validated entering/exiting QM behaves as expected ## TODO! * [ ] When snapping the quake window between desktops with <kbd>win+shift+arrow</kbd>, the window doesn't horizontally re-size to the new monitor dimensions. It should.
2021-04-26 21:36:23 +02:00
// If this fails, we'll use the default of 96. I think it can only fail for
// bad parameters, which we won't have, so no big deal.
LOG_IF_FAILED(GetDpiForMonitor(hmon, MDT_EFFECTIVE_DPI, &dpix, &dpiy));
Snap to character grid when resizing window (#3181) When user resizes window, snap the size to align with the character grid (like e.g. putty, mintty and most unix terminals). Properly resolves arbitrary pane configuration (even with different font sizes and padding) trying to align each pane as close as possible. It also fixes terminal minimum size enforcement which was not quite well handled, especially with multiple panes. This PR does not however try to keep the terminals aligned at other user actions (e.g. font change or pane split). That is to be tracked by some other activity. Snapping is resolved in the pane tree, recursively, so it (hopefully) works for any possible layout. Along the way I had to clean up some things as so to make the resulting code not so cumbersome: 1. Pane.cpp: Replaced _firstPercent and _secondPercent with single _desiredSplitPosition to reduce invariants - these had to be kept in sync so their sum always gives 1 (and were not really a percent). The desired part refers to fact that since panes are aligned, there is usually some deviation from that ratio. 2. Pane.cpp: Fixed _GetMinSize() - it was improperly accounting for split direction 3. TerminalControl: Made dedicated member for padding instead of reading it from a control itself. This is because the winrt property functions turned out to be slow and this algorithm needs to access it many times. I also cached scrollbar width for the same reason. 4. AppHost: Moved window to client size resolution to virtual method, where IslandWindow and NonClientIslandWindow have their own implementations (as opposite to pointer casting). One problem with current implementation is I had to make a long call chain from the window that requests snapping to the (root) pane that implements it: IslandWindow -> AppHost's callback -> App -> TerminalPage -> Tab -> Pane. I don't know if this can be done better. ## Validation Steps Performed Spam split pane buttons, randomly change font sizes with ctrl+mouse wheel and drag the window back and forth. Closes #2834 Closes #2277
2020-01-08 22:19:23 +01:00
Add and enforce minimum width (#5599) ## Summary of the Pull Request Enforces a minimum width of 460 wide. This allows tabs to always be seen (albeit partially). NOTE: A minimum height was originally added to allow the About menu to be seen. This minimum height was removed from this PR because we don't foresee a circumstance where your Terminal is in that state, and you can't just resize it to make the content fit properly. ## References #4990 may be fixed/affected by this? ## PR Checklist * [X] Closes #4976 * [X] Will close issue #5418 upon verification ## Validation Steps Performed Here's some images of what the terminal looks like when it's at its minimum size: ### 100% scaling #### 100% scaling: one tab ![100% scaling: one tab](https://user-images.githubusercontent.com/11050425/80408686-76e0fd00-887c-11ea-8283-35871d24652a.png) #### 100% scaling: two tabs ![100% scaling: two tabs](https://user-images.githubusercontent.com/11050425/80408695-79435700-887c-11ea-9670-116cde320e07.png) #### 100% scaling: 3 tabs (scrolling enabled) ![100% scaling: 3 tabs (scrolling enabled)](https://user-images.githubusercontent.com/11050425/80408701-7c3e4780-887c-11ea-8ede-8b69d20d6f66.png) ### 200% scaling #### 200% scaling: one tab ![200% scaling: one tab](https://user-images.githubusercontent.com/11050425/80408783-9a0bac80-887c-11ea-8b62-bd064f89403d.png) #### 200% scaling: two tabs ![200% scaling: two tabs](https://user-images.githubusercontent.com/11050425/80408793-9c6e0680-887c-11ea-9301-344189281006.png) #### 200% scaling: 3 tabs (scrolling enabled) ![200% scaling: 3 tabs (scrolling enabled)](https://user-images.githubusercontent.com/11050425/80408799-9ed06080-887c-11ea-892a-ee8e329080c5.png)
2020-04-29 01:24:21 +02:00
const auto widthScale = base::ClampedNumeric<float>(dpix) / USER_DEFAULT_SCREEN_DPI;
const long minWidthScaled = minimumWidth * widthScale;
Snap to character grid when resizing window (#3181) When user resizes window, snap the size to align with the character grid (like e.g. putty, mintty and most unix terminals). Properly resolves arbitrary pane configuration (even with different font sizes and padding) trying to align each pane as close as possible. It also fixes terminal minimum size enforcement which was not quite well handled, especially with multiple panes. This PR does not however try to keep the terminals aligned at other user actions (e.g. font change or pane split). That is to be tracked by some other activity. Snapping is resolved in the pane tree, recursively, so it (hopefully) works for any possible layout. Along the way I had to clean up some things as so to make the resulting code not so cumbersome: 1. Pane.cpp: Replaced _firstPercent and _secondPercent with single _desiredSplitPosition to reduce invariants - these had to be kept in sync so their sum always gives 1 (and were not really a percent). The desired part refers to fact that since panes are aligned, there is usually some deviation from that ratio. 2. Pane.cpp: Fixed _GetMinSize() - it was improperly accounting for split direction 3. TerminalControl: Made dedicated member for padding instead of reading it from a control itself. This is because the winrt property functions turned out to be slow and this algorithm needs to access it many times. I also cached scrollbar width for the same reason. 4. AppHost: Moved window to client size resolution to virtual method, where IslandWindow and NonClientIslandWindow have their own implementations (as opposite to pointer casting). One problem with current implementation is I had to make a long call chain from the window that requests snapping to the (root) pane that implements it: IslandWindow -> AppHost's callback -> App -> TerminalPage -> Tab -> Pane. I don't know if this can be done better. ## Validation Steps Performed Spam split pane buttons, randomly change font sizes with ctrl+mouse wheel and drag the window back and forth. Closes #2834 Closes #2277
2020-01-08 22:19:23 +01:00
const auto nonClientSize = GetTotalNonClientExclusiveSize(dpix);
Add and enforce minimum width (#5599) ## Summary of the Pull Request Enforces a minimum width of 460 wide. This allows tabs to always be seen (albeit partially). NOTE: A minimum height was originally added to allow the About menu to be seen. This minimum height was removed from this PR because we don't foresee a circumstance where your Terminal is in that state, and you can't just resize it to make the content fit properly. ## References #4990 may be fixed/affected by this? ## PR Checklist * [X] Closes #4976 * [X] Will close issue #5418 upon verification ## Validation Steps Performed Here's some images of what the terminal looks like when it's at its minimum size: ### 100% scaling #### 100% scaling: one tab ![100% scaling: one tab](https://user-images.githubusercontent.com/11050425/80408686-76e0fd00-887c-11ea-8283-35871d24652a.png) #### 100% scaling: two tabs ![100% scaling: two tabs](https://user-images.githubusercontent.com/11050425/80408695-79435700-887c-11ea-9670-116cde320e07.png) #### 100% scaling: 3 tabs (scrolling enabled) ![100% scaling: 3 tabs (scrolling enabled)](https://user-images.githubusercontent.com/11050425/80408701-7c3e4780-887c-11ea-8ede-8b69d20d6f66.png) ### 200% scaling #### 200% scaling: one tab ![200% scaling: one tab](https://user-images.githubusercontent.com/11050425/80408783-9a0bac80-887c-11ea-8b62-bd064f89403d.png) #### 200% scaling: two tabs ![200% scaling: two tabs](https://user-images.githubusercontent.com/11050425/80408793-9c6e0680-887c-11ea-9301-344189281006.png) #### 200% scaling: 3 tabs (scrolling enabled) ![200% scaling: 3 tabs (scrolling enabled)](https://user-images.githubusercontent.com/11050425/80408799-9ed06080-887c-11ea-892a-ee8e329080c5.png)
2020-04-29 01:24:21 +02:00
Snap to character grid when resizing window (#3181) When user resizes window, snap the size to align with the character grid (like e.g. putty, mintty and most unix terminals). Properly resolves arbitrary pane configuration (even with different font sizes and padding) trying to align each pane as close as possible. It also fixes terminal minimum size enforcement which was not quite well handled, especially with multiple panes. This PR does not however try to keep the terminals aligned at other user actions (e.g. font change or pane split). That is to be tracked by some other activity. Snapping is resolved in the pane tree, recursively, so it (hopefully) works for any possible layout. Along the way I had to clean up some things as so to make the resulting code not so cumbersome: 1. Pane.cpp: Replaced _firstPercent and _secondPercent with single _desiredSplitPosition to reduce invariants - these had to be kept in sync so their sum always gives 1 (and were not really a percent). The desired part refers to fact that since panes are aligned, there is usually some deviation from that ratio. 2. Pane.cpp: Fixed _GetMinSize() - it was improperly accounting for split direction 3. TerminalControl: Made dedicated member for padding instead of reading it from a control itself. This is because the winrt property functions turned out to be slow and this algorithm needs to access it many times. I also cached scrollbar width for the same reason. 4. AppHost: Moved window to client size resolution to virtual method, where IslandWindow and NonClientIslandWindow have their own implementations (as opposite to pointer casting). One problem with current implementation is I had to make a long call chain from the window that requests snapping to the (root) pane that implements it: IslandWindow -> AppHost's callback -> App -> TerminalPage -> Tab -> Pane. I don't know if this can be done better. ## Validation Steps Performed Spam split pane buttons, randomly change font sizes with ctrl+mouse wheel and drag the window back and forth. Closes #2834 Closes #2277
2020-01-08 22:19:23 +01:00
auto clientWidth = winRect->right - winRect->left - nonClientSize.cx;
Add and enforce minimum width (#5599) ## Summary of the Pull Request Enforces a minimum width of 460 wide. This allows tabs to always be seen (albeit partially). NOTE: A minimum height was originally added to allow the About menu to be seen. This minimum height was removed from this PR because we don't foresee a circumstance where your Terminal is in that state, and you can't just resize it to make the content fit properly. ## References #4990 may be fixed/affected by this? ## PR Checklist * [X] Closes #4976 * [X] Will close issue #5418 upon verification ## Validation Steps Performed Here's some images of what the terminal looks like when it's at its minimum size: ### 100% scaling #### 100% scaling: one tab ![100% scaling: one tab](https://user-images.githubusercontent.com/11050425/80408686-76e0fd00-887c-11ea-8283-35871d24652a.png) #### 100% scaling: two tabs ![100% scaling: two tabs](https://user-images.githubusercontent.com/11050425/80408695-79435700-887c-11ea-9670-116cde320e07.png) #### 100% scaling: 3 tabs (scrolling enabled) ![100% scaling: 3 tabs (scrolling enabled)](https://user-images.githubusercontent.com/11050425/80408701-7c3e4780-887c-11ea-8ede-8b69d20d6f66.png) ### 200% scaling #### 200% scaling: one tab ![200% scaling: one tab](https://user-images.githubusercontent.com/11050425/80408783-9a0bac80-887c-11ea-8b62-bd064f89403d.png) #### 200% scaling: two tabs ![200% scaling: two tabs](https://user-images.githubusercontent.com/11050425/80408793-9c6e0680-887c-11ea-9301-344189281006.png) #### 200% scaling: 3 tabs (scrolling enabled) ![200% scaling: 3 tabs (scrolling enabled)](https://user-images.githubusercontent.com/11050425/80408799-9ed06080-887c-11ea-892a-ee8e329080c5.png)
2020-04-29 01:24:21 +02:00
clientWidth = std::max(minWidthScaled, clientWidth);
Snap to character grid when resizing window (#3181) When user resizes window, snap the size to align with the character grid (like e.g. putty, mintty and most unix terminals). Properly resolves arbitrary pane configuration (even with different font sizes and padding) trying to align each pane as close as possible. It also fixes terminal minimum size enforcement which was not quite well handled, especially with multiple panes. This PR does not however try to keep the terminals aligned at other user actions (e.g. font change or pane split). That is to be tracked by some other activity. Snapping is resolved in the pane tree, recursively, so it (hopefully) works for any possible layout. Along the way I had to clean up some things as so to make the resulting code not so cumbersome: 1. Pane.cpp: Replaced _firstPercent and _secondPercent with single _desiredSplitPosition to reduce invariants - these had to be kept in sync so their sum always gives 1 (and were not really a percent). The desired part refers to fact that since panes are aligned, there is usually some deviation from that ratio. 2. Pane.cpp: Fixed _GetMinSize() - it was improperly accounting for split direction 3. TerminalControl: Made dedicated member for padding instead of reading it from a control itself. This is because the winrt property functions turned out to be slow and this algorithm needs to access it many times. I also cached scrollbar width for the same reason. 4. AppHost: Moved window to client size resolution to virtual method, where IslandWindow and NonClientIslandWindow have their own implementations (as opposite to pointer casting). One problem with current implementation is I had to make a long call chain from the window that requests snapping to the (root) pane that implements it: IslandWindow -> AppHost's callback -> App -> TerminalPage -> Tab -> Pane. I don't know if this can be done better. ## Validation Steps Performed Spam split pane buttons, randomly change font sizes with ctrl+mouse wheel and drag the window back and forth. Closes #2834 Closes #2277
2020-01-08 22:19:23 +01:00
auto clientHeight = winRect->bottom - winRect->top - nonClientSize.cy;
Make the window name `_quake` special (#9785) ## Summary of the Pull Request This PR adds some special behavior to the window named "\_quake". * When creating the quake window, it ignores "initialRows" and "initialCols" and opens on the top half of the monitor. - It uses `initialPosition` to determine which monitor this is * It cannot be moved * It can only be vertically resized on the bottom border. * It's always in focus mode. - We should probably have an issue tracking "Allow showing tabs in focus mode"? Maybe? - This one element is maybe the one I'm least attached to When renaming a window to "\_quake", it adopts all those behaviors as well. It does not exit focus mode when leaving QM, nor does it resize back. That seemed unnecessary. ## References * As spec'ed in #9274 * See also #8888 ## PR Checklist * [x] In the pursuit of #653 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated, but I'm not gonna do any of that till quake mode is totally done. ## Detailed Description of the Pull Request / Additional comments Note that this doesn't do things like: * dropdown * global hotkey summon * summon to the current monitor * summon to the current desktop I'm doing #653 _very_ piecemeal, to try and make the PRs less egregious. ## Validation Steps Performed * validated that center on launch still works * validated that QM works on different monitors based on `initialPosition` * validated entering/exiting QM behaves as expected ## TODO! * [ ] When snapping the quake window between desktops with <kbd>win+shift+arrow</kbd>, the window doesn't horizontally re-size to the new monitor dimensions. It should.
2021-04-26 21:36:23 +02:00
// If we're the quake window, prevent resizing on all sides except the
// bottom. This also applies to resizing with the Alt+Space menu
if (IsQuakeWindow() && wParam != WMSZ_BOTTOM)
{
// Stuff our current window size into the lParam, and return true. This
// will tell User32 to use our current dimensions to resize to.
::GetWindowRect(_window.get(), winRect);
return true;
}
Snap to character grid when resizing window (#3181) When user resizes window, snap the size to align with the character grid (like e.g. putty, mintty and most unix terminals). Properly resolves arbitrary pane configuration (even with different font sizes and padding) trying to align each pane as close as possible. It also fixes terminal minimum size enforcement which was not quite well handled, especially with multiple panes. This PR does not however try to keep the terminals aligned at other user actions (e.g. font change or pane split). That is to be tracked by some other activity. Snapping is resolved in the pane tree, recursively, so it (hopefully) works for any possible layout. Along the way I had to clean up some things as so to make the resulting code not so cumbersome: 1. Pane.cpp: Replaced _firstPercent and _secondPercent with single _desiredSplitPosition to reduce invariants - these had to be kept in sync so their sum always gives 1 (and were not really a percent). The desired part refers to fact that since panes are aligned, there is usually some deviation from that ratio. 2. Pane.cpp: Fixed _GetMinSize() - it was improperly accounting for split direction 3. TerminalControl: Made dedicated member for padding instead of reading it from a control itself. This is because the winrt property functions turned out to be slow and this algorithm needs to access it many times. I also cached scrollbar width for the same reason. 4. AppHost: Moved window to client size resolution to virtual method, where IslandWindow and NonClientIslandWindow have their own implementations (as opposite to pointer casting). One problem with current implementation is I had to make a long call chain from the window that requests snapping to the (root) pane that implements it: IslandWindow -> AppHost's callback -> App -> TerminalPage -> Tab -> Pane. I don't know if this can be done better. ## Validation Steps Performed Spam split pane buttons, randomly change font sizes with ctrl+mouse wheel and drag the window back and forth. Closes #2834 Closes #2277
2020-01-08 22:19:23 +01:00
if (wParam != WMSZ_TOP && wParam != WMSZ_BOTTOM)
{
// If user has dragged anything but the top or bottom border (so e.g. left border,
// top-right corner etc.), then this means that the width has changed. We thus ask to
// adjust this new width so that terminal(s) is/are aligned to their character grid(s).
clientWidth = gsl::narrow_cast<int>(_pfnSnapDimensionCallback(true, gsl::narrow_cast<float>(clientWidth)));
}
if (wParam != WMSZ_LEFT && wParam != WMSZ_RIGHT)
{
// Analogous to above, but for height.
clientHeight = gsl::narrow_cast<int>(_pfnSnapDimensionCallback(false, gsl::narrow_cast<float>(clientHeight)));
}
// Now make the window rectangle match the calculated client width and height,
// regarding which border the user is dragging. E.g. if user drags left border, then
// we make sure to adjust the 'left' component of rectangle and not the 'right'. Note
// that top-left and bottom-left corners also 'include' left border, hence we match
// this in multi-case switch.
// Set width
switch (wParam)
{
case WMSZ_LEFT:
case WMSZ_TOPLEFT:
case WMSZ_BOTTOMLEFT:
winRect->left = winRect->right - (clientWidth + nonClientSize.cx);
break;
case WMSZ_RIGHT:
case WMSZ_TOPRIGHT:
case WMSZ_BOTTOMRIGHT:
winRect->right = winRect->left + (clientWidth + nonClientSize.cx);
break;
}
// Set height
switch (wParam)
{
case WMSZ_BOTTOM:
case WMSZ_BOTTOMLEFT:
case WMSZ_BOTTOMRIGHT:
winRect->bottom = winRect->top + (clientHeight + nonClientSize.cy);
break;
case WMSZ_TOP:
case WMSZ_TOPLEFT:
case WMSZ_TOPRIGHT:
winRect->top = winRect->bottom - (clientHeight + nonClientSize.cy);
break;
}
Make the window name `_quake` special (#9785) ## Summary of the Pull Request This PR adds some special behavior to the window named "\_quake". * When creating the quake window, it ignores "initialRows" and "initialCols" and opens on the top half of the monitor. - It uses `initialPosition` to determine which monitor this is * It cannot be moved * It can only be vertically resized on the bottom border. * It's always in focus mode. - We should probably have an issue tracking "Allow showing tabs in focus mode"? Maybe? - This one element is maybe the one I'm least attached to When renaming a window to "\_quake", it adopts all those behaviors as well. It does not exit focus mode when leaving QM, nor does it resize back. That seemed unnecessary. ## References * As spec'ed in #9274 * See also #8888 ## PR Checklist * [x] In the pursuit of #653 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated, but I'm not gonna do any of that till quake mode is totally done. ## Detailed Description of the Pull Request / Additional comments Note that this doesn't do things like: * dropdown * global hotkey summon * summon to the current monitor * summon to the current desktop I'm doing #653 _very_ piecemeal, to try and make the PRs less egregious. ## Validation Steps Performed * validated that center on launch still works * validated that QM works on different monitors based on `initialPosition` * validated entering/exiting QM behaves as expected ## TODO! * [ ] When snapping the quake window between desktops with <kbd>win+shift+arrow</kbd>, the window doesn't horizontally re-size to the new monitor dimensions. It should.
2021-04-26 21:36:23 +02:00
return true;
}
// Method Description:
// - Handle the WM_MOVING message
// - If we're the quake window, then we don't want to be able to be moved.
// Immediately return our current window position, which will prevent us from
// being moved at all.
// Arguments:
// - lParam: a LPRECT with the proposed window position, that should be filled
// with the resultant position.
// Return Value:
// - true iff we handled this message.
LRESULT IslandWindow::_OnMoving(const WPARAM /*wParam*/, const LPARAM lParam)
{
LPRECT winRect = reinterpret_cast<LPRECT>(lParam);
// If we're the quake window, prevent moving the window. If we don't do
// this, then Alt+Space...Move will still be able to move the window.
Make the window name `_quake` special (#9785) ## Summary of the Pull Request This PR adds some special behavior to the window named "\_quake". * When creating the quake window, it ignores "initialRows" and "initialCols" and opens on the top half of the monitor. - It uses `initialPosition` to determine which monitor this is * It cannot be moved * It can only be vertically resized on the bottom border. * It's always in focus mode. - We should probably have an issue tracking "Allow showing tabs in focus mode"? Maybe? - This one element is maybe the one I'm least attached to When renaming a window to "\_quake", it adopts all those behaviors as well. It does not exit focus mode when leaving QM, nor does it resize back. That seemed unnecessary. ## References * As spec'ed in #9274 * See also #8888 ## PR Checklist * [x] In the pursuit of #653 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated, but I'm not gonna do any of that till quake mode is totally done. ## Detailed Description of the Pull Request / Additional comments Note that this doesn't do things like: * dropdown * global hotkey summon * summon to the current monitor * summon to the current desktop I'm doing #653 _very_ piecemeal, to try and make the PRs less egregious. ## Validation Steps Performed * validated that center on launch still works * validated that QM works on different monitors based on `initialPosition` * validated entering/exiting QM behaves as expected ## TODO! * [ ] When snapping the quake window between desktops with <kbd>win+shift+arrow</kbd>, the window doesn't horizontally re-size to the new monitor dimensions. It should.
2021-04-26 21:36:23 +02:00
if (IsQuakeWindow())
{
// Stuff our current window into the lParam, and return true. This
// will tell User32 to use our current position to move to.
::GetWindowRect(_window.get(), winRect);
return true;
}
return false;
Snap to character grid when resizing window (#3181) When user resizes window, snap the size to align with the character grid (like e.g. putty, mintty and most unix terminals). Properly resolves arbitrary pane configuration (even with different font sizes and padding) trying to align each pane as close as possible. It also fixes terminal minimum size enforcement which was not quite well handled, especially with multiple panes. This PR does not however try to keep the terminals aligned at other user actions (e.g. font change or pane split). That is to be tracked by some other activity. Snapping is resolved in the pane tree, recursively, so it (hopefully) works for any possible layout. Along the way I had to clean up some things as so to make the resulting code not so cumbersome: 1. Pane.cpp: Replaced _firstPercent and _secondPercent with single _desiredSplitPosition to reduce invariants - these had to be kept in sync so their sum always gives 1 (and were not really a percent). The desired part refers to fact that since panes are aligned, there is usually some deviation from that ratio. 2. Pane.cpp: Fixed _GetMinSize() - it was improperly accounting for split direction 3. TerminalControl: Made dedicated member for padding instead of reading it from a control itself. This is because the winrt property functions turned out to be slow and this algorithm needs to access it many times. I also cached scrollbar width for the same reason. 4. AppHost: Moved window to client size resolution to virtual method, where IslandWindow and NonClientIslandWindow have their own implementations (as opposite to pointer casting). One problem with current implementation is I had to make a long call chain from the window that requests snapping to the (root) pane that implements it: IslandWindow -> AppHost's callback -> App -> TerminalPage -> Tab -> Pane. I don't know if this can be done better. ## Validation Steps Performed Spam split pane buttons, randomly change font sizes with ctrl+mouse wheel and drag the window back and forth. Closes #2834 Closes #2277
2020-01-08 22:19:23 +01:00
}
void IslandWindow::Initialize()
{
_source = DesktopWindowXamlSource{};
auto interop = _source.as<IDesktopWindowXamlSourceNative>();
winrt::check_hresult(interop->AttachToWindow(_window.get()));
// stash the child interop handle so we can resize it when the main hwnd is resized
interop->get_WindowHandle(&_interopWindowHandle);
_rootGrid = winrt::Windows::UI::Xaml::Controls::Grid();
_source.Content(_rootGrid);
// initialize the taskbar object
if (auto taskbar = wil::CoCreateInstanceNoThrow<ITaskbarList3>(CLSID_TaskbarList))
{
if (SUCCEEDED(taskbar->HrInit()))
{
_taskbar = std::move(taskbar);
}
}
_systemMenuNextItemId = IDM_SYSTEM_MENU_BEGIN;
// Enable vintage opacity by removing the XAML emergency backstop, GH#603.
// We don't really care if this failed or not.
TerminalTrySetTransparentBackground(true);
}
void IslandWindow::OnSize(const UINT width, const UINT height)
{
// update the interop window size
SetWindowPos(_interopWindowHandle, nullptr, 0, 0, width, height, SWP_SHOWWINDOW | SWP_NOACTIVATE);
if (_rootGrid)
{
const auto size = GetLogicalSize();
_rootGrid.Width(size.Width);
_rootGrid.Height(size.Height);
}
}
// Method Description:
// - Handles a WM_GETMINMAXINFO message, issued before the window sizing starts.
// This message allows to modify the minimal and maximal dimensions of the window.
// We focus on minimal dimensions here
// (the maximal dimension will be calculate upon maximizing)
// Our goal is to protect against to downsizing to less than minimal allowed dimensions,
// that might occur in the scenarios where _OnSizing is bypassed.
// An example of such scenario is anchoring the window to the top/bottom screen border
// in order to maximize window height (GH# 8026).
// The computation is similar to what we do in _OnSizing:
// we need to consider both the client area and non-client exclusive area sizes,
// while taking DPI into account as well.
// Arguments:
// - lParam: Pointer to the requested MINMAXINFO struct,
// a ptMinTrackSize field of which we want to update with the computed dimensions.
// It also acts as the return value (it's a ref parameter).
// Return Value:
// - <none>
void IslandWindow::_OnGetMinMaxInfo(const WPARAM /*wParam*/, const LPARAM lParam)
{
// Without a callback we don't know to snap the dimensions of the client area.
// Should not be a problem, the callback is not set early in the startup
// The initial dimensions will be set later on
if (!_pfnSnapDimensionCallback)
{
return;
}
HMONITOR hmon = MonitorFromWindow(GetHandle(), MONITOR_DEFAULTTONEAREST);
if (hmon == NULL)
{
return;
}
UINT dpix = USER_DEFAULT_SCREEN_DPI;
UINT dpiy = USER_DEFAULT_SCREEN_DPI;
GetDpiForMonitor(hmon, MDT_EFFECTIVE_DPI, &dpix, &dpiy);
// From now we use dpix for all computations (same as in _OnSizing).
const auto nonClientSizeScaled = GetTotalNonClientExclusiveSize(dpix);
const auto scale = base::ClampedNumeric<float>(dpix) / USER_DEFAULT_SCREEN_DPI;
auto lpMinMaxInfo = reinterpret_cast<LPMINMAXINFO>(lParam);
lpMinMaxInfo->ptMinTrackSize.x = _calculateTotalSize(true, minimumWidth * scale, nonClientSizeScaled.cx);
lpMinMaxInfo->ptMinTrackSize.y = _calculateTotalSize(false, minimumHeight * scale, nonClientSizeScaled.cy);
}
// Method Description:
// - Helper function that calculates a singe dimension value, given initialWindow and nonClientSizes
// Arguments:
// - isWidth: parameter to pass to SnapDimensionCallback.
// True if the method is invoked for width computation, false if for height.
// - clientSize: the size of the client area (already)
// - nonClientSizeScaled: the exclusive non-client size (already scaled)
// Return Value:
// - The total dimension
long IslandWindow::_calculateTotalSize(const bool isWidth, const long clientSize, const long nonClientSize)
{
return gsl::narrow_cast<int>(_pfnSnapDimensionCallback(isWidth, gsl::narrow_cast<float>(clientSize)) + nonClientSize);
}
[[nodiscard]] LRESULT IslandWindow::MessageHandler(UINT const message, WPARAM const wparam, LPARAM const lparam) noexcept
{
switch (message)
{
2021-04-29 00:13:28 +02:00
case WM_HOTKEY:
{
_HotkeyPressedHandlers(static_cast<long>(wparam));
return 0;
}
case WM_GETMINMAXINFO:
{
_OnGetMinMaxInfo(wparam, lparam);
return 0;
}
case WM_CREATE:
{
_HandleCreateWindow(wparam, lparam);
return 0;
}
case WM_SETFOCUS:
{
if (_interopWindowHandle != nullptr)
{
// send focus to the child window
SetFocus(_interopWindowHandle);
2021-04-29 00:13:28 +02:00
return 0;
}
2021-04-29 00:13:28 +02:00
break;
}
Add support for running a commandline in another WT window (#8898) ## Summary of the Pull Request **If you're reading this PR and haven't signed off on #8135, go there first.** ![window-management-000](https://user-images.githubusercontent.com/18356694/103932910-25199380-50e8-11eb-97e3-594a31da62d2.gif) This provides the basic parts of the implementation of #4472. Namely: * We add support for the `--window,-w <window-id>` argument to `wt.exe`, to allow a commandline to be given to another window. * If `window-id` is `0`, run the given commands in _the current window_. * If `window-id` is a negative number, run the commands in a _new_ Terminal window. * If `window-id` is the ID of an existing window, then run the commandline in that window. * If `window-id` is _not_ the ID of an existing window, create a new window. That window will be assigned the ID provided in the commandline. The provided subcommands will be run in that new window. * If `window-id` is omitted, then create a new window. ## References * Spec: #8135 * Megathread: #5000 * Project: projects/5 ## PR Checklist * [x] Closes #4472 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - **sure does** ## Detailed Description of the Pull Request / Additional comments Note that `wt -w 1 -d c:\foo cmd.exe` does work, by causing window 1 to change There are limitations, and there are plenty of things to work on in the future: * [ ] We don't support names for windows yet * [ ] We don't support window glomming by default, or a setting to configure what happens when `-w` is omitted. I thought it best to lay the groundwork first, then come back to that. * [ ] `-w 0` currently just uses the "last activated" window, not "the current". There's more follow-up work to try and smartly find the actual window we're being called from. * [ ] Basically anything else that's listed in projects/5. I'm cutting this PR where it currently is, because this is already a huge PR. I believe the remaining tasks will all be easier to land, once this is in. ## Validation Steps Performed I've been creating windows, and closing them, and running cmdlines for a while now. I'm gonna keep doing that while the PR is open, till no bugs remain. # TODOs * [x] There are a bunch of `GetID`, `GetPID` calls that aren't try/caught 😬 - [x] `Monarch.cpp` - [x] `Peasant.cpp` - [x] `WindowManager.cpp` - [x] `AppHost.cpp` * [x] If the monarch gets hung, then _you can't launch any Terminals_ 😨 We should handle this gracefully. - Proposed idea: give the Monarch some time to respond to a proposal for a commandline. If there's no response in that timeframe, this window is now a _hermit_, outside of society entirely. It can't be elected Monarch. It can't receive command lines. It has no ID. - Could we gracefully recover from such a state? maybe, probably not though. - Same deal if a peasant hangs, it could end up hanging the monarch, right? Like if you do `wt -w 2`, and `2` is hung, then does the monarch get hung waiting on the hung peasant? - After talking with @miniksa, **we're gonna punt this from the initial implementation**. If people legit hit this in the wild, we'll fix it then.
2021-02-10 12:28:09 +01:00
case WM_ACTIVATE:
{
// wparam = 0 indicates the window was deactivated
if (LOWORD(wparam) != 0)
{
_WindowActivatedHandlers();
}
Add support for running a commandline in another WT window (#8898) ## Summary of the Pull Request **If you're reading this PR and haven't signed off on #8135, go there first.** ![window-management-000](https://user-images.githubusercontent.com/18356694/103932910-25199380-50e8-11eb-97e3-594a31da62d2.gif) This provides the basic parts of the implementation of #4472. Namely: * We add support for the `--window,-w <window-id>` argument to `wt.exe`, to allow a commandline to be given to another window. * If `window-id` is `0`, run the given commands in _the current window_. * If `window-id` is a negative number, run the commands in a _new_ Terminal window. * If `window-id` is the ID of an existing window, then run the commandline in that window. * If `window-id` is _not_ the ID of an existing window, create a new window. That window will be assigned the ID provided in the commandline. The provided subcommands will be run in that new window. * If `window-id` is omitted, then create a new window. ## References * Spec: #8135 * Megathread: #5000 * Project: projects/5 ## PR Checklist * [x] Closes #4472 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - **sure does** ## Detailed Description of the Pull Request / Additional comments Note that `wt -w 1 -d c:\foo cmd.exe` does work, by causing window 1 to change There are limitations, and there are plenty of things to work on in the future: * [ ] We don't support names for windows yet * [ ] We don't support window glomming by default, or a setting to configure what happens when `-w` is omitted. I thought it best to lay the groundwork first, then come back to that. * [ ] `-w 0` currently just uses the "last activated" window, not "the current". There's more follow-up work to try and smartly find the actual window we're being called from. * [ ] Basically anything else that's listed in projects/5. I'm cutting this PR where it currently is, because this is already a huge PR. I believe the remaining tasks will all be easier to land, once this is in. ## Validation Steps Performed I've been creating windows, and closing them, and running cmdlines for a while now. I'm gonna keep doing that while the PR is open, till no bugs remain. # TODOs * [x] There are a bunch of `GetID`, `GetPID` calls that aren't try/caught 😬 - [x] `Monarch.cpp` - [x] `Peasant.cpp` - [x] `WindowManager.cpp` - [x] `AppHost.cpp` * [x] If the monarch gets hung, then _you can't launch any Terminals_ 😨 We should handle this gracefully. - Proposed idea: give the Monarch some time to respond to a proposal for a commandline. If there's no response in that timeframe, this window is now a _hermit_, outside of society entirely. It can't be elected Monarch. It can't receive command lines. It has no ID. - Could we gracefully recover from such a state? maybe, probably not though. - Same deal if a peasant hangs, it could end up hanging the monarch, right? Like if you do `wt -w 2`, and `2` is hung, then does the monarch get hung waiting on the hung peasant? - After talking with @miniksa, **we're gonna punt this from the initial implementation**. If people legit hit this in the wild, we'll fix it then.
2021-02-10 12:28:09 +01:00
break;
}
case WM_NCLBUTTONDOWN:
case WM_NCLBUTTONUP:
case WM_NCMBUTTONDOWN:
case WM_NCMBUTTONUP:
case WM_NCRBUTTONDOWN:
case WM_NCRBUTTONUP:
case WM_NCXBUTTONDOWN:
case WM_NCXBUTTONUP:
{
// If we clicked in the titlebar, raise an event so the app host can
// dispatch an appropriate event.
_DragRegionClickedHandlers();
break;
}
case WM_MENUCHAR:
{
// GH#891: return this LRESULT here to prevent the app from making a
// bell when alt+key is pressed. A menu is active and the user presses a
// key that does not correspond to any mnemonic or accelerator key,
return MAKELRESULT(0, MNC_CLOSE);
}
Snap to character grid when resizing window (#3181) When user resizes window, snap the size to align with the character grid (like e.g. putty, mintty and most unix terminals). Properly resolves arbitrary pane configuration (even with different font sizes and padding) trying to align each pane as close as possible. It also fixes terminal minimum size enforcement which was not quite well handled, especially with multiple panes. This PR does not however try to keep the terminals aligned at other user actions (e.g. font change or pane split). That is to be tracked by some other activity. Snapping is resolved in the pane tree, recursively, so it (hopefully) works for any possible layout. Along the way I had to clean up some things as so to make the resulting code not so cumbersome: 1. Pane.cpp: Replaced _firstPercent and _secondPercent with single _desiredSplitPosition to reduce invariants - these had to be kept in sync so their sum always gives 1 (and were not really a percent). The desired part refers to fact that since panes are aligned, there is usually some deviation from that ratio. 2. Pane.cpp: Fixed _GetMinSize() - it was improperly accounting for split direction 3. TerminalControl: Made dedicated member for padding instead of reading it from a control itself. This is because the winrt property functions turned out to be slow and this algorithm needs to access it many times. I also cached scrollbar width for the same reason. 4. AppHost: Moved window to client size resolution to virtual method, where IslandWindow and NonClientIslandWindow have their own implementations (as opposite to pointer casting). One problem with current implementation is I had to make a long call chain from the window that requests snapping to the (root) pane that implements it: IslandWindow -> AppHost's callback -> App -> TerminalPage -> Tab -> Pane. I don't know if this can be done better. ## Validation Steps Performed Spam split pane buttons, randomly change font sizes with ctrl+mouse wheel and drag the window back and forth. Closes #2834 Closes #2277
2020-01-08 22:19:23 +01:00
case WM_SIZING:
{
return _OnSizing(wparam, lparam);
}
Hide `_quake` window on minimize ALWAYS (#10113) ## Summary of the Pull Request This is a scoped implementation of "hide on minimize", only to the `_quake` window. When minimized, the `_quake` window won't appear in the taskbar. IT ALSO WON'T APPEAR IN THE TRAY, BECAUSE WE DON'T HAVE ONE YET. I talked about this with @DHowett, and it seemed cool. Other windows will still minimize normally. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 * minimize to tray: #5727 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-61246940 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated - probably yea, but something <sub>something <sub>something</sub></sub> ## Detailed Description of the Pull Request / Additional comments After playing with it, it is in fact, cool. ALSO `LOG_IF_WIN32_BOOL_FALSE` should DEFINITELY not be used with `ShowWindow`. [`ShowWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-showwindow#return-value) returns false if the window was previously hidden, but doesn't `SetLastError`, so that macro will _throw_. ## Validation Steps Performed ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon", "name": "_quake" } }, // { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-18 12:44:42 +02:00
case WM_SIZE:
{
if (wparam == SIZE_MINIMIZED && _isQuakeWindow)
{
ShowWindow(GetHandle(), SW_HIDE);
return 0;
}
break;
}
Make the window name `_quake` special (#9785) ## Summary of the Pull Request This PR adds some special behavior to the window named "\_quake". * When creating the quake window, it ignores "initialRows" and "initialCols" and opens on the top half of the monitor. - It uses `initialPosition` to determine which monitor this is * It cannot be moved * It can only be vertically resized on the bottom border. * It's always in focus mode. - We should probably have an issue tracking "Allow showing tabs in focus mode"? Maybe? - This one element is maybe the one I'm least attached to When renaming a window to "\_quake", it adopts all those behaviors as well. It does not exit focus mode when leaving QM, nor does it resize back. That seemed unnecessary. ## References * As spec'ed in #9274 * See also #8888 ## PR Checklist * [x] In the pursuit of #653 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated, but I'm not gonna do any of that till quake mode is totally done. ## Detailed Description of the Pull Request / Additional comments Note that this doesn't do things like: * dropdown * global hotkey summon * summon to the current monitor * summon to the current desktop I'm doing #653 _very_ piecemeal, to try and make the PRs less egregious. ## Validation Steps Performed * validated that center on launch still works * validated that QM works on different monitors based on `initialPosition` * validated entering/exiting QM behaves as expected ## TODO! * [ ] When snapping the quake window between desktops with <kbd>win+shift+arrow</kbd>, the window doesn't horizontally re-size to the new monitor dimensions. It should.
2021-04-26 21:36:23 +02:00
case WM_MOVING:
{
return _OnMoving(wparam, lparam);
}
Manually dismiss popups when the window moves, or the SUI scrolls (#10922) ## Summary of the Pull Request BODGY! This solution was suggested in https://github.com/microsoft/microsoft-ui-xaml/issues/4554#issuecomment-887815332. When the window moves, or when a ScrollViewer scrolls, dismiss any popups that are visible. This happens automagically when an app is a real XAML app, but it doesn't work for XAML Islands. ## References * upstream at https://github.com/microsoft/microsoft-ui-xaml/issues/4554 ## PR Checklist * [x] Closes #9320 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments Unfortunately, we've got a bunch of scroll viewers in our SUI. So I did something bodgyx2 to make our life a little easier. `DismissAllPopups` can be used to dismiss all popups for a particular UI element. However, we've got a bunch of pages with scroll viewers that may or may not have popups in them. Rather than define the same exact body for all their `ViewChanging` events, the `HasScrollViewer` struct will just do it for you! Inside the `HasScrollViewer` stuct, we can't get at the `XamlRoot()` that our subclass implements. I mean, _we_ can, but when XAML does it's codegen, _XAML_ won't be able to figure it out. Fortunately for us, we don't need to! The sender is a UIElement, so we can just get _their_ `XamlRoot()`. So, you can fix this for any SUI page with just a simple ```diff - <ScrollViewer> + <ScrollViewer ViewChanging="ViewChanging"> ``` ```diff - struct AddProfile : AddProfileT<AddProfile> + struct AddProfile : public HasScrollViewer<AddProfile>, AddProfileT<AddProfile> ``` ## Validation Steps Performed * the window doesn't close when you move it * the popups _do_ close when you move the window * the popups close when you scroll any SUI page
2021-08-16 15:41:17 +02:00
case WM_MOVE:
{
_WindowMovedHandlers();
break;
}
case WM_CLOSE:
{
// If the user wants to close the app by clicking 'X' button,
// we hand off the close experience to the app layer. If all the tabs
// are closed, the window will be closed as well.
_windowCloseButtonClickedHandler();
return 0;
}
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
case WM_MOUSEWHEEL:
try
{
// This whole handler is a hack for GH#979.
//
// On some laptops, their trackpads won't scroll inactive windows
// _ever_. With our entire window just being one giant XAML Island, the
// touchpad driver thinks our entire window is inactive, and won't
// scroll the XAML island. On those types of laptops, we'll get a
// WM_MOUSEWHEEL here, in our root window, when the trackpad scrolls.
// We're going to take that message and manually plumb it through to our
// TermControl's, or anything else that implements IMouseWheelListener.
// https://msdn.microsoft.com/en-us/library/windows/desktop/ms645617(v=vs.85).aspx
// Important! Do not use the LOWORD or HIWORD macros to extract the x-
// and y- coordinates of the cursor position because these macros return
// incorrect results on systems with multiple monitors. Systems with
// multiple monitors can have negative x- and y- coordinates, and LOWORD
// and HIWORD treat the coordinates as unsigned quantities.
const til::point eventPoint{ GET_X_LPARAM(lparam), GET_Y_LPARAM(lparam) };
// This mouse event is relative to the display origin, not the window. Convert here.
const til::rectangle windowRect{ GetWindowRect() };
const auto origin = windowRect.origin();
const auto relative = eventPoint - origin;
// Convert to logical scaling before raising the event.
const auto real = relative / GetCurrentDpiScale();
const short wheelDelta = static_cast<short>(HIWORD(wparam));
// Raise an event, so any listeners can handle the mouse wheel event manually.
_MouseScrolledHandlers(real, wheelDelta);
return 0;
}
CATCH_LOG();
case WM_THEMECHANGED:
UpdateWindowIconForActiveMetrics(_window.get());
return 0;
case WM_WINDOWPOSCHANGING:
{
// GH#10274 - if the quake window gets moved to another monitor via aero
// snap (win+shift+arrows), then re-adjust the size for the new monitor.
if (IsQuakeWindow())
{
// Retrieve the suggested dimensions and make a rect and size.
LPWINDOWPOS lpwpos = (LPWINDOWPOS)lparam;
// We only need to apply restrictions if the position is changing.
// The SWP_ flags are confusing to read. This is
// "if we're not moving the window, do nothing."
if (WI_IsFlagSet(lpwpos->flags, SWP_NOMOVE))
{
break;
}
// Figure out the suggested dimensions and position.
RECT rcSuggested;
rcSuggested.left = lpwpos->x;
rcSuggested.top = lpwpos->y;
rcSuggested.right = rcSuggested.left + lpwpos->cx;
rcSuggested.bottom = rcSuggested.top + lpwpos->cy;
// Find the bounds of the current monitor, and the monitor that
// we're suggested to be on.
HMONITOR current = MonitorFromWindow(_window.get(), MONITOR_DEFAULTTONEAREST);
MONITORINFO currentInfo;
currentInfo.cbSize = sizeof(MONITORINFO);
GetMonitorInfo(current, &currentInfo);
HMONITOR proposed = MonitorFromRect(&rcSuggested, MONITOR_DEFAULTTONEAREST);
MONITORINFO proposedInfo;
proposedInfo.cbSize = sizeof(MONITORINFO);
GetMonitorInfo(proposed, &proposedInfo);
// If the monitor changed...
if (til::rectangle{ proposedInfo.rcMonitor } !=
til::rectangle{ currentInfo.rcMonitor })
{
const auto newWindowRect{ _getQuakeModeSize(proposed) };
// Inform User32 that we want to be placed at the position
// and dimensions that _getQuakeModeSize returned. When we
// snap across monitor boundaries, this will re-evaluate our
// size for the new monitor.
lpwpos->x = newWindowRect.left<int>();
lpwpos->y = newWindowRect.top<int>();
lpwpos->cx = newWindowRect.width<int>();
lpwpos->cy = newWindowRect.height<int>();
return 0;
}
}
}
case CM_NOTIFY_FROM_NOTIFICATION_AREA:
{
switch (LOWORD(lparam))
{
case NIN_SELECT:
case NIN_KEYSELECT:
{
_NotifyNotificationIconPressedHandlers();
return 0;
}
case WM_CONTEXTMENU:
{
const til::point eventPoint{ GET_X_LPARAM(wparam), GET_Y_LPARAM(wparam) };
_NotifyShowNotificationIconContextMenuHandlers(eventPoint);
return 0;
}
}
break;
}
case WM_SYSCOMMAND:
{
if (wparam == SC_RESTORE && _fullscreen)
{
_ShouldExitFullscreenHandlers();
return 0;
}
break;
}
case WM_MENUCOMMAND:
{
_NotifyNotificationIconMenuItemSelectedHandlers((HMENU)lparam, (UINT)wparam);
return 0;
}
case WM_SYSCOMMAND:
{
auto search = _systemMenuItems.find(LOWORD(wparam));
if (search != _systemMenuItems.end())
{
search->second.callback();
}
break;
}
default:
// We'll want to receive this message when explorer.exe restarts
// so that we can re-add our icon to the notification area.
// This unfortunately isn't a switch case because we register the
// message at runtime.
if (message == WM_TASKBARCREATED)
{
_NotifyReAddNotificationIconHandlers();
return 0;
}
}
// TODO: handle messages here...
return base_type::MessageHandler(message, wparam, lparam);
}
// Method Description:
// - Called when the window has been resized (or maximized)
// Arguments:
// - width: the new width of the window _in pixels_
// - height: the new height of the window _in pixels_
void IslandWindow::OnResize(const UINT width, const UINT height)
{
if (_interopWindowHandle)
{
OnSize(width, height);
}
}
// Method Description:
// - Called when the window is minimized to the taskbar.
void IslandWindow::OnMinimize()
{
Enable dragging with the entire titlebar (#1948) * This definitely works for getting shadow, pointy corners back Don't do anything in NCPAINT. If you do, you have to do everything. But the whole point of DwmExtendFrameIntoClientArea is to let you paint the NC area in your normal paint. So just do that dummy. * This doesn't transition across monitors. * This has a window style change I think is wrong. * I'm not sure the margins change is important. * The window style was _not_ important * Still getting a black xaml islands area (the HRGN) when we switch to high DPI * I don't know if this affects anything. * heyo this works. I'm not entirely sure why. But if we only update the titlebar drag region when that actually changes, it's a _lot_ smoother. I'm not super happy with the duplicated work in _UpdateDragRegion and OnSize, but checking this in in case I can't figure that out. * Add more comments and cleanup * Try making the button RightCustomContent * * Make the MinMaxClose's drag bar's min size the same as a caption button * Make the new tab button transparent, to see how that looks * Make sure the TabView doesn't push the MMC off the window * Create a TitlebarControl * The TitlebarControl is owned by the NCIW. It consists of a Content, DragBar, and MMCControl. * The App instatntiates a TabRowControl at runtime, and either places it in the UI (for tabs below titlebar) or hangs on to it, and gives it to the NCIW when the NCIW creates its UI. * When the NCIW is created, it creates a grid with two rows, one for the titlebar and one for the app content. * The MMCControl is only responsible for Min Max Close now, and is closer to the window implementation. * The drag bar takes up all the space from the right of the TabRow to the left of the MMC * Things that **DON'T** work: - When you add tabs, the drag bar doesn't update it's size. It only updates OnSize - The MMCControl's Min and Max buttons don't seem to work anymore. - They should probably just expose their OnMinimizeClick and OnMaximizeClick events for the Titlebar to handle minimizing and maximizing. - The drag bar is Magenta (#ff00ff) currently. - I'm not _sure_ we need a TabRowControl. We could probably get away with removing it from the UI tree, I was just being dumb before. * Fix the MMC buttons not working I forgot to plumb the window handle through * Make the titlebar less magenta * Resize the drag region as we add/remove tabs * Move the actual MMC handling to the TitlebarControl * Some PR nits, fix the titlebar painting on maximize * Put the TabRow in our XAML * Remove dead code in preparation for review * Horrifyingly try Gdi Plus as a solution, that is _wrong_ though * Revert "Horrifyingly try Gdi Plus as a solution, that is _wrong_ though" This reverts commit e038b5d9216c6710c2a7f81840d76f8130cd73b8. * This fixes the bottom border but breaks the titlebar painting * Fix the NC bottom border * A bunch of the more minor PR nits * Add a MinimizeClick event to the MMCControl This works for Minimize. This is what I wanted to do originally. * Add events for _all_ of the buttons, not just the Minimize btn * Change hoe setting the titlebar content works Now the app triggers a callcack on the host to set the content, instead of the host querying the app. * Move the tab row to the bottom of it's available space * Fix the theme reloading * PR nits from @miniksa * Update src/cascadia/WindowsTerminal/NonClientIslandWindow.cpp Co-Authored-By: Michael Niksa <miniksa@microsoft.com> * This needed to be fixed, was missed in other PR nits * runformat wait _what_ * Does this fix the CI build?
2019-07-19 00:21:33 +02:00
// TODO GH#1989 Stop rendering island content when the app is minimized.
if (_minimizeToNotificationArea)
{
HideWindow();
}
}
// Method Description:
// - Called when the window is restored from having been minimized.
void IslandWindow::OnRestore()
{
Enable dragging with the entire titlebar (#1948) * This definitely works for getting shadow, pointy corners back Don't do anything in NCPAINT. If you do, you have to do everything. But the whole point of DwmExtendFrameIntoClientArea is to let you paint the NC area in your normal paint. So just do that dummy. * This doesn't transition across monitors. * This has a window style change I think is wrong. * I'm not sure the margins change is important. * The window style was _not_ important * Still getting a black xaml islands area (the HRGN) when we switch to high DPI * I don't know if this affects anything. * heyo this works. I'm not entirely sure why. But if we only update the titlebar drag region when that actually changes, it's a _lot_ smoother. I'm not super happy with the duplicated work in _UpdateDragRegion and OnSize, but checking this in in case I can't figure that out. * Add more comments and cleanup * Try making the button RightCustomContent * * Make the MinMaxClose's drag bar's min size the same as a caption button * Make the new tab button transparent, to see how that looks * Make sure the TabView doesn't push the MMC off the window * Create a TitlebarControl * The TitlebarControl is owned by the NCIW. It consists of a Content, DragBar, and MMCControl. * The App instatntiates a TabRowControl at runtime, and either places it in the UI (for tabs below titlebar) or hangs on to it, and gives it to the NCIW when the NCIW creates its UI. * When the NCIW is created, it creates a grid with two rows, one for the titlebar and one for the app content. * The MMCControl is only responsible for Min Max Close now, and is closer to the window implementation. * The drag bar takes up all the space from the right of the TabRow to the left of the MMC * Things that **DON'T** work: - When you add tabs, the drag bar doesn't update it's size. It only updates OnSize - The MMCControl's Min and Max buttons don't seem to work anymore. - They should probably just expose their OnMinimizeClick and OnMaximizeClick events for the Titlebar to handle minimizing and maximizing. - The drag bar is Magenta (#ff00ff) currently. - I'm not _sure_ we need a TabRowControl. We could probably get away with removing it from the UI tree, I was just being dumb before. * Fix the MMC buttons not working I forgot to plumb the window handle through * Make the titlebar less magenta * Resize the drag region as we add/remove tabs * Move the actual MMC handling to the TitlebarControl * Some PR nits, fix the titlebar painting on maximize * Put the TabRow in our XAML * Remove dead code in preparation for review * Horrifyingly try Gdi Plus as a solution, that is _wrong_ though * Revert "Horrifyingly try Gdi Plus as a solution, that is _wrong_ though" This reverts commit e038b5d9216c6710c2a7f81840d76f8130cd73b8. * This fixes the bottom border but breaks the titlebar painting * Fix the NC bottom border * A bunch of the more minor PR nits * Add a MinimizeClick event to the MMCControl This works for Minimize. This is what I wanted to do originally. * Add events for _all_ of the buttons, not just the Minimize btn * Change hoe setting the titlebar content works Now the app triggers a callcack on the host to set the content, instead of the host querying the app. * Move the tab row to the bottom of it's available space * Fix the theme reloading * PR nits from @miniksa * Update src/cascadia/WindowsTerminal/NonClientIslandWindow.cpp Co-Authored-By: Michael Niksa <miniksa@microsoft.com> * This needed to be fixed, was missed in other PR nits * runformat wait _what_ * Does this fix the CI build?
2019-07-19 00:21:33 +02:00
// TODO GH#1989 Stop rendering island content when the app is minimized.
}
Enable dragging with the entire titlebar (#1948) * This definitely works for getting shadow, pointy corners back Don't do anything in NCPAINT. If you do, you have to do everything. But the whole point of DwmExtendFrameIntoClientArea is to let you paint the NC area in your normal paint. So just do that dummy. * This doesn't transition across monitors. * This has a window style change I think is wrong. * I'm not sure the margins change is important. * The window style was _not_ important * Still getting a black xaml islands area (the HRGN) when we switch to high DPI * I don't know if this affects anything. * heyo this works. I'm not entirely sure why. But if we only update the titlebar drag region when that actually changes, it's a _lot_ smoother. I'm not super happy with the duplicated work in _UpdateDragRegion and OnSize, but checking this in in case I can't figure that out. * Add more comments and cleanup * Try making the button RightCustomContent * * Make the MinMaxClose's drag bar's min size the same as a caption button * Make the new tab button transparent, to see how that looks * Make sure the TabView doesn't push the MMC off the window * Create a TitlebarControl * The TitlebarControl is owned by the NCIW. It consists of a Content, DragBar, and MMCControl. * The App instatntiates a TabRowControl at runtime, and either places it in the UI (for tabs below titlebar) or hangs on to it, and gives it to the NCIW when the NCIW creates its UI. * When the NCIW is created, it creates a grid with two rows, one for the titlebar and one for the app content. * The MMCControl is only responsible for Min Max Close now, and is closer to the window implementation. * The drag bar takes up all the space from the right of the TabRow to the left of the MMC * Things that **DON'T** work: - When you add tabs, the drag bar doesn't update it's size. It only updates OnSize - The MMCControl's Min and Max buttons don't seem to work anymore. - They should probably just expose their OnMinimizeClick and OnMaximizeClick events for the Titlebar to handle minimizing and maximizing. - The drag bar is Magenta (#ff00ff) currently. - I'm not _sure_ we need a TabRowControl. We could probably get away with removing it from the UI tree, I was just being dumb before. * Fix the MMC buttons not working I forgot to plumb the window handle through * Make the titlebar less magenta * Resize the drag region as we add/remove tabs * Move the actual MMC handling to the TitlebarControl * Some PR nits, fix the titlebar painting on maximize * Put the TabRow in our XAML * Remove dead code in preparation for review * Horrifyingly try Gdi Plus as a solution, that is _wrong_ though * Revert "Horrifyingly try Gdi Plus as a solution, that is _wrong_ though" This reverts commit e038b5d9216c6710c2a7f81840d76f8130cd73b8. * This fixes the bottom border but breaks the titlebar painting * Fix the NC bottom border * A bunch of the more minor PR nits * Add a MinimizeClick event to the MMCControl This works for Minimize. This is what I wanted to do originally. * Add events for _all_ of the buttons, not just the Minimize btn * Change hoe setting the titlebar content works Now the app triggers a callcack on the host to set the content, instead of the host querying the app. * Move the tab row to the bottom of it's available space * Fix the theme reloading * PR nits from @miniksa * Update src/cascadia/WindowsTerminal/NonClientIslandWindow.cpp Co-Authored-By: Michael Niksa <miniksa@microsoft.com> * This needed to be fixed, was missed in other PR nits * runformat wait _what_ * Does this fix the CI build?
2019-07-19 00:21:33 +02:00
void IslandWindow::SetContent(winrt::Windows::UI::Xaml::UIElement content)
{
_rootGrid.Children().Clear();
Enable dragging with the entire titlebar (#1948) * This definitely works for getting shadow, pointy corners back Don't do anything in NCPAINT. If you do, you have to do everything. But the whole point of DwmExtendFrameIntoClientArea is to let you paint the NC area in your normal paint. So just do that dummy. * This doesn't transition across monitors. * This has a window style change I think is wrong. * I'm not sure the margins change is important. * The window style was _not_ important * Still getting a black xaml islands area (the HRGN) when we switch to high DPI * I don't know if this affects anything. * heyo this works. I'm not entirely sure why. But if we only update the titlebar drag region when that actually changes, it's a _lot_ smoother. I'm not super happy with the duplicated work in _UpdateDragRegion and OnSize, but checking this in in case I can't figure that out. * Add more comments and cleanup * Try making the button RightCustomContent * * Make the MinMaxClose's drag bar's min size the same as a caption button * Make the new tab button transparent, to see how that looks * Make sure the TabView doesn't push the MMC off the window * Create a TitlebarControl * The TitlebarControl is owned by the NCIW. It consists of a Content, DragBar, and MMCControl. * The App instatntiates a TabRowControl at runtime, and either places it in the UI (for tabs below titlebar) or hangs on to it, and gives it to the NCIW when the NCIW creates its UI. * When the NCIW is created, it creates a grid with two rows, one for the titlebar and one for the app content. * The MMCControl is only responsible for Min Max Close now, and is closer to the window implementation. * The drag bar takes up all the space from the right of the TabRow to the left of the MMC * Things that **DON'T** work: - When you add tabs, the drag bar doesn't update it's size. It only updates OnSize - The MMCControl's Min and Max buttons don't seem to work anymore. - They should probably just expose their OnMinimizeClick and OnMaximizeClick events for the Titlebar to handle minimizing and maximizing. - The drag bar is Magenta (#ff00ff) currently. - I'm not _sure_ we need a TabRowControl. We could probably get away with removing it from the UI tree, I was just being dumb before. * Fix the MMC buttons not working I forgot to plumb the window handle through * Make the titlebar less magenta * Resize the drag region as we add/remove tabs * Move the actual MMC handling to the TitlebarControl * Some PR nits, fix the titlebar painting on maximize * Put the TabRow in our XAML * Remove dead code in preparation for review * Horrifyingly try Gdi Plus as a solution, that is _wrong_ though * Revert "Horrifyingly try Gdi Plus as a solution, that is _wrong_ though" This reverts commit e038b5d9216c6710c2a7f81840d76f8130cd73b8. * This fixes the bottom border but breaks the titlebar painting * Fix the NC bottom border * A bunch of the more minor PR nits * Add a MinimizeClick event to the MMCControl This works for Minimize. This is what I wanted to do originally. * Add events for _all_ of the buttons, not just the Minimize btn * Change hoe setting the titlebar content works Now the app triggers a callcack on the host to set the content, instead of the host querying the app. * Move the tab row to the bottom of it's available space * Fix the theme reloading * PR nits from @miniksa * Update src/cascadia/WindowsTerminal/NonClientIslandWindow.cpp Co-Authored-By: Michael Niksa <miniksa@microsoft.com> * This needed to be fixed, was missed in other PR nits * runformat wait _what_ * Does this fix the CI build?
2019-07-19 00:21:33 +02:00
_rootGrid.Children().Append(content);
}
Snap to character grid when resizing window (#3181) When user resizes window, snap the size to align with the character grid (like e.g. putty, mintty and most unix terminals). Properly resolves arbitrary pane configuration (even with different font sizes and padding) trying to align each pane as close as possible. It also fixes terminal minimum size enforcement which was not quite well handled, especially with multiple panes. This PR does not however try to keep the terminals aligned at other user actions (e.g. font change or pane split). That is to be tracked by some other activity. Snapping is resolved in the pane tree, recursively, so it (hopefully) works for any possible layout. Along the way I had to clean up some things as so to make the resulting code not so cumbersome: 1. Pane.cpp: Replaced _firstPercent and _secondPercent with single _desiredSplitPosition to reduce invariants - these had to be kept in sync so their sum always gives 1 (and were not really a percent). The desired part refers to fact that since panes are aligned, there is usually some deviation from that ratio. 2. Pane.cpp: Fixed _GetMinSize() - it was improperly accounting for split direction 3. TerminalControl: Made dedicated member for padding instead of reading it from a control itself. This is because the winrt property functions turned out to be slow and this algorithm needs to access it many times. I also cached scrollbar width for the same reason. 4. AppHost: Moved window to client size resolution to virtual method, where IslandWindow and NonClientIslandWindow have their own implementations (as opposite to pointer casting). One problem with current implementation is I had to make a long call chain from the window that requests snapping to the (root) pane that implements it: IslandWindow -> AppHost's callback -> App -> TerminalPage -> Tab -> Pane. I don't know if this can be done better. ## Validation Steps Performed Spam split pane buttons, randomly change font sizes with ctrl+mouse wheel and drag the window back and forth. Closes #2834 Closes #2277
2020-01-08 22:19:23 +01:00
// Method Description:
// - Get the dimensions of our non-client area, as a rect where each component
// represents that side.
// - The .left will be a negative number, to represent that the actual side of
// the non-client area is outside the border of our window. It's roughly 8px (
// * DPI scaling) to the left of the visible border.
// - The .right component will be positive, indicating that the nonclient border
// is in the positive-x direction from the edge of our client area.
// - This will also include our titlebar! It's in the nonclient area for us.
Snap to character grid when resizing window (#3181) When user resizes window, snap the size to align with the character grid (like e.g. putty, mintty and most unix terminals). Properly resolves arbitrary pane configuration (even with different font sizes and padding) trying to align each pane as close as possible. It also fixes terminal minimum size enforcement which was not quite well handled, especially with multiple panes. This PR does not however try to keep the terminals aligned at other user actions (e.g. font change or pane split). That is to be tracked by some other activity. Snapping is resolved in the pane tree, recursively, so it (hopefully) works for any possible layout. Along the way I had to clean up some things as so to make the resulting code not so cumbersome: 1. Pane.cpp: Replaced _firstPercent and _secondPercent with single _desiredSplitPosition to reduce invariants - these had to be kept in sync so their sum always gives 1 (and were not really a percent). The desired part refers to fact that since panes are aligned, there is usually some deviation from that ratio. 2. Pane.cpp: Fixed _GetMinSize() - it was improperly accounting for split direction 3. TerminalControl: Made dedicated member for padding instead of reading it from a control itself. This is because the winrt property functions turned out to be slow and this algorithm needs to access it many times. I also cached scrollbar width for the same reason. 4. AppHost: Moved window to client size resolution to virtual method, where IslandWindow and NonClientIslandWindow have their own implementations (as opposite to pointer casting). One problem with current implementation is I had to make a long call chain from the window that requests snapping to the (root) pane that implements it: IslandWindow -> AppHost's callback -> App -> TerminalPage -> Tab -> Pane. I don't know if this can be done better. ## Validation Steps Performed Spam split pane buttons, randomly change font sizes with ctrl+mouse wheel and drag the window back and forth. Closes #2834 Closes #2277
2020-01-08 22:19:23 +01:00
// Arguments:
// - dpi: the scaling that we should use to calculate the border sizes.
// Return Value:
// - a RECT whose components represent the margins of the nonclient area,
// relative to the client area.
RECT IslandWindow::GetNonClientFrame(const UINT dpi) const noexcept
Snap to character grid when resizing window (#3181) When user resizes window, snap the size to align with the character grid (like e.g. putty, mintty and most unix terminals). Properly resolves arbitrary pane configuration (even with different font sizes and padding) trying to align each pane as close as possible. It also fixes terminal minimum size enforcement which was not quite well handled, especially with multiple panes. This PR does not however try to keep the terminals aligned at other user actions (e.g. font change or pane split). That is to be tracked by some other activity. Snapping is resolved in the pane tree, recursively, so it (hopefully) works for any possible layout. Along the way I had to clean up some things as so to make the resulting code not so cumbersome: 1. Pane.cpp: Replaced _firstPercent and _secondPercent with single _desiredSplitPosition to reduce invariants - these had to be kept in sync so their sum always gives 1 (and were not really a percent). The desired part refers to fact that since panes are aligned, there is usually some deviation from that ratio. 2. Pane.cpp: Fixed _GetMinSize() - it was improperly accounting for split direction 3. TerminalControl: Made dedicated member for padding instead of reading it from a control itself. This is because the winrt property functions turned out to be slow and this algorithm needs to access it many times. I also cached scrollbar width for the same reason. 4. AppHost: Moved window to client size resolution to virtual method, where IslandWindow and NonClientIslandWindow have their own implementations (as opposite to pointer casting). One problem with current implementation is I had to make a long call chain from the window that requests snapping to the (root) pane that implements it: IslandWindow -> AppHost's callback -> App -> TerminalPage -> Tab -> Pane. I don't know if this can be done better. ## Validation Steps Performed Spam split pane buttons, randomly change font sizes with ctrl+mouse wheel and drag the window back and forth. Closes #2834 Closes #2277
2020-01-08 22:19:23 +01:00
{
const auto windowStyle = static_cast<DWORD>(GetWindowLong(_window.get(), GWL_STYLE));
RECT islandFrame{};
// If we failed to get the correct window size for whatever reason, log
// the error and go on. We'll use whatever the control proposed as the
// size of our window, which will be at least close.
LOG_IF_WIN32_BOOL_FALSE(AdjustWindowRectExForDpi(&islandFrame, windowStyle, false, 0, dpi));
return islandFrame;
}
Snap to character grid when resizing window (#3181) When user resizes window, snap the size to align with the character grid (like e.g. putty, mintty and most unix terminals). Properly resolves arbitrary pane configuration (even with different font sizes and padding) trying to align each pane as close as possible. It also fixes terminal minimum size enforcement which was not quite well handled, especially with multiple panes. This PR does not however try to keep the terminals aligned at other user actions (e.g. font change or pane split). That is to be tracked by some other activity. Snapping is resolved in the pane tree, recursively, so it (hopefully) works for any possible layout. Along the way I had to clean up some things as so to make the resulting code not so cumbersome: 1. Pane.cpp: Replaced _firstPercent and _secondPercent with single _desiredSplitPosition to reduce invariants - these had to be kept in sync so their sum always gives 1 (and were not really a percent). The desired part refers to fact that since panes are aligned, there is usually some deviation from that ratio. 2. Pane.cpp: Fixed _GetMinSize() - it was improperly accounting for split direction 3. TerminalControl: Made dedicated member for padding instead of reading it from a control itself. This is because the winrt property functions turned out to be slow and this algorithm needs to access it many times. I also cached scrollbar width for the same reason. 4. AppHost: Moved window to client size resolution to virtual method, where IslandWindow and NonClientIslandWindow have their own implementations (as opposite to pointer casting). One problem with current implementation is I had to make a long call chain from the window that requests snapping to the (root) pane that implements it: IslandWindow -> AppHost's callback -> App -> TerminalPage -> Tab -> Pane. I don't know if this can be done better. ## Validation Steps Performed Spam split pane buttons, randomly change font sizes with ctrl+mouse wheel and drag the window back and forth. Closes #2834 Closes #2277
2020-01-08 22:19:23 +01:00
// Method Description:
// - Gets the difference between window and client area size.
// Arguments:
// - dpi: dpi of a monitor on which the window is placed
// Return Value
// - The size difference
SIZE IslandWindow::GetTotalNonClientExclusiveSize(const UINT dpi) const noexcept
{
const auto islandFrame{ GetNonClientFrame(dpi) };
Snap to character grid when resizing window (#3181) When user resizes window, snap the size to align with the character grid (like e.g. putty, mintty and most unix terminals). Properly resolves arbitrary pane configuration (even with different font sizes and padding) trying to align each pane as close as possible. It also fixes terminal minimum size enforcement which was not quite well handled, especially with multiple panes. This PR does not however try to keep the terminals aligned at other user actions (e.g. font change or pane split). That is to be tracked by some other activity. Snapping is resolved in the pane tree, recursively, so it (hopefully) works for any possible layout. Along the way I had to clean up some things as so to make the resulting code not so cumbersome: 1. Pane.cpp: Replaced _firstPercent and _secondPercent with single _desiredSplitPosition to reduce invariants - these had to be kept in sync so their sum always gives 1 (and were not really a percent). The desired part refers to fact that since panes are aligned, there is usually some deviation from that ratio. 2. Pane.cpp: Fixed _GetMinSize() - it was improperly accounting for split direction 3. TerminalControl: Made dedicated member for padding instead of reading it from a control itself. This is because the winrt property functions turned out to be slow and this algorithm needs to access it many times. I also cached scrollbar width for the same reason. 4. AppHost: Moved window to client size resolution to virtual method, where IslandWindow and NonClientIslandWindow have their own implementations (as opposite to pointer casting). One problem with current implementation is I had to make a long call chain from the window that requests snapping to the (root) pane that implements it: IslandWindow -> AppHost's callback -> App -> TerminalPage -> Tab -> Pane. I don't know if this can be done better. ## Validation Steps Performed Spam split pane buttons, randomly change font sizes with ctrl+mouse wheel and drag the window back and forth. Closes #2834 Closes #2277
2020-01-08 22:19:23 +01:00
return {
islandFrame.right - islandFrame.left,
islandFrame.bottom - islandFrame.top
};
}
Enable dragging with the entire titlebar (#1948) * This definitely works for getting shadow, pointy corners back Don't do anything in NCPAINT. If you do, you have to do everything. But the whole point of DwmExtendFrameIntoClientArea is to let you paint the NC area in your normal paint. So just do that dummy. * This doesn't transition across monitors. * This has a window style change I think is wrong. * I'm not sure the margins change is important. * The window style was _not_ important * Still getting a black xaml islands area (the HRGN) when we switch to high DPI * I don't know if this affects anything. * heyo this works. I'm not entirely sure why. But if we only update the titlebar drag region when that actually changes, it's a _lot_ smoother. I'm not super happy with the duplicated work in _UpdateDragRegion and OnSize, but checking this in in case I can't figure that out. * Add more comments and cleanup * Try making the button RightCustomContent * * Make the MinMaxClose's drag bar's min size the same as a caption button * Make the new tab button transparent, to see how that looks * Make sure the TabView doesn't push the MMC off the window * Create a TitlebarControl * The TitlebarControl is owned by the NCIW. It consists of a Content, DragBar, and MMCControl. * The App instatntiates a TabRowControl at runtime, and either places it in the UI (for tabs below titlebar) or hangs on to it, and gives it to the NCIW when the NCIW creates its UI. * When the NCIW is created, it creates a grid with two rows, one for the titlebar and one for the app content. * The MMCControl is only responsible for Min Max Close now, and is closer to the window implementation. * The drag bar takes up all the space from the right of the TabRow to the left of the MMC * Things that **DON'T** work: - When you add tabs, the drag bar doesn't update it's size. It only updates OnSize - The MMCControl's Min and Max buttons don't seem to work anymore. - They should probably just expose their OnMinimizeClick and OnMaximizeClick events for the Titlebar to handle minimizing and maximizing. - The drag bar is Magenta (#ff00ff) currently. - I'm not _sure_ we need a TabRowControl. We could probably get away with removing it from the UI tree, I was just being dumb before. * Fix the MMC buttons not working I forgot to plumb the window handle through * Make the titlebar less magenta * Resize the drag region as we add/remove tabs * Move the actual MMC handling to the TitlebarControl * Some PR nits, fix the titlebar painting on maximize * Put the TabRow in our XAML * Remove dead code in preparation for review * Horrifyingly try Gdi Plus as a solution, that is _wrong_ though * Revert "Horrifyingly try Gdi Plus as a solution, that is _wrong_ though" This reverts commit e038b5d9216c6710c2a7f81840d76f8130cd73b8. * This fixes the bottom border but breaks the titlebar painting * Fix the NC bottom border * A bunch of the more minor PR nits * Add a MinimizeClick event to the MMCControl This works for Minimize. This is what I wanted to do originally. * Add events for _all_ of the buttons, not just the Minimize btn * Change hoe setting the titlebar content works Now the app triggers a callcack on the host to set the content, instead of the host querying the app. * Move the tab row to the bottom of it's available space * Fix the theme reloading * PR nits from @miniksa * Update src/cascadia/WindowsTerminal/NonClientIslandWindow.cpp Co-Authored-By: Michael Niksa <miniksa@microsoft.com> * This needed to be fixed, was missed in other PR nits * runformat wait _what_ * Does this fix the CI build?
2019-07-19 00:21:33 +02:00
void IslandWindow::OnAppInitialized()
{
// Do a quick resize to force the island to paint
const auto size = GetPhysicalSize();
OnSize(size.cx, size.cy);
}
Enable dragging with the entire titlebar (#1948) * This definitely works for getting shadow, pointy corners back Don't do anything in NCPAINT. If you do, you have to do everything. But the whole point of DwmExtendFrameIntoClientArea is to let you paint the NC area in your normal paint. So just do that dummy. * This doesn't transition across monitors. * This has a window style change I think is wrong. * I'm not sure the margins change is important. * The window style was _not_ important * Still getting a black xaml islands area (the HRGN) when we switch to high DPI * I don't know if this affects anything. * heyo this works. I'm not entirely sure why. But if we only update the titlebar drag region when that actually changes, it's a _lot_ smoother. I'm not super happy with the duplicated work in _UpdateDragRegion and OnSize, but checking this in in case I can't figure that out. * Add more comments and cleanup * Try making the button RightCustomContent * * Make the MinMaxClose's drag bar's min size the same as a caption button * Make the new tab button transparent, to see how that looks * Make sure the TabView doesn't push the MMC off the window * Create a TitlebarControl * The TitlebarControl is owned by the NCIW. It consists of a Content, DragBar, and MMCControl. * The App instatntiates a TabRowControl at runtime, and either places it in the UI (for tabs below titlebar) or hangs on to it, and gives it to the NCIW when the NCIW creates its UI. * When the NCIW is created, it creates a grid with two rows, one for the titlebar and one for the app content. * The MMCControl is only responsible for Min Max Close now, and is closer to the window implementation. * The drag bar takes up all the space from the right of the TabRow to the left of the MMC * Things that **DON'T** work: - When you add tabs, the drag bar doesn't update it's size. It only updates OnSize - The MMCControl's Min and Max buttons don't seem to work anymore. - They should probably just expose their OnMinimizeClick and OnMaximizeClick events for the Titlebar to handle minimizing and maximizing. - The drag bar is Magenta (#ff00ff) currently. - I'm not _sure_ we need a TabRowControl. We could probably get away with removing it from the UI tree, I was just being dumb before. * Fix the MMC buttons not working I forgot to plumb the window handle through * Make the titlebar less magenta * Resize the drag region as we add/remove tabs * Move the actual MMC handling to the TitlebarControl * Some PR nits, fix the titlebar painting on maximize * Put the TabRow in our XAML * Remove dead code in preparation for review * Horrifyingly try Gdi Plus as a solution, that is _wrong_ though * Revert "Horrifyingly try Gdi Plus as a solution, that is _wrong_ though" This reverts commit e038b5d9216c6710c2a7f81840d76f8130cd73b8. * This fixes the bottom border but breaks the titlebar painting * Fix the NC bottom border * A bunch of the more minor PR nits * Add a MinimizeClick event to the MMCControl This works for Minimize. This is what I wanted to do originally. * Add events for _all_ of the buttons, not just the Minimize btn * Change hoe setting the titlebar content works Now the app triggers a callcack on the host to set the content, instead of the host querying the app. * Move the tab row to the bottom of it's available space * Fix the theme reloading * PR nits from @miniksa * Update src/cascadia/WindowsTerminal/NonClientIslandWindow.cpp Co-Authored-By: Michael Niksa <miniksa@microsoft.com> * This needed to be fixed, was missed in other PR nits * runformat wait _what_ * Does this fix the CI build?
2019-07-19 00:21:33 +02:00
// Method Description:
// - Called when the app wants to change its theme. We'll update the root UI
// element of the entire XAML tree, so that all UI elements get the theme
// applied.
// Arguments:
// - arg: the ElementTheme to use as the new theme for the UI
// Return Value:
// - <none>
void IslandWindow::OnApplicationThemeChanged(const winrt::Windows::UI::Xaml::ElementTheme& requestedTheme)
Enable dragging with the entire titlebar (#1948) * This definitely works for getting shadow, pointy corners back Don't do anything in NCPAINT. If you do, you have to do everything. But the whole point of DwmExtendFrameIntoClientArea is to let you paint the NC area in your normal paint. So just do that dummy. * This doesn't transition across monitors. * This has a window style change I think is wrong. * I'm not sure the margins change is important. * The window style was _not_ important * Still getting a black xaml islands area (the HRGN) when we switch to high DPI * I don't know if this affects anything. * heyo this works. I'm not entirely sure why. But if we only update the titlebar drag region when that actually changes, it's a _lot_ smoother. I'm not super happy with the duplicated work in _UpdateDragRegion and OnSize, but checking this in in case I can't figure that out. * Add more comments and cleanup * Try making the button RightCustomContent * * Make the MinMaxClose's drag bar's min size the same as a caption button * Make the new tab button transparent, to see how that looks * Make sure the TabView doesn't push the MMC off the window * Create a TitlebarControl * The TitlebarControl is owned by the NCIW. It consists of a Content, DragBar, and MMCControl. * The App instatntiates a TabRowControl at runtime, and either places it in the UI (for tabs below titlebar) or hangs on to it, and gives it to the NCIW when the NCIW creates its UI. * When the NCIW is created, it creates a grid with two rows, one for the titlebar and one for the app content. * The MMCControl is only responsible for Min Max Close now, and is closer to the window implementation. * The drag bar takes up all the space from the right of the TabRow to the left of the MMC * Things that **DON'T** work: - When you add tabs, the drag bar doesn't update it's size. It only updates OnSize - The MMCControl's Min and Max buttons don't seem to work anymore. - They should probably just expose their OnMinimizeClick and OnMaximizeClick events for the Titlebar to handle minimizing and maximizing. - The drag bar is Magenta (#ff00ff) currently. - I'm not _sure_ we need a TabRowControl. We could probably get away with removing it from the UI tree, I was just being dumb before. * Fix the MMC buttons not working I forgot to plumb the window handle through * Make the titlebar less magenta * Resize the drag region as we add/remove tabs * Move the actual MMC handling to the TitlebarControl * Some PR nits, fix the titlebar painting on maximize * Put the TabRow in our XAML * Remove dead code in preparation for review * Horrifyingly try Gdi Plus as a solution, that is _wrong_ though * Revert "Horrifyingly try Gdi Plus as a solution, that is _wrong_ though" This reverts commit e038b5d9216c6710c2a7f81840d76f8130cd73b8. * This fixes the bottom border but breaks the titlebar painting * Fix the NC bottom border * A bunch of the more minor PR nits * Add a MinimizeClick event to the MMCControl This works for Minimize. This is what I wanted to do originally. * Add events for _all_ of the buttons, not just the Minimize btn * Change hoe setting the titlebar content works Now the app triggers a callcack on the host to set the content, instead of the host querying the app. * Move the tab row to the bottom of it's available space * Fix the theme reloading * PR nits from @miniksa * Update src/cascadia/WindowsTerminal/NonClientIslandWindow.cpp Co-Authored-By: Michael Niksa <miniksa@microsoft.com> * This needed to be fixed, was missed in other PR nits * runformat wait _what_ * Does this fix the CI build?
2019-07-19 00:21:33 +02:00
{
_rootGrid.RequestedTheme(requestedTheme);
// Invalidate the window rect, so that we'll repaint any elements we're
// drawing ourselves to match the new theme
::InvalidateRect(_window.get(), nullptr, false);
}
// Method Description:
// - Updates our focus mode state. See _SetIsBorderless for more details.
// Arguments:
// - <none>
// Return Value:
// - <none>
void IslandWindow::FocusModeChanged(const bool focusMode)
{
// Do nothing if the value was unchanged.
if (focusMode == _borderless)
{
return;
}
_SetIsBorderless(focusMode);
}
Enable fullscreen mode (#3408) ## Summary of the Pull Request Enables the `toggleFullscreen` action to be able to enter fullscreen mode, bound by default to <kbd>alt+enter</kbd>. The action is bubbled up to the WindowsTerminal (Win32) layer, where the window resizes itself to take the entire size of the monitor. This largely reuses code from conhost. Conhost already had a fullscreen mode, so I figured I might as well re-use that. ## References Unfortunately there are still very thin borders around the window when the NonClientIslandWindow is fullscreened. I think I know where the problem is. However, that area of code is about to get a massive overhaul with #3064, so I didn't want to necessarily make it worse right now. A follow up should be filed to add support for "Always show / reveal / never show tabs in fullscreen mode". Currently, the only mode is "never show tabs". Additionally, some of this code (particularily re:drawing the nonclient area) could be re-used for #2238. ## PR Checklist * [x] Closes #531, #3411 * [x] I work here * [n/a] Tests added/passed 😭 * [x] Requires documentation to be updated ## Validation Steps Performed * Manually tested both the NonClientIslandWindow and the IslandWindow. * Cherry-pick commit 8e56bfe * Don't draw the tab strip when maximized (cherry picked from commit bac4be7c0f3ed1cdcd4f9ae8980fc98103538613) * Fix the vista window flash for the NCIW (cherry picked from commit 7d3a18a893c02bd2ed75026f2aac52e20321a1cf) * Some code cleanup for review (cherry picked from commit 9e22b7730bba426adcbfd9e7025f192dbf8efb32) * A tad bit more notes and cleanup * Update schema, docs * Most of the PR comments * I'm not sure this actually works, so I'm committing it to revert it and check * Update some comments that were lost. * Fix a build break? * oh no
2019-11-05 20:40:29 +01:00
// Method Description:
// - Updates our fullscreen state. See _SetIsFullscreen for more details.
Enable fullscreen mode (#3408) ## Summary of the Pull Request Enables the `toggleFullscreen` action to be able to enter fullscreen mode, bound by default to <kbd>alt+enter</kbd>. The action is bubbled up to the WindowsTerminal (Win32) layer, where the window resizes itself to take the entire size of the monitor. This largely reuses code from conhost. Conhost already had a fullscreen mode, so I figured I might as well re-use that. ## References Unfortunately there are still very thin borders around the window when the NonClientIslandWindow is fullscreened. I think I know where the problem is. However, that area of code is about to get a massive overhaul with #3064, so I didn't want to necessarily make it worse right now. A follow up should be filed to add support for "Always show / reveal / never show tabs in fullscreen mode". Currently, the only mode is "never show tabs". Additionally, some of this code (particularily re:drawing the nonclient area) could be re-used for #2238. ## PR Checklist * [x] Closes #531, #3411 * [x] I work here * [n/a] Tests added/passed 😭 * [x] Requires documentation to be updated ## Validation Steps Performed * Manually tested both the NonClientIslandWindow and the IslandWindow. * Cherry-pick commit 8e56bfe * Don't draw the tab strip when maximized (cherry picked from commit bac4be7c0f3ed1cdcd4f9ae8980fc98103538613) * Fix the vista window flash for the NCIW (cherry picked from commit 7d3a18a893c02bd2ed75026f2aac52e20321a1cf) * Some code cleanup for review (cherry picked from commit 9e22b7730bba426adcbfd9e7025f192dbf8efb32) * A tad bit more notes and cleanup * Update schema, docs * Most of the PR comments * I'm not sure this actually works, so I'm committing it to revert it and check * Update some comments that were lost. * Fix a build break? * oh no
2019-11-05 20:40:29 +01:00
// Arguments:
// - <none>
// Return Value:
// - <none>
void IslandWindow::FullscreenChanged(const bool fullscreen)
{
// Do nothing if the value was unchanged.
if (fullscreen == _fullscreen)
{
return;
}
_SetIsFullscreen(fullscreen);
}
// Method Description:
// - Enter or exit the "always on top" state. Before the window is created, this
// value will later be used when we create the window to create the window on
// top of all others. After the window is created, it will either enter the
// group of topmost windows, or exit the group of topmost windows.
// Arguments:
// - alwaysOnTop: whether we should be entering or exiting always on top mode.
// Return Value:
// - <none>
void IslandWindow::SetAlwaysOnTop(const bool alwaysOnTop)
Enable fullscreen mode (#3408) ## Summary of the Pull Request Enables the `toggleFullscreen` action to be able to enter fullscreen mode, bound by default to <kbd>alt+enter</kbd>. The action is bubbled up to the WindowsTerminal (Win32) layer, where the window resizes itself to take the entire size of the monitor. This largely reuses code from conhost. Conhost already had a fullscreen mode, so I figured I might as well re-use that. ## References Unfortunately there are still very thin borders around the window when the NonClientIslandWindow is fullscreened. I think I know where the problem is. However, that area of code is about to get a massive overhaul with #3064, so I didn't want to necessarily make it worse right now. A follow up should be filed to add support for "Always show / reveal / never show tabs in fullscreen mode". Currently, the only mode is "never show tabs". Additionally, some of this code (particularily re:drawing the nonclient area) could be re-used for #2238. ## PR Checklist * [x] Closes #531, #3411 * [x] I work here * [n/a] Tests added/passed 😭 * [x] Requires documentation to be updated ## Validation Steps Performed * Manually tested both the NonClientIslandWindow and the IslandWindow. * Cherry-pick commit 8e56bfe * Don't draw the tab strip when maximized (cherry picked from commit bac4be7c0f3ed1cdcd4f9ae8980fc98103538613) * Fix the vista window flash for the NCIW (cherry picked from commit 7d3a18a893c02bd2ed75026f2aac52e20321a1cf) * Some code cleanup for review (cherry picked from commit 9e22b7730bba426adcbfd9e7025f192dbf8efb32) * A tad bit more notes and cleanup * Update schema, docs * Most of the PR comments * I'm not sure this actually works, so I'm committing it to revert it and check * Update some comments that were lost. * Fix a build break? * oh no
2019-11-05 20:40:29 +01:00
{
_alwaysOnTop = alwaysOnTop;
const auto hwnd = GetHandle();
if (hwnd)
{
SetWindowPos(hwnd,
_alwaysOnTop ? HWND_TOPMOST : HWND_NOTOPMOST,
0, // the window dimensions are unused, because we're passing SWP_NOSIZE
0,
0,
0,
SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE);
}
Enable fullscreen mode (#3408) ## Summary of the Pull Request Enables the `toggleFullscreen` action to be able to enter fullscreen mode, bound by default to <kbd>alt+enter</kbd>. The action is bubbled up to the WindowsTerminal (Win32) layer, where the window resizes itself to take the entire size of the monitor. This largely reuses code from conhost. Conhost already had a fullscreen mode, so I figured I might as well re-use that. ## References Unfortunately there are still very thin borders around the window when the NonClientIslandWindow is fullscreened. I think I know where the problem is. However, that area of code is about to get a massive overhaul with #3064, so I didn't want to necessarily make it worse right now. A follow up should be filed to add support for "Always show / reveal / never show tabs in fullscreen mode". Currently, the only mode is "never show tabs". Additionally, some of this code (particularily re:drawing the nonclient area) could be re-used for #2238. ## PR Checklist * [x] Closes #531, #3411 * [x] I work here * [n/a] Tests added/passed 😭 * [x] Requires documentation to be updated ## Validation Steps Performed * Manually tested both the NonClientIslandWindow and the IslandWindow. * Cherry-pick commit 8e56bfe * Don't draw the tab strip when maximized (cherry picked from commit bac4be7c0f3ed1cdcd4f9ae8980fc98103538613) * Fix the vista window flash for the NCIW (cherry picked from commit 7d3a18a893c02bd2ed75026f2aac52e20321a1cf) * Some code cleanup for review (cherry picked from commit 9e22b7730bba426adcbfd9e7025f192dbf8efb32) * A tad bit more notes and cleanup * Update schema, docs * Most of the PR comments * I'm not sure this actually works, so I'm committing it to revert it and check * Update some comments that were lost. * Fix a build break? * oh no
2019-11-05 20:40:29 +01:00
}
// Method Description
// - Flash the taskbar icon, indicating to the user that something needs their attention
void IslandWindow::FlashTaskbar()
{
// Using 'false' as the boolean argument ensures that the taskbar is
// only flashed if the app window is not focused
FlashWindow(_window.get(), false);
}
// Method Description:
// - Sets the taskbar progress indicator
// - We follow the ConEmu style for the state and progress values,
// more details at https://conemu.github.io/en/AnsiEscapeCodes.html#ConEmu_specific_OSC
// Arguments:
// - state: indicates the progress state
// - progress: indicates the progress value
void IslandWindow::SetTaskbarProgress(const size_t state, const size_t progress)
{
if (_taskbar)
{
switch (state)
{
case 0:
// removes the taskbar progress indicator
_taskbar->SetProgressState(_window.get(), TBPF_NOPROGRESS);
break;
case 1:
// sets the progress value to value given by the 'progress' parameter
_taskbar->SetProgressState(_window.get(), TBPF_NORMAL);
_taskbar->SetProgressValue(_window.get(), progress, 100);
break;
case 2:
// sets the progress indicator to an error state
_taskbar->SetProgressState(_window.get(), TBPF_ERROR);
_taskbar->SetProgressValue(_window.get(), progress, 100);
break;
case 3:
Combine progress states in the tab, taskbar (#10755) ## Summary of the Pull Request ![background-progress-000](https://user-images.githubusercontent.com/18356694/126653006-3ad2fdae-67ae-4cdb-aa46-25d09217e365.gif) This PR causes the Terminal to combine taskbar states at the tab and window level, according to the [MSDN docs for `SetProgressState`](https://docs.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-itaskbarlist3-setprogressstate#how-the-taskbar-button-chooses-the-progress-indicator-for-a-group). This allows the Terminal's taskbar icon to continue showing progress information, even if you're in a pane/tab that _doesn't_ have progress state. This is helpful for cases where the user may be running a build in one tab, and working on something else in another. ## References * [`SetProgressState`](https://docs.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-itaskbarlist3-setprogressstate#how-the-taskbar-button-chooses-the-progress-indicator-for-a-group) * Progress mega: #6700 ## PR Checklist * [x] Closes #10090 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This also fixes a related bug where transitioning from the "error" or "warning" state directly to the "indeterminate" state would cause the taskbar icon to get stuck in a bad state. ## Validation Steps Performed <details> <summary><code>progress.cmd</code></summary> ```cmd @echo off setlocal enabledelayedexpansion set _type=3 if (%1) == () ( set _type=3 ) else ( set _type=%1 ) if (%_type%) == (0) ( <NUL set /p =]9;4 echo Cleared progress ) if (%_type%) == (1) ( <NUL set /p =]9;4;1;25 echo Started progress (normal, 25^) ) if (%_type%) == (2) ( <NUL set /p =]9;4;2;50 echo Started progress (error, 50^) ) if (%_type%) == (3) ( @rem start indeterminate progress in the taskbar @rem this `<NUL set /p =` magic will output the text _without a newline_ <NUL set /p =]9;4;3 echo Started progress (indeterminate, {omitted}) ) if (%_type%) == (4) ( <NUL set /p =]9;4;4;75 echo Started progress (warning, 75^) ) ``` </details>
2021-08-10 13:16:17 +02:00
// sets the progress indicator to an indeterminate state.
// FIRST, set the progress to "no progress". That'll clear out any
// progress value from the previous state. Otherwise, a transition
// from (error,x%) or (warning,x%) to indeterminate will leave the
// progress value unchanged, and not show the spinner.
_taskbar->SetProgressState(_window.get(), TBPF_NOPROGRESS);
_taskbar->SetProgressState(_window.get(), TBPF_INDETERMINATE);
break;
case 4:
// sets the progress indicator to a pause state
_taskbar->SetProgressState(_window.get(), TBPF_PAUSED);
_taskbar->SetProgressValue(_window.get(), progress, 100);
break;
default:
break;
}
}
}
Enable fullscreen mode (#3408) ## Summary of the Pull Request Enables the `toggleFullscreen` action to be able to enter fullscreen mode, bound by default to <kbd>alt+enter</kbd>. The action is bubbled up to the WindowsTerminal (Win32) layer, where the window resizes itself to take the entire size of the monitor. This largely reuses code from conhost. Conhost already had a fullscreen mode, so I figured I might as well re-use that. ## References Unfortunately there are still very thin borders around the window when the NonClientIslandWindow is fullscreened. I think I know where the problem is. However, that area of code is about to get a massive overhaul with #3064, so I didn't want to necessarily make it worse right now. A follow up should be filed to add support for "Always show / reveal / never show tabs in fullscreen mode". Currently, the only mode is "never show tabs". Additionally, some of this code (particularily re:drawing the nonclient area) could be re-used for #2238. ## PR Checklist * [x] Closes #531, #3411 * [x] I work here * [n/a] Tests added/passed 😭 * [x] Requires documentation to be updated ## Validation Steps Performed * Manually tested both the NonClientIslandWindow and the IslandWindow. * Cherry-pick commit 8e56bfe * Don't draw the tab strip when maximized (cherry picked from commit bac4be7c0f3ed1cdcd4f9ae8980fc98103538613) * Fix the vista window flash for the NCIW (cherry picked from commit 7d3a18a893c02bd2ed75026f2aac52e20321a1cf) * Some code cleanup for review (cherry picked from commit 9e22b7730bba426adcbfd9e7025f192dbf8efb32) * A tad bit more notes and cleanup * Update schema, docs * Most of the PR comments * I'm not sure this actually works, so I'm committing it to revert it and check * Update some comments that were lost. * Fix a build break? * oh no
2019-11-05 20:40:29 +01:00
// From GdiEngine::s_SetWindowLongWHelper
void SetWindowLongWHelper(const HWND hWnd, const int nIndex, const LONG dwNewLong) noexcept
Enable fullscreen mode (#3408) ## Summary of the Pull Request Enables the `toggleFullscreen` action to be able to enter fullscreen mode, bound by default to <kbd>alt+enter</kbd>. The action is bubbled up to the WindowsTerminal (Win32) layer, where the window resizes itself to take the entire size of the monitor. This largely reuses code from conhost. Conhost already had a fullscreen mode, so I figured I might as well re-use that. ## References Unfortunately there are still very thin borders around the window when the NonClientIslandWindow is fullscreened. I think I know where the problem is. However, that area of code is about to get a massive overhaul with #3064, so I didn't want to necessarily make it worse right now. A follow up should be filed to add support for "Always show / reveal / never show tabs in fullscreen mode". Currently, the only mode is "never show tabs". Additionally, some of this code (particularily re:drawing the nonclient area) could be re-used for #2238. ## PR Checklist * [x] Closes #531, #3411 * [x] I work here * [n/a] Tests added/passed 😭 * [x] Requires documentation to be updated ## Validation Steps Performed * Manually tested both the NonClientIslandWindow and the IslandWindow. * Cherry-pick commit 8e56bfe * Don't draw the tab strip when maximized (cherry picked from commit bac4be7c0f3ed1cdcd4f9ae8980fc98103538613) * Fix the vista window flash for the NCIW (cherry picked from commit 7d3a18a893c02bd2ed75026f2aac52e20321a1cf) * Some code cleanup for review (cherry picked from commit 9e22b7730bba426adcbfd9e7025f192dbf8efb32) * A tad bit more notes and cleanup * Update schema, docs * Most of the PR comments * I'm not sure this actually works, so I'm committing it to revert it and check * Update some comments that were lost. * Fix a build break? * oh no
2019-11-05 20:40:29 +01:00
{
// SetWindowLong has strange error handling. On success, it returns the
// previous Window Long value and doesn't modify the Last Error state. To
// deal with this, we set the last error to 0/S_OK first, call it, and if
// the previous long was 0, we check if the error was non-zero before
// reporting. Otherwise, we'll get an "Error: The operation has completed
// successfully." and there will be another screenshot on the internet
// making fun of Windows. See:
// https://msdn.microsoft.com/en-us/library/windows/desktop/ms633591(v=vs.85).aspx
SetLastError(0);
LONG const lResult = SetWindowLongW(hWnd, nIndex, dwNewLong);
if (0 == lResult)
{
LOG_LAST_ERROR_IF(0 != GetLastError());
}
}
// Method Description:
// - This is a helper to figure out what the window styles should be, given the
// current state of flags like borderless mode and fullscreen mode.
// Arguments:
// - <none>
// Return Value:
// - a LONG with the appropriate flags set for our current window mode, to be used with GWL_STYLE
LONG IslandWindow::_getDesiredWindowStyle() const
{
auto windowStyle = GetWindowLongW(GetHandle(), GWL_STYLE);
// If we're both fullscreen and borderless, fullscreen mode takes precedence.
if (_fullscreen)
{
// When moving to fullscreen, remove WS_OVERLAPPEDWINDOW, which specifies
// styles for non-fullscreen windows (e.g. caption bar), and add the
// WS_POPUP style to allow us to size ourselves to the monitor size.
// Do the reverse when restoring from fullscreen.
// Doing these modifications to that window will cause a vista-style
// window frame to briefly appear when entering and exiting fullscreen.
WI_ClearFlag(windowStyle, WS_BORDER);
WI_ClearFlag(windowStyle, WS_SIZEBOX);
WI_ClearAllFlags(windowStyle, WS_OVERLAPPEDWINDOW);
WI_SetFlag(windowStyle, WS_POPUP);
return windowStyle;
}
else if (_borderless)
{
// When moving to borderless, remove WS_OVERLAPPEDWINDOW, which
// specifies styles for non-fullscreen windows (e.g. caption bar), and
// add the WS_BORDER and WS_SIZEBOX styles. This allows us to still have
// a small resizing frame, but without a full titlebar, nor caption
// buttons.
WI_ClearAllFlags(windowStyle, WS_OVERLAPPEDWINDOW);
WI_ClearFlag(windowStyle, WS_POPUP);
WI_SetFlag(windowStyle, WS_BORDER);
WI_SetFlag(windowStyle, WS_SIZEBOX);
return windowStyle;
}
// Here, we're not in either fullscreen or borderless mode. Return to
// WS_OVERLAPPEDWINDOW.
WI_ClearFlag(windowStyle, WS_POPUP);
WI_ClearFlag(windowStyle, WS_BORDER);
WI_ClearFlag(windowStyle, WS_SIZEBOX);
WI_SetAllFlags(windowStyle, WS_OVERLAPPEDWINDOW);
return windowStyle;
}
// Method Description:
// - Enable or disable focus mode. When entering focus mode, we'll
// need to manually hide the entire titlebar.
// - When we're entering focus we need to do some additional modification
// of our window styles. However, the NonClientIslandWindow very explicitly
// _doesn't_ need to do these steps.
// Arguments:
// - borderlessEnabled: If true, we're entering focus mode. If false, we're leaving.
// Return Value:
// - <none>
void IslandWindow::_SetIsBorderless(const bool borderlessEnabled)
{
_borderless = borderlessEnabled;
HWND const hWnd = GetHandle();
// First, modify regular window styles as appropriate
auto windowStyle = _getDesiredWindowStyle();
SetWindowLongWHelper(hWnd, GWL_STYLE, windowStyle);
// Now modify extended window styles as appropriate
// When moving to fullscreen, remove the window edge style to avoid an
// ugly border when not focused.
auto exWindowStyle = GetWindowLongW(hWnd, GWL_EXSTYLE);
WI_UpdateFlag(exWindowStyle, WS_EX_WINDOWEDGE, !_fullscreen);
SetWindowLongWHelper(hWnd, GWL_EXSTYLE, exWindowStyle);
// Resize the window, with SWP_FRAMECHANGED, to trigger user32 to
// recalculate the non/client areas
const til::rectangle windowPos{ GetWindowRect() };
Make the window name `_quake` special (#9785) ## Summary of the Pull Request This PR adds some special behavior to the window named "\_quake". * When creating the quake window, it ignores "initialRows" and "initialCols" and opens on the top half of the monitor. - It uses `initialPosition` to determine which monitor this is * It cannot be moved * It can only be vertically resized on the bottom border. * It's always in focus mode. - We should probably have an issue tracking "Allow showing tabs in focus mode"? Maybe? - This one element is maybe the one I'm least attached to When renaming a window to "\_quake", it adopts all those behaviors as well. It does not exit focus mode when leaving QM, nor does it resize back. That seemed unnecessary. ## References * As spec'ed in #9274 * See also #8888 ## PR Checklist * [x] In the pursuit of #653 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated, but I'm not gonna do any of that till quake mode is totally done. ## Detailed Description of the Pull Request / Additional comments Note that this doesn't do things like: * dropdown * global hotkey summon * summon to the current monitor * summon to the current desktop I'm doing #653 _very_ piecemeal, to try and make the PRs less egregious. ## Validation Steps Performed * validated that center on launch still works * validated that QM works on different monitors based on `initialPosition` * validated entering/exiting QM behaves as expected ## TODO! * [ ] When snapping the quake window between desktops with <kbd>win+shift+arrow</kbd>, the window doesn't horizontally re-size to the new monitor dimensions. It should.
2021-04-26 21:36:23 +02:00
SetWindowPos(GetHandle(),
HWND_TOP,
windowPos.left<int>(),
windowPos.top<int>(),
windowPos.width<int>(),
windowPos.height<int>(),
SWP_SHOWWINDOW | SWP_FRAMECHANGED | SWP_NOACTIVATE);
}
Fix restore window position when exiting fullscreen (#9737) <!-- 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 This change cleans up the Fullscreen implementation for both conhost and Terminal, improving the restore position (where the window goes when exiting fullscreen). Prior to this change the window wasn't guaranteed to restore somewhere on the window's current monitor when exiting fullscreen. With this change the window will restore always to its current monitor, at a reasonable location (and will 'double restore' (to fullscreen->maximize->restore) after monitor changes while fullscreen, which is the expected user behavior. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9746 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema 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 --> ## Detailed Description of the Pull Request / Additional comments A fullscreen window's monitor can change. - Win+Shift+left/right migrates a window between monitors. - User could open settings, display, and move the monitor or change its DPI. - The monitor could be unplugged. - The session could be remote and be disconnected. A fullscreen window stores a 'restore position' when entering fullscreen, used to move the window back 'where it was'. BUT, its unexpected for the window to exit fullscreen and jump to another monitor. This means its previous position must be migrated from the old monitor's work area to the new monitor's work area. If a window is maximized, it is sized to the work area. Like with fullscreen, a maximized window has a 'restore position', though unlike with fullscreen the restore position for maximized is stored by the system itself. Migration in cases where a maximized (or fullscreen) window's monitor changes is also taken care of by the system. To restore 'safely' to maximized (after changing window styles) a window must only `SetWindowPos(SWP_FRAMECHANGED)`. While technically a maximized window that becomes fullscreen 'is still maximized' (from Win32's perspective), its prudent to also `ShowWindow(SW_MAXIMIZED)` prior to `SWP_FRAMECHANGED` (to explicitly make the window maximized). If not restoring to maximized, the restore position is adjusted by the new/ old work area. Additionally, the new/ old window DPI is used to adjust the size of the window by the DPI change (keeping the window's logical size the same). - The work area origin is checked first (shifting window rect by the change in origin) - The DPI is checked next, changing right/ bottom (size only) - Each edge of the window is compared against the corresponding edge of the work area, nudging the window back on-screen if hanging offscreen. By shifting right before left, bottom before top, the top-left is guaranteed on-screen. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Tried it out. Seemed to work on my machine. Jk, ran conhost/ terminal on mixed DPI system, max (or not), fullscreen, win+shift+left/ exit fullscreen/ maximize. Monitor unplug, etc.
2021-04-13 18:33:00 +02:00
// Method Description:
// - Called when entering fullscreen, with the window's current monitor rect and work area.
// - The current window position, dpi, work area, and maximized state are stored, and the
// window is positioned to the monitor rect.
void IslandWindow::_SetFullscreenPosition(const RECT rcMonitor, const RECT rcWork)
{
HWND const hWnd = GetHandle();
::GetWindowRect(hWnd, &_rcWindowBeforeFullscreen);
_dpiBeforeFullscreen = GetDpiForWindow(hWnd);
_fWasMaximizedBeforeFullscreen = IsZoomed(hWnd);
_rcWorkBeforeFullscreen = rcWork;
SetWindowPos(hWnd,
HWND_TOP,
rcMonitor.left,
rcMonitor.top,
rcMonitor.right - rcMonitor.left,
rcMonitor.bottom - rcMonitor.top,
SWP_FRAMECHANGED);
}
// Method Description:
// - Called when exiting fullscreen, with the window's current monitor work area.
// - The window is restored to its previous position, migrating that previous position to the
// window's current monitor (if the current work area or window DPI have changed).
// - A fullscreen window's monitor can be changed by win+shift+left/right hotkeys or monitor
// topology changes (for example unplugging a monitor or disconnecting a remote session).
void IslandWindow::_RestoreFullscreenPosition(const RECT rcWork)
{
HWND const hWnd = GetHandle();
// If the window was previously maximized, re-maximize the window.
if (_fWasMaximizedBeforeFullscreen)
{
ShowWindow(hWnd, SW_SHOWMAXIMIZED);
SetWindowPos(hWnd, HWND_TOP, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_NOZORDER | SWP_FRAMECHANGED);
return;
}
// Start with the stored window position.
RECT rcRestore = _rcWindowBeforeFullscreen;
// If the window DPI has changed, re-size the stored position by the change in DPI. This
// ensures the window restores to the same logical size (even if to a monitor with a different
// DPI/ scale factor).
UINT dpiWindow = GetDpiForWindow(hWnd);
rcRestore.right = rcRestore.left + MulDiv(rcRestore.right - rcRestore.left, dpiWindow, _dpiBeforeFullscreen);
rcRestore.bottom = rcRestore.top + MulDiv(rcRestore.bottom - rcRestore.top, dpiWindow, _dpiBeforeFullscreen);
// Offset the stored position by the difference in work area.
OffsetRect(&rcRestore,
rcWork.left - _rcWorkBeforeFullscreen.left,
rcWork.top - _rcWorkBeforeFullscreen.top);
const til::size ncSize{ GetTotalNonClientExclusiveSize(dpiWindow) };
RECT rcWorkAdjusted = rcWork;
// GH#10199 - adjust the size of the "work" rect by the size of our borders.
// We want to make sure the window is restored within the bounds of the
// monitor we're on, but it's totally fine if the invisible borders are
// outside the monitor.
const auto halfWidth{ ncSize.width<long>() / 2 };
const auto halfHeight{ ncSize.height<long>() / 2 };
rcWorkAdjusted.left -= halfWidth;
rcWorkAdjusted.right += halfWidth;
rcWorkAdjusted.top -= halfHeight;
rcWorkAdjusted.bottom += halfHeight;
Fix restore window position when exiting fullscreen (#9737) <!-- 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 This change cleans up the Fullscreen implementation for both conhost and Terminal, improving the restore position (where the window goes when exiting fullscreen). Prior to this change the window wasn't guaranteed to restore somewhere on the window's current monitor when exiting fullscreen. With this change the window will restore always to its current monitor, at a reasonable location (and will 'double restore' (to fullscreen->maximize->restore) after monitor changes while fullscreen, which is the expected user behavior. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9746 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema 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 --> ## Detailed Description of the Pull Request / Additional comments A fullscreen window's monitor can change. - Win+Shift+left/right migrates a window between monitors. - User could open settings, display, and move the monitor or change its DPI. - The monitor could be unplugged. - The session could be remote and be disconnected. A fullscreen window stores a 'restore position' when entering fullscreen, used to move the window back 'where it was'. BUT, its unexpected for the window to exit fullscreen and jump to another monitor. This means its previous position must be migrated from the old monitor's work area to the new monitor's work area. If a window is maximized, it is sized to the work area. Like with fullscreen, a maximized window has a 'restore position', though unlike with fullscreen the restore position for maximized is stored by the system itself. Migration in cases where a maximized (or fullscreen) window's monitor changes is also taken care of by the system. To restore 'safely' to maximized (after changing window styles) a window must only `SetWindowPos(SWP_FRAMECHANGED)`. While technically a maximized window that becomes fullscreen 'is still maximized' (from Win32's perspective), its prudent to also `ShowWindow(SW_MAXIMIZED)` prior to `SWP_FRAMECHANGED` (to explicitly make the window maximized). If not restoring to maximized, the restore position is adjusted by the new/ old work area. Additionally, the new/ old window DPI is used to adjust the size of the window by the DPI change (keeping the window's logical size the same). - The work area origin is checked first (shifting window rect by the change in origin) - The DPI is checked next, changing right/ bottom (size only) - Each edge of the window is compared against the corresponding edge of the work area, nudging the window back on-screen if hanging offscreen. By shifting right before left, bottom before top, the top-left is guaranteed on-screen. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Tried it out. Seemed to work on my machine. Jk, ran conhost/ terminal on mixed DPI system, max (or not), fullscreen, win+shift+left/ exit fullscreen/ maximize. Monitor unplug, etc.
2021-04-13 18:33:00 +02:00
// Enforce that our position is entirely within the bounds of our work area.
// Prefer the top-left be on-screen rather than bottom-right (right before left, bottom before top).
if (rcRestore.right > rcWorkAdjusted.right)
Fix restore window position when exiting fullscreen (#9737) <!-- 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 This change cleans up the Fullscreen implementation for both conhost and Terminal, improving the restore position (where the window goes when exiting fullscreen). Prior to this change the window wasn't guaranteed to restore somewhere on the window's current monitor when exiting fullscreen. With this change the window will restore always to its current monitor, at a reasonable location (and will 'double restore' (to fullscreen->maximize->restore) after monitor changes while fullscreen, which is the expected user behavior. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9746 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema 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 --> ## Detailed Description of the Pull Request / Additional comments A fullscreen window's monitor can change. - Win+Shift+left/right migrates a window between monitors. - User could open settings, display, and move the monitor or change its DPI. - The monitor could be unplugged. - The session could be remote and be disconnected. A fullscreen window stores a 'restore position' when entering fullscreen, used to move the window back 'where it was'. BUT, its unexpected for the window to exit fullscreen and jump to another monitor. This means its previous position must be migrated from the old monitor's work area to the new monitor's work area. If a window is maximized, it is sized to the work area. Like with fullscreen, a maximized window has a 'restore position', though unlike with fullscreen the restore position for maximized is stored by the system itself. Migration in cases where a maximized (or fullscreen) window's monitor changes is also taken care of by the system. To restore 'safely' to maximized (after changing window styles) a window must only `SetWindowPos(SWP_FRAMECHANGED)`. While technically a maximized window that becomes fullscreen 'is still maximized' (from Win32's perspective), its prudent to also `ShowWindow(SW_MAXIMIZED)` prior to `SWP_FRAMECHANGED` (to explicitly make the window maximized). If not restoring to maximized, the restore position is adjusted by the new/ old work area. Additionally, the new/ old window DPI is used to adjust the size of the window by the DPI change (keeping the window's logical size the same). - The work area origin is checked first (shifting window rect by the change in origin) - The DPI is checked next, changing right/ bottom (size only) - Each edge of the window is compared against the corresponding edge of the work area, nudging the window back on-screen if hanging offscreen. By shifting right before left, bottom before top, the top-left is guaranteed on-screen. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Tried it out. Seemed to work on my machine. Jk, ran conhost/ terminal on mixed DPI system, max (or not), fullscreen, win+shift+left/ exit fullscreen/ maximize. Monitor unplug, etc.
2021-04-13 18:33:00 +02:00
{
OffsetRect(&rcRestore, rcWorkAdjusted.right - rcRestore.right, 0);
Fix restore window position when exiting fullscreen (#9737) <!-- 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 This change cleans up the Fullscreen implementation for both conhost and Terminal, improving the restore position (where the window goes when exiting fullscreen). Prior to this change the window wasn't guaranteed to restore somewhere on the window's current monitor when exiting fullscreen. With this change the window will restore always to its current monitor, at a reasonable location (and will 'double restore' (to fullscreen->maximize->restore) after monitor changes while fullscreen, which is the expected user behavior. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9746 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema 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 --> ## Detailed Description of the Pull Request / Additional comments A fullscreen window's monitor can change. - Win+Shift+left/right migrates a window between monitors. - User could open settings, display, and move the monitor or change its DPI. - The monitor could be unplugged. - The session could be remote and be disconnected. A fullscreen window stores a 'restore position' when entering fullscreen, used to move the window back 'where it was'. BUT, its unexpected for the window to exit fullscreen and jump to another monitor. This means its previous position must be migrated from the old monitor's work area to the new monitor's work area. If a window is maximized, it is sized to the work area. Like with fullscreen, a maximized window has a 'restore position', though unlike with fullscreen the restore position for maximized is stored by the system itself. Migration in cases where a maximized (or fullscreen) window's monitor changes is also taken care of by the system. To restore 'safely' to maximized (after changing window styles) a window must only `SetWindowPos(SWP_FRAMECHANGED)`. While technically a maximized window that becomes fullscreen 'is still maximized' (from Win32's perspective), its prudent to also `ShowWindow(SW_MAXIMIZED)` prior to `SWP_FRAMECHANGED` (to explicitly make the window maximized). If not restoring to maximized, the restore position is adjusted by the new/ old work area. Additionally, the new/ old window DPI is used to adjust the size of the window by the DPI change (keeping the window's logical size the same). - The work area origin is checked first (shifting window rect by the change in origin) - The DPI is checked next, changing right/ bottom (size only) - Each edge of the window is compared against the corresponding edge of the work area, nudging the window back on-screen if hanging offscreen. By shifting right before left, bottom before top, the top-left is guaranteed on-screen. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Tried it out. Seemed to work on my machine. Jk, ran conhost/ terminal on mixed DPI system, max (or not), fullscreen, win+shift+left/ exit fullscreen/ maximize. Monitor unplug, etc.
2021-04-13 18:33:00 +02:00
}
if (rcRestore.left < rcWorkAdjusted.left)
Fix restore window position when exiting fullscreen (#9737) <!-- 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 This change cleans up the Fullscreen implementation for both conhost and Terminal, improving the restore position (where the window goes when exiting fullscreen). Prior to this change the window wasn't guaranteed to restore somewhere on the window's current monitor when exiting fullscreen. With this change the window will restore always to its current monitor, at a reasonable location (and will 'double restore' (to fullscreen->maximize->restore) after monitor changes while fullscreen, which is the expected user behavior. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9746 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema 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 --> ## Detailed Description of the Pull Request / Additional comments A fullscreen window's monitor can change. - Win+Shift+left/right migrates a window between monitors. - User could open settings, display, and move the monitor or change its DPI. - The monitor could be unplugged. - The session could be remote and be disconnected. A fullscreen window stores a 'restore position' when entering fullscreen, used to move the window back 'where it was'. BUT, its unexpected for the window to exit fullscreen and jump to another monitor. This means its previous position must be migrated from the old monitor's work area to the new monitor's work area. If a window is maximized, it is sized to the work area. Like with fullscreen, a maximized window has a 'restore position', though unlike with fullscreen the restore position for maximized is stored by the system itself. Migration in cases where a maximized (or fullscreen) window's monitor changes is also taken care of by the system. To restore 'safely' to maximized (after changing window styles) a window must only `SetWindowPos(SWP_FRAMECHANGED)`. While technically a maximized window that becomes fullscreen 'is still maximized' (from Win32's perspective), its prudent to also `ShowWindow(SW_MAXIMIZED)` prior to `SWP_FRAMECHANGED` (to explicitly make the window maximized). If not restoring to maximized, the restore position is adjusted by the new/ old work area. Additionally, the new/ old window DPI is used to adjust the size of the window by the DPI change (keeping the window's logical size the same). - The work area origin is checked first (shifting window rect by the change in origin) - The DPI is checked next, changing right/ bottom (size only) - Each edge of the window is compared against the corresponding edge of the work area, nudging the window back on-screen if hanging offscreen. By shifting right before left, bottom before top, the top-left is guaranteed on-screen. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Tried it out. Seemed to work on my machine. Jk, ran conhost/ terminal on mixed DPI system, max (or not), fullscreen, win+shift+left/ exit fullscreen/ maximize. Monitor unplug, etc.
2021-04-13 18:33:00 +02:00
{
OffsetRect(&rcRestore, rcWorkAdjusted.left - rcRestore.left, 0);
Fix restore window position when exiting fullscreen (#9737) <!-- 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 This change cleans up the Fullscreen implementation for both conhost and Terminal, improving the restore position (where the window goes when exiting fullscreen). Prior to this change the window wasn't guaranteed to restore somewhere on the window's current monitor when exiting fullscreen. With this change the window will restore always to its current monitor, at a reasonable location (and will 'double restore' (to fullscreen->maximize->restore) after monitor changes while fullscreen, which is the expected user behavior. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9746 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema 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 --> ## Detailed Description of the Pull Request / Additional comments A fullscreen window's monitor can change. - Win+Shift+left/right migrates a window between monitors. - User could open settings, display, and move the monitor or change its DPI. - The monitor could be unplugged. - The session could be remote and be disconnected. A fullscreen window stores a 'restore position' when entering fullscreen, used to move the window back 'where it was'. BUT, its unexpected for the window to exit fullscreen and jump to another monitor. This means its previous position must be migrated from the old monitor's work area to the new monitor's work area. If a window is maximized, it is sized to the work area. Like with fullscreen, a maximized window has a 'restore position', though unlike with fullscreen the restore position for maximized is stored by the system itself. Migration in cases where a maximized (or fullscreen) window's monitor changes is also taken care of by the system. To restore 'safely' to maximized (after changing window styles) a window must only `SetWindowPos(SWP_FRAMECHANGED)`. While technically a maximized window that becomes fullscreen 'is still maximized' (from Win32's perspective), its prudent to also `ShowWindow(SW_MAXIMIZED)` prior to `SWP_FRAMECHANGED` (to explicitly make the window maximized). If not restoring to maximized, the restore position is adjusted by the new/ old work area. Additionally, the new/ old window DPI is used to adjust the size of the window by the DPI change (keeping the window's logical size the same). - The work area origin is checked first (shifting window rect by the change in origin) - The DPI is checked next, changing right/ bottom (size only) - Each edge of the window is compared against the corresponding edge of the work area, nudging the window back on-screen if hanging offscreen. By shifting right before left, bottom before top, the top-left is guaranteed on-screen. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Tried it out. Seemed to work on my machine. Jk, ran conhost/ terminal on mixed DPI system, max (or not), fullscreen, win+shift+left/ exit fullscreen/ maximize. Monitor unplug, etc.
2021-04-13 18:33:00 +02:00
}
if (rcRestore.bottom > rcWorkAdjusted.bottom)
Fix restore window position when exiting fullscreen (#9737) <!-- 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 This change cleans up the Fullscreen implementation for both conhost and Terminal, improving the restore position (where the window goes when exiting fullscreen). Prior to this change the window wasn't guaranteed to restore somewhere on the window's current monitor when exiting fullscreen. With this change the window will restore always to its current monitor, at a reasonable location (and will 'double restore' (to fullscreen->maximize->restore) after monitor changes while fullscreen, which is the expected user behavior. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9746 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema 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 --> ## Detailed Description of the Pull Request / Additional comments A fullscreen window's monitor can change. - Win+Shift+left/right migrates a window between monitors. - User could open settings, display, and move the monitor or change its DPI. - The monitor could be unplugged. - The session could be remote and be disconnected. A fullscreen window stores a 'restore position' when entering fullscreen, used to move the window back 'where it was'. BUT, its unexpected for the window to exit fullscreen and jump to another monitor. This means its previous position must be migrated from the old monitor's work area to the new monitor's work area. If a window is maximized, it is sized to the work area. Like with fullscreen, a maximized window has a 'restore position', though unlike with fullscreen the restore position for maximized is stored by the system itself. Migration in cases where a maximized (or fullscreen) window's monitor changes is also taken care of by the system. To restore 'safely' to maximized (after changing window styles) a window must only `SetWindowPos(SWP_FRAMECHANGED)`. While technically a maximized window that becomes fullscreen 'is still maximized' (from Win32's perspective), its prudent to also `ShowWindow(SW_MAXIMIZED)` prior to `SWP_FRAMECHANGED` (to explicitly make the window maximized). If not restoring to maximized, the restore position is adjusted by the new/ old work area. Additionally, the new/ old window DPI is used to adjust the size of the window by the DPI change (keeping the window's logical size the same). - The work area origin is checked first (shifting window rect by the change in origin) - The DPI is checked next, changing right/ bottom (size only) - Each edge of the window is compared against the corresponding edge of the work area, nudging the window back on-screen if hanging offscreen. By shifting right before left, bottom before top, the top-left is guaranteed on-screen. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Tried it out. Seemed to work on my machine. Jk, ran conhost/ terminal on mixed DPI system, max (or not), fullscreen, win+shift+left/ exit fullscreen/ maximize. Monitor unplug, etc.
2021-04-13 18:33:00 +02:00
{
OffsetRect(&rcRestore, 0, rcWorkAdjusted.bottom - rcRestore.bottom);
Fix restore window position when exiting fullscreen (#9737) <!-- 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 This change cleans up the Fullscreen implementation for both conhost and Terminal, improving the restore position (where the window goes when exiting fullscreen). Prior to this change the window wasn't guaranteed to restore somewhere on the window's current monitor when exiting fullscreen. With this change the window will restore always to its current monitor, at a reasonable location (and will 'double restore' (to fullscreen->maximize->restore) after monitor changes while fullscreen, which is the expected user behavior. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9746 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema 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 --> ## Detailed Description of the Pull Request / Additional comments A fullscreen window's monitor can change. - Win+Shift+left/right migrates a window between monitors. - User could open settings, display, and move the monitor or change its DPI. - The monitor could be unplugged. - The session could be remote and be disconnected. A fullscreen window stores a 'restore position' when entering fullscreen, used to move the window back 'where it was'. BUT, its unexpected for the window to exit fullscreen and jump to another monitor. This means its previous position must be migrated from the old monitor's work area to the new monitor's work area. If a window is maximized, it is sized to the work area. Like with fullscreen, a maximized window has a 'restore position', though unlike with fullscreen the restore position for maximized is stored by the system itself. Migration in cases where a maximized (or fullscreen) window's monitor changes is also taken care of by the system. To restore 'safely' to maximized (after changing window styles) a window must only `SetWindowPos(SWP_FRAMECHANGED)`. While technically a maximized window that becomes fullscreen 'is still maximized' (from Win32's perspective), its prudent to also `ShowWindow(SW_MAXIMIZED)` prior to `SWP_FRAMECHANGED` (to explicitly make the window maximized). If not restoring to maximized, the restore position is adjusted by the new/ old work area. Additionally, the new/ old window DPI is used to adjust the size of the window by the DPI change (keeping the window's logical size the same). - The work area origin is checked first (shifting window rect by the change in origin) - The DPI is checked next, changing right/ bottom (size only) - Each edge of the window is compared against the corresponding edge of the work area, nudging the window back on-screen if hanging offscreen. By shifting right before left, bottom before top, the top-left is guaranteed on-screen. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Tried it out. Seemed to work on my machine. Jk, ran conhost/ terminal on mixed DPI system, max (or not), fullscreen, win+shift+left/ exit fullscreen/ maximize. Monitor unplug, etc.
2021-04-13 18:33:00 +02:00
}
if (rcRestore.top < rcWorkAdjusted.top)
Fix restore window position when exiting fullscreen (#9737) <!-- 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 This change cleans up the Fullscreen implementation for both conhost and Terminal, improving the restore position (where the window goes when exiting fullscreen). Prior to this change the window wasn't guaranteed to restore somewhere on the window's current monitor when exiting fullscreen. With this change the window will restore always to its current monitor, at a reasonable location (and will 'double restore' (to fullscreen->maximize->restore) after monitor changes while fullscreen, which is the expected user behavior. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9746 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema 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 --> ## Detailed Description of the Pull Request / Additional comments A fullscreen window's monitor can change. - Win+Shift+left/right migrates a window between monitors. - User could open settings, display, and move the monitor or change its DPI. - The monitor could be unplugged. - The session could be remote and be disconnected. A fullscreen window stores a 'restore position' when entering fullscreen, used to move the window back 'where it was'. BUT, its unexpected for the window to exit fullscreen and jump to another monitor. This means its previous position must be migrated from the old monitor's work area to the new monitor's work area. If a window is maximized, it is sized to the work area. Like with fullscreen, a maximized window has a 'restore position', though unlike with fullscreen the restore position for maximized is stored by the system itself. Migration in cases where a maximized (or fullscreen) window's monitor changes is also taken care of by the system. To restore 'safely' to maximized (after changing window styles) a window must only `SetWindowPos(SWP_FRAMECHANGED)`. While technically a maximized window that becomes fullscreen 'is still maximized' (from Win32's perspective), its prudent to also `ShowWindow(SW_MAXIMIZED)` prior to `SWP_FRAMECHANGED` (to explicitly make the window maximized). If not restoring to maximized, the restore position is adjusted by the new/ old work area. Additionally, the new/ old window DPI is used to adjust the size of the window by the DPI change (keeping the window's logical size the same). - The work area origin is checked first (shifting window rect by the change in origin) - The DPI is checked next, changing right/ bottom (size only) - Each edge of the window is compared against the corresponding edge of the work area, nudging the window back on-screen if hanging offscreen. By shifting right before left, bottom before top, the top-left is guaranteed on-screen. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Tried it out. Seemed to work on my machine. Jk, ran conhost/ terminal on mixed DPI system, max (or not), fullscreen, win+shift+left/ exit fullscreen/ maximize. Monitor unplug, etc.
2021-04-13 18:33:00 +02:00
{
OffsetRect(&rcRestore, 0, rcWorkAdjusted.top - rcRestore.top);
Fix restore window position when exiting fullscreen (#9737) <!-- 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 This change cleans up the Fullscreen implementation for both conhost and Terminal, improving the restore position (where the window goes when exiting fullscreen). Prior to this change the window wasn't guaranteed to restore somewhere on the window's current monitor when exiting fullscreen. With this change the window will restore always to its current monitor, at a reasonable location (and will 'double restore' (to fullscreen->maximize->restore) after monitor changes while fullscreen, which is the expected user behavior. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9746 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema 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 --> ## Detailed Description of the Pull Request / Additional comments A fullscreen window's monitor can change. - Win+Shift+left/right migrates a window between monitors. - User could open settings, display, and move the monitor or change its DPI. - The monitor could be unplugged. - The session could be remote and be disconnected. A fullscreen window stores a 'restore position' when entering fullscreen, used to move the window back 'where it was'. BUT, its unexpected for the window to exit fullscreen and jump to another monitor. This means its previous position must be migrated from the old monitor's work area to the new monitor's work area. If a window is maximized, it is sized to the work area. Like with fullscreen, a maximized window has a 'restore position', though unlike with fullscreen the restore position for maximized is stored by the system itself. Migration in cases where a maximized (or fullscreen) window's monitor changes is also taken care of by the system. To restore 'safely' to maximized (after changing window styles) a window must only `SetWindowPos(SWP_FRAMECHANGED)`. While technically a maximized window that becomes fullscreen 'is still maximized' (from Win32's perspective), its prudent to also `ShowWindow(SW_MAXIMIZED)` prior to `SWP_FRAMECHANGED` (to explicitly make the window maximized). If not restoring to maximized, the restore position is adjusted by the new/ old work area. Additionally, the new/ old window DPI is used to adjust the size of the window by the DPI change (keeping the window's logical size the same). - The work area origin is checked first (shifting window rect by the change in origin) - The DPI is checked next, changing right/ bottom (size only) - Each edge of the window is compared against the corresponding edge of the work area, nudging the window back on-screen if hanging offscreen. By shifting right before left, bottom before top, the top-left is guaranteed on-screen. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Tried it out. Seemed to work on my machine. Jk, ran conhost/ terminal on mixed DPI system, max (or not), fullscreen, win+shift+left/ exit fullscreen/ maximize. Monitor unplug, etc.
2021-04-13 18:33:00 +02:00
}
// Show the window at the computed position.
SetWindowPos(hWnd,
HWND_TOP,
rcRestore.left,
rcRestore.top,
rcRestore.right - rcRestore.left,
rcRestore.bottom - rcRestore.top,
SWP_SHOWWINDOW | SWP_NOZORDER | SWP_NOACTIVATE | SWP_FRAMECHANGED);
}
Enable fullscreen mode (#3408) ## Summary of the Pull Request Enables the `toggleFullscreen` action to be able to enter fullscreen mode, bound by default to <kbd>alt+enter</kbd>. The action is bubbled up to the WindowsTerminal (Win32) layer, where the window resizes itself to take the entire size of the monitor. This largely reuses code from conhost. Conhost already had a fullscreen mode, so I figured I might as well re-use that. ## References Unfortunately there are still very thin borders around the window when the NonClientIslandWindow is fullscreened. I think I know where the problem is. However, that area of code is about to get a massive overhaul with #3064, so I didn't want to necessarily make it worse right now. A follow up should be filed to add support for "Always show / reveal / never show tabs in fullscreen mode". Currently, the only mode is "never show tabs". Additionally, some of this code (particularily re:drawing the nonclient area) could be re-used for #2238. ## PR Checklist * [x] Closes #531, #3411 * [x] I work here * [n/a] Tests added/passed 😭 * [x] Requires documentation to be updated ## Validation Steps Performed * Manually tested both the NonClientIslandWindow and the IslandWindow. * Cherry-pick commit 8e56bfe * Don't draw the tab strip when maximized (cherry picked from commit bac4be7c0f3ed1cdcd4f9ae8980fc98103538613) * Fix the vista window flash for the NCIW (cherry picked from commit 7d3a18a893c02bd2ed75026f2aac52e20321a1cf) * Some code cleanup for review (cherry picked from commit 9e22b7730bba426adcbfd9e7025f192dbf8efb32) * A tad bit more notes and cleanup * Update schema, docs * Most of the PR comments * I'm not sure this actually works, so I'm committing it to revert it and check * Update some comments that were lost. * Fix a build break? * oh no
2019-11-05 20:40:29 +01:00
// Method Description:
// - Controls setting us into or out of fullscreen mode. Largely taken from
// Window::SetIsFullscreen in conhost.
// - When entering fullscreen mode, we'll save the current window size and
// location, and expand to take the entire monitor size. When leaving, we'll
// use that saved size to restore back to.
// Arguments:
// - fullscreenEnabled true if we should enable fullscreen mode, false to disable.
// Return Value:
// - <none>
void IslandWindow::_SetIsFullscreen(const bool fullscreenEnabled)
{
// It is possible to enter _SetIsFullscreen even if we're already in full
// screen. Use the old is in fullscreen flag to gate checks that rely on the
// current state.
Fix restore window position when exiting fullscreen (#9737) <!-- 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 This change cleans up the Fullscreen implementation for both conhost and Terminal, improving the restore position (where the window goes when exiting fullscreen). Prior to this change the window wasn't guaranteed to restore somewhere on the window's current monitor when exiting fullscreen. With this change the window will restore always to its current monitor, at a reasonable location (and will 'double restore' (to fullscreen->maximize->restore) after monitor changes while fullscreen, which is the expected user behavior. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9746 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema 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 --> ## Detailed Description of the Pull Request / Additional comments A fullscreen window's monitor can change. - Win+Shift+left/right migrates a window between monitors. - User could open settings, display, and move the monitor or change its DPI. - The monitor could be unplugged. - The session could be remote and be disconnected. A fullscreen window stores a 'restore position' when entering fullscreen, used to move the window back 'where it was'. BUT, its unexpected for the window to exit fullscreen and jump to another monitor. This means its previous position must be migrated from the old monitor's work area to the new monitor's work area. If a window is maximized, it is sized to the work area. Like with fullscreen, a maximized window has a 'restore position', though unlike with fullscreen the restore position for maximized is stored by the system itself. Migration in cases where a maximized (or fullscreen) window's monitor changes is also taken care of by the system. To restore 'safely' to maximized (after changing window styles) a window must only `SetWindowPos(SWP_FRAMECHANGED)`. While technically a maximized window that becomes fullscreen 'is still maximized' (from Win32's perspective), its prudent to also `ShowWindow(SW_MAXIMIZED)` prior to `SWP_FRAMECHANGED` (to explicitly make the window maximized). If not restoring to maximized, the restore position is adjusted by the new/ old work area. Additionally, the new/ old window DPI is used to adjust the size of the window by the DPI change (keeping the window's logical size the same). - The work area origin is checked first (shifting window rect by the change in origin) - The DPI is checked next, changing right/ bottom (size only) - Each edge of the window is compared against the corresponding edge of the work area, nudging the window back on-screen if hanging offscreen. By shifting right before left, bottom before top, the top-left is guaranteed on-screen. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Tried it out. Seemed to work on my machine. Jk, ran conhost/ terminal on mixed DPI system, max (or not), fullscreen, win+shift+left/ exit fullscreen/ maximize. Monitor unplug, etc.
2021-04-13 18:33:00 +02:00
const bool fChangingFullscreen = (fullscreenEnabled != _fullscreen);
Enable fullscreen mode (#3408) ## Summary of the Pull Request Enables the `toggleFullscreen` action to be able to enter fullscreen mode, bound by default to <kbd>alt+enter</kbd>. The action is bubbled up to the WindowsTerminal (Win32) layer, where the window resizes itself to take the entire size of the monitor. This largely reuses code from conhost. Conhost already had a fullscreen mode, so I figured I might as well re-use that. ## References Unfortunately there are still very thin borders around the window when the NonClientIslandWindow is fullscreened. I think I know where the problem is. However, that area of code is about to get a massive overhaul with #3064, so I didn't want to necessarily make it worse right now. A follow up should be filed to add support for "Always show / reveal / never show tabs in fullscreen mode". Currently, the only mode is "never show tabs". Additionally, some of this code (particularily re:drawing the nonclient area) could be re-used for #2238. ## PR Checklist * [x] Closes #531, #3411 * [x] I work here * [n/a] Tests added/passed 😭 * [x] Requires documentation to be updated ## Validation Steps Performed * Manually tested both the NonClientIslandWindow and the IslandWindow. * Cherry-pick commit 8e56bfe * Don't draw the tab strip when maximized (cherry picked from commit bac4be7c0f3ed1cdcd4f9ae8980fc98103538613) * Fix the vista window flash for the NCIW (cherry picked from commit 7d3a18a893c02bd2ed75026f2aac52e20321a1cf) * Some code cleanup for review (cherry picked from commit 9e22b7730bba426adcbfd9e7025f192dbf8efb32) * A tad bit more notes and cleanup * Update schema, docs * Most of the PR comments * I'm not sure this actually works, so I'm committing it to revert it and check * Update some comments that were lost. * Fix a build break? * oh no
2019-11-05 20:40:29 +01:00
_fullscreen = fullscreenEnabled;
HWND const hWnd = GetHandle();
Use WS_POPUP for NonClientIslandWindow instead of overriding WM_NCCALCSIZE to remove borders (#3721) <!-- 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 Fixes the sides disappearing when entering full screen mode when the window is maximized. However, now, a Vista-style frame briefly appears when entering/exiting full screen. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #3709 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [x] Requires documentation to be updated (no) * [ ] 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 When the non-client island window is maximized and has the WS_OVERLAPPEDWINDOW style, SetWindowPos is "lying": the position ends up being offset compared to the one we gave it (found by debugging). So I changed it to use WS_POPUP like the client island window was already doing. But now it has the Vista frame that appears briefly when entering/exiting full screen like the client island window. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed
2019-12-16 21:58:38 +01:00
// First, modify regular window styles as appropriate
auto windowStyle = _getDesiredWindowStyle();
SetWindowLongWHelper(hWnd, GWL_STYLE, windowStyle);
Enable fullscreen mode (#3408) ## Summary of the Pull Request Enables the `toggleFullscreen` action to be able to enter fullscreen mode, bound by default to <kbd>alt+enter</kbd>. The action is bubbled up to the WindowsTerminal (Win32) layer, where the window resizes itself to take the entire size of the monitor. This largely reuses code from conhost. Conhost already had a fullscreen mode, so I figured I might as well re-use that. ## References Unfortunately there are still very thin borders around the window when the NonClientIslandWindow is fullscreened. I think I know where the problem is. However, that area of code is about to get a massive overhaul with #3064, so I didn't want to necessarily make it worse right now. A follow up should be filed to add support for "Always show / reveal / never show tabs in fullscreen mode". Currently, the only mode is "never show tabs". Additionally, some of this code (particularily re:drawing the nonclient area) could be re-used for #2238. ## PR Checklist * [x] Closes #531, #3411 * [x] I work here * [n/a] Tests added/passed 😭 * [x] Requires documentation to be updated ## Validation Steps Performed * Manually tested both the NonClientIslandWindow and the IslandWindow. * Cherry-pick commit 8e56bfe * Don't draw the tab strip when maximized (cherry picked from commit bac4be7c0f3ed1cdcd4f9ae8980fc98103538613) * Fix the vista window flash for the NCIW (cherry picked from commit 7d3a18a893c02bd2ed75026f2aac52e20321a1cf) * Some code cleanup for review (cherry picked from commit 9e22b7730bba426adcbfd9e7025f192dbf8efb32) * A tad bit more notes and cleanup * Update schema, docs * Most of the PR comments * I'm not sure this actually works, so I'm committing it to revert it and check * Update some comments that were lost. * Fix a build break? * oh no
2019-11-05 20:40:29 +01:00
Use WS_POPUP for NonClientIslandWindow instead of overriding WM_NCCALCSIZE to remove borders (#3721) <!-- 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 Fixes the sides disappearing when entering full screen mode when the window is maximized. However, now, a Vista-style frame briefly appears when entering/exiting full screen. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #3709 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [x] Requires documentation to be updated (no) * [ ] 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 When the non-client island window is maximized and has the WS_OVERLAPPEDWINDOW style, SetWindowPos is "lying": the position ends up being offset compared to the one we gave it (found by debugging). So I changed it to use WS_POPUP like the client island window was already doing. But now it has the Vista frame that appears briefly when entering/exiting full screen like the client island window. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed
2019-12-16 21:58:38 +01:00
// Now modify extended window styles as appropriate
// When moving to fullscreen, remove the window edge style to avoid an
// ugly border when not focused.
auto exWindowStyle = GetWindowLongW(hWnd, GWL_EXSTYLE);
WI_UpdateFlag(exWindowStyle, WS_EX_WINDOWEDGE, !_fullscreen);
SetWindowLongWHelper(hWnd, GWL_EXSTYLE, exWindowStyle);
Enable fullscreen mode (#3408) ## Summary of the Pull Request Enables the `toggleFullscreen` action to be able to enter fullscreen mode, bound by default to <kbd>alt+enter</kbd>. The action is bubbled up to the WindowsTerminal (Win32) layer, where the window resizes itself to take the entire size of the monitor. This largely reuses code from conhost. Conhost already had a fullscreen mode, so I figured I might as well re-use that. ## References Unfortunately there are still very thin borders around the window when the NonClientIslandWindow is fullscreened. I think I know where the problem is. However, that area of code is about to get a massive overhaul with #3064, so I didn't want to necessarily make it worse right now. A follow up should be filed to add support for "Always show / reveal / never show tabs in fullscreen mode". Currently, the only mode is "never show tabs". Additionally, some of this code (particularily re:drawing the nonclient area) could be re-used for #2238. ## PR Checklist * [x] Closes #531, #3411 * [x] I work here * [n/a] Tests added/passed 😭 * [x] Requires documentation to be updated ## Validation Steps Performed * Manually tested both the NonClientIslandWindow and the IslandWindow. * Cherry-pick commit 8e56bfe * Don't draw the tab strip when maximized (cherry picked from commit bac4be7c0f3ed1cdcd4f9ae8980fc98103538613) * Fix the vista window flash for the NCIW (cherry picked from commit 7d3a18a893c02bd2ed75026f2aac52e20321a1cf) * Some code cleanup for review (cherry picked from commit 9e22b7730bba426adcbfd9e7025f192dbf8efb32) * A tad bit more notes and cleanup * Update schema, docs * Most of the PR comments * I'm not sure this actually works, so I'm committing it to revert it and check * Update some comments that were lost. * Fix a build break? * oh no
2019-11-05 20:40:29 +01:00
Fix restore window position when exiting fullscreen (#9737) <!-- 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 This change cleans up the Fullscreen implementation for both conhost and Terminal, improving the restore position (where the window goes when exiting fullscreen). Prior to this change the window wasn't guaranteed to restore somewhere on the window's current monitor when exiting fullscreen. With this change the window will restore always to its current monitor, at a reasonable location (and will 'double restore' (to fullscreen->maximize->restore) after monitor changes while fullscreen, which is the expected user behavior. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9746 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema 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 --> ## Detailed Description of the Pull Request / Additional comments A fullscreen window's monitor can change. - Win+Shift+left/right migrates a window between monitors. - User could open settings, display, and move the monitor or change its DPI. - The monitor could be unplugged. - The session could be remote and be disconnected. A fullscreen window stores a 'restore position' when entering fullscreen, used to move the window back 'where it was'. BUT, its unexpected for the window to exit fullscreen and jump to another monitor. This means its previous position must be migrated from the old monitor's work area to the new monitor's work area. If a window is maximized, it is sized to the work area. Like with fullscreen, a maximized window has a 'restore position', though unlike with fullscreen the restore position for maximized is stored by the system itself. Migration in cases where a maximized (or fullscreen) window's monitor changes is also taken care of by the system. To restore 'safely' to maximized (after changing window styles) a window must only `SetWindowPos(SWP_FRAMECHANGED)`. While technically a maximized window that becomes fullscreen 'is still maximized' (from Win32's perspective), its prudent to also `ShowWindow(SW_MAXIMIZED)` prior to `SWP_FRAMECHANGED` (to explicitly make the window maximized). If not restoring to maximized, the restore position is adjusted by the new/ old work area. Additionally, the new/ old window DPI is used to adjust the size of the window by the DPI change (keeping the window's logical size the same). - The work area origin is checked first (shifting window rect by the change in origin) - The DPI is checked next, changing right/ bottom (size only) - Each edge of the window is compared against the corresponding edge of the work area, nudging the window back on-screen if hanging offscreen. By shifting right before left, bottom before top, the top-left is guaranteed on-screen. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Tried it out. Seemed to work on my machine. Jk, ran conhost/ terminal on mixed DPI system, max (or not), fullscreen, win+shift+left/ exit fullscreen/ maximize. Monitor unplug, etc.
2021-04-13 18:33:00 +02:00
// Only change the window position if changing fullscreen state.
if (fChangingFullscreen)
Enable fullscreen mode (#3408) ## Summary of the Pull Request Enables the `toggleFullscreen` action to be able to enter fullscreen mode, bound by default to <kbd>alt+enter</kbd>. The action is bubbled up to the WindowsTerminal (Win32) layer, where the window resizes itself to take the entire size of the monitor. This largely reuses code from conhost. Conhost already had a fullscreen mode, so I figured I might as well re-use that. ## References Unfortunately there are still very thin borders around the window when the NonClientIslandWindow is fullscreened. I think I know where the problem is. However, that area of code is about to get a massive overhaul with #3064, so I didn't want to necessarily make it worse right now. A follow up should be filed to add support for "Always show / reveal / never show tabs in fullscreen mode". Currently, the only mode is "never show tabs". Additionally, some of this code (particularily re:drawing the nonclient area) could be re-used for #2238. ## PR Checklist * [x] Closes #531, #3411 * [x] I work here * [n/a] Tests added/passed 😭 * [x] Requires documentation to be updated ## Validation Steps Performed * Manually tested both the NonClientIslandWindow and the IslandWindow. * Cherry-pick commit 8e56bfe * Don't draw the tab strip when maximized (cherry picked from commit bac4be7c0f3ed1cdcd4f9ae8980fc98103538613) * Fix the vista window flash for the NCIW (cherry picked from commit 7d3a18a893c02bd2ed75026f2aac52e20321a1cf) * Some code cleanup for review (cherry picked from commit 9e22b7730bba426adcbfd9e7025f192dbf8efb32) * A tad bit more notes and cleanup * Update schema, docs * Most of the PR comments * I'm not sure this actually works, so I'm committing it to revert it and check * Update some comments that were lost. * Fix a build break? * oh no
2019-11-05 20:40:29 +01:00
{
Fix restore window position when exiting fullscreen (#9737) <!-- 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 This change cleans up the Fullscreen implementation for both conhost and Terminal, improving the restore position (where the window goes when exiting fullscreen). Prior to this change the window wasn't guaranteed to restore somewhere on the window's current monitor when exiting fullscreen. With this change the window will restore always to its current monitor, at a reasonable location (and will 'double restore' (to fullscreen->maximize->restore) after monitor changes while fullscreen, which is the expected user behavior. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9746 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema 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 --> ## Detailed Description of the Pull Request / Additional comments A fullscreen window's monitor can change. - Win+Shift+left/right migrates a window between monitors. - User could open settings, display, and move the monitor or change its DPI. - The monitor could be unplugged. - The session could be remote and be disconnected. A fullscreen window stores a 'restore position' when entering fullscreen, used to move the window back 'where it was'. BUT, its unexpected for the window to exit fullscreen and jump to another monitor. This means its previous position must be migrated from the old monitor's work area to the new monitor's work area. If a window is maximized, it is sized to the work area. Like with fullscreen, a maximized window has a 'restore position', though unlike with fullscreen the restore position for maximized is stored by the system itself. Migration in cases where a maximized (or fullscreen) window's monitor changes is also taken care of by the system. To restore 'safely' to maximized (after changing window styles) a window must only `SetWindowPos(SWP_FRAMECHANGED)`. While technically a maximized window that becomes fullscreen 'is still maximized' (from Win32's perspective), its prudent to also `ShowWindow(SW_MAXIMIZED)` prior to `SWP_FRAMECHANGED` (to explicitly make the window maximized). If not restoring to maximized, the restore position is adjusted by the new/ old work area. Additionally, the new/ old window DPI is used to adjust the size of the window by the DPI change (keeping the window's logical size the same). - The work area origin is checked first (shifting window rect by the change in origin) - The DPI is checked next, changing right/ bottom (size only) - Each edge of the window is compared against the corresponding edge of the work area, nudging the window back on-screen if hanging offscreen. By shifting right before left, bottom before top, the top-left is guaranteed on-screen. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Tried it out. Seemed to work on my machine. Jk, ran conhost/ terminal on mixed DPI system, max (or not), fullscreen, win+shift+left/ exit fullscreen/ maximize. Monitor unplug, etc.
2021-04-13 18:33:00 +02:00
// Get the monitor info for the window's current monitor.
MONITORINFO mi = {};
mi.cbSize = sizeof(mi);
GetMonitorInfo(MonitorFromWindow(hWnd, MONITOR_DEFAULTTONEAREST), &mi);
if (_fullscreen)
Enable fullscreen mode (#3408) ## Summary of the Pull Request Enables the `toggleFullscreen` action to be able to enter fullscreen mode, bound by default to <kbd>alt+enter</kbd>. The action is bubbled up to the WindowsTerminal (Win32) layer, where the window resizes itself to take the entire size of the monitor. This largely reuses code from conhost. Conhost already had a fullscreen mode, so I figured I might as well re-use that. ## References Unfortunately there are still very thin borders around the window when the NonClientIslandWindow is fullscreened. I think I know where the problem is. However, that area of code is about to get a massive overhaul with #3064, so I didn't want to necessarily make it worse right now. A follow up should be filed to add support for "Always show / reveal / never show tabs in fullscreen mode". Currently, the only mode is "never show tabs". Additionally, some of this code (particularily re:drawing the nonclient area) could be re-used for #2238. ## PR Checklist * [x] Closes #531, #3411 * [x] I work here * [n/a] Tests added/passed 😭 * [x] Requires documentation to be updated ## Validation Steps Performed * Manually tested both the NonClientIslandWindow and the IslandWindow. * Cherry-pick commit 8e56bfe * Don't draw the tab strip when maximized (cherry picked from commit bac4be7c0f3ed1cdcd4f9ae8980fc98103538613) * Fix the vista window flash for the NCIW (cherry picked from commit 7d3a18a893c02bd2ed75026f2aac52e20321a1cf) * Some code cleanup for review (cherry picked from commit 9e22b7730bba426adcbfd9e7025f192dbf8efb32) * A tad bit more notes and cleanup * Update schema, docs * Most of the PR comments * I'm not sure this actually works, so I'm committing it to revert it and check * Update some comments that were lost. * Fix a build break? * oh no
2019-11-05 20:40:29 +01:00
{
Fix restore window position when exiting fullscreen (#9737) <!-- 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 This change cleans up the Fullscreen implementation for both conhost and Terminal, improving the restore position (where the window goes when exiting fullscreen). Prior to this change the window wasn't guaranteed to restore somewhere on the window's current monitor when exiting fullscreen. With this change the window will restore always to its current monitor, at a reasonable location (and will 'double restore' (to fullscreen->maximize->restore) after monitor changes while fullscreen, which is the expected user behavior. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9746 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema 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 --> ## Detailed Description of the Pull Request / Additional comments A fullscreen window's monitor can change. - Win+Shift+left/right migrates a window between monitors. - User could open settings, display, and move the monitor or change its DPI. - The monitor could be unplugged. - The session could be remote and be disconnected. A fullscreen window stores a 'restore position' when entering fullscreen, used to move the window back 'where it was'. BUT, its unexpected for the window to exit fullscreen and jump to another monitor. This means its previous position must be migrated from the old monitor's work area to the new monitor's work area. If a window is maximized, it is sized to the work area. Like with fullscreen, a maximized window has a 'restore position', though unlike with fullscreen the restore position for maximized is stored by the system itself. Migration in cases where a maximized (or fullscreen) window's monitor changes is also taken care of by the system. To restore 'safely' to maximized (after changing window styles) a window must only `SetWindowPos(SWP_FRAMECHANGED)`. While technically a maximized window that becomes fullscreen 'is still maximized' (from Win32's perspective), its prudent to also `ShowWindow(SW_MAXIMIZED)` prior to `SWP_FRAMECHANGED` (to explicitly make the window maximized). If not restoring to maximized, the restore position is adjusted by the new/ old work area. Additionally, the new/ old window DPI is used to adjust the size of the window by the DPI change (keeping the window's logical size the same). - The work area origin is checked first (shifting window rect by the change in origin) - The DPI is checked next, changing right/ bottom (size only) - Each edge of the window is compared against the corresponding edge of the work area, nudging the window back on-screen if hanging offscreen. By shifting right before left, bottom before top, the top-left is guaranteed on-screen. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Tried it out. Seemed to work on my machine. Jk, ran conhost/ terminal on mixed DPI system, max (or not), fullscreen, win+shift+left/ exit fullscreen/ maximize. Monitor unplug, etc.
2021-04-13 18:33:00 +02:00
// Store the window's current position and size the window to the monitor.
_SetFullscreenPosition(mi.rcMonitor, mi.rcWork);
Enable fullscreen mode (#3408) ## Summary of the Pull Request Enables the `toggleFullscreen` action to be able to enter fullscreen mode, bound by default to <kbd>alt+enter</kbd>. The action is bubbled up to the WindowsTerminal (Win32) layer, where the window resizes itself to take the entire size of the monitor. This largely reuses code from conhost. Conhost already had a fullscreen mode, so I figured I might as well re-use that. ## References Unfortunately there are still very thin borders around the window when the NonClientIslandWindow is fullscreened. I think I know where the problem is. However, that area of code is about to get a massive overhaul with #3064, so I didn't want to necessarily make it worse right now. A follow up should be filed to add support for "Always show / reveal / never show tabs in fullscreen mode". Currently, the only mode is "never show tabs". Additionally, some of this code (particularily re:drawing the nonclient area) could be re-used for #2238. ## PR Checklist * [x] Closes #531, #3411 * [x] I work here * [n/a] Tests added/passed 😭 * [x] Requires documentation to be updated ## Validation Steps Performed * Manually tested both the NonClientIslandWindow and the IslandWindow. * Cherry-pick commit 8e56bfe * Don't draw the tab strip when maximized (cherry picked from commit bac4be7c0f3ed1cdcd4f9ae8980fc98103538613) * Fix the vista window flash for the NCIW (cherry picked from commit 7d3a18a893c02bd2ed75026f2aac52e20321a1cf) * Some code cleanup for review (cherry picked from commit 9e22b7730bba426adcbfd9e7025f192dbf8efb32) * A tad bit more notes and cleanup * Update schema, docs * Most of the PR comments * I'm not sure this actually works, so I'm committing it to revert it and check * Update some comments that were lost. * Fix a build break? * oh no
2019-11-05 20:40:29 +01:00
}
Fix restore window position when exiting fullscreen (#9737) <!-- 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 This change cleans up the Fullscreen implementation for both conhost and Terminal, improving the restore position (where the window goes when exiting fullscreen). Prior to this change the window wasn't guaranteed to restore somewhere on the window's current monitor when exiting fullscreen. With this change the window will restore always to its current monitor, at a reasonable location (and will 'double restore' (to fullscreen->maximize->restore) after monitor changes while fullscreen, which is the expected user behavior. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9746 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema 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 --> ## Detailed Description of the Pull Request / Additional comments A fullscreen window's monitor can change. - Win+Shift+left/right migrates a window between monitors. - User could open settings, display, and move the monitor or change its DPI. - The monitor could be unplugged. - The session could be remote and be disconnected. A fullscreen window stores a 'restore position' when entering fullscreen, used to move the window back 'where it was'. BUT, its unexpected for the window to exit fullscreen and jump to another monitor. This means its previous position must be migrated from the old monitor's work area to the new monitor's work area. If a window is maximized, it is sized to the work area. Like with fullscreen, a maximized window has a 'restore position', though unlike with fullscreen the restore position for maximized is stored by the system itself. Migration in cases where a maximized (or fullscreen) window's monitor changes is also taken care of by the system. To restore 'safely' to maximized (after changing window styles) a window must only `SetWindowPos(SWP_FRAMECHANGED)`. While technically a maximized window that becomes fullscreen 'is still maximized' (from Win32's perspective), its prudent to also `ShowWindow(SW_MAXIMIZED)` prior to `SWP_FRAMECHANGED` (to explicitly make the window maximized). If not restoring to maximized, the restore position is adjusted by the new/ old work area. Additionally, the new/ old window DPI is used to adjust the size of the window by the DPI change (keeping the window's logical size the same). - The work area origin is checked first (shifting window rect by the change in origin) - The DPI is checked next, changing right/ bottom (size only) - Each edge of the window is compared against the corresponding edge of the work area, nudging the window back on-screen if hanging offscreen. By shifting right before left, bottom before top, the top-left is guaranteed on-screen. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Tried it out. Seemed to work on my machine. Jk, ran conhost/ terminal on mixed DPI system, max (or not), fullscreen, win+shift+left/ exit fullscreen/ maximize. Monitor unplug, etc.
2021-04-13 18:33:00 +02:00
else
Enable fullscreen mode (#3408) ## Summary of the Pull Request Enables the `toggleFullscreen` action to be able to enter fullscreen mode, bound by default to <kbd>alt+enter</kbd>. The action is bubbled up to the WindowsTerminal (Win32) layer, where the window resizes itself to take the entire size of the monitor. This largely reuses code from conhost. Conhost already had a fullscreen mode, so I figured I might as well re-use that. ## References Unfortunately there are still very thin borders around the window when the NonClientIslandWindow is fullscreened. I think I know where the problem is. However, that area of code is about to get a massive overhaul with #3064, so I didn't want to necessarily make it worse right now. A follow up should be filed to add support for "Always show / reveal / never show tabs in fullscreen mode". Currently, the only mode is "never show tabs". Additionally, some of this code (particularily re:drawing the nonclient area) could be re-used for #2238. ## PR Checklist * [x] Closes #531, #3411 * [x] I work here * [n/a] Tests added/passed 😭 * [x] Requires documentation to be updated ## Validation Steps Performed * Manually tested both the NonClientIslandWindow and the IslandWindow. * Cherry-pick commit 8e56bfe * Don't draw the tab strip when maximized (cherry picked from commit bac4be7c0f3ed1cdcd4f9ae8980fc98103538613) * Fix the vista window flash for the NCIW (cherry picked from commit 7d3a18a893c02bd2ed75026f2aac52e20321a1cf) * Some code cleanup for review (cherry picked from commit 9e22b7730bba426adcbfd9e7025f192dbf8efb32) * A tad bit more notes and cleanup * Update schema, docs * Most of the PR comments * I'm not sure this actually works, so I'm committing it to revert it and check * Update some comments that were lost. * Fix a build break? * oh no
2019-11-05 20:40:29 +01:00
{
Fix restore window position when exiting fullscreen (#9737) <!-- 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 This change cleans up the Fullscreen implementation for both conhost and Terminal, improving the restore position (where the window goes when exiting fullscreen). Prior to this change the window wasn't guaranteed to restore somewhere on the window's current monitor when exiting fullscreen. With this change the window will restore always to its current monitor, at a reasonable location (and will 'double restore' (to fullscreen->maximize->restore) after monitor changes while fullscreen, which is the expected user behavior. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9746 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema 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 --> ## Detailed Description of the Pull Request / Additional comments A fullscreen window's monitor can change. - Win+Shift+left/right migrates a window between monitors. - User could open settings, display, and move the monitor or change its DPI. - The monitor could be unplugged. - The session could be remote and be disconnected. A fullscreen window stores a 'restore position' when entering fullscreen, used to move the window back 'where it was'. BUT, its unexpected for the window to exit fullscreen and jump to another monitor. This means its previous position must be migrated from the old monitor's work area to the new monitor's work area. If a window is maximized, it is sized to the work area. Like with fullscreen, a maximized window has a 'restore position', though unlike with fullscreen the restore position for maximized is stored by the system itself. Migration in cases where a maximized (or fullscreen) window's monitor changes is also taken care of by the system. To restore 'safely' to maximized (after changing window styles) a window must only `SetWindowPos(SWP_FRAMECHANGED)`. While technically a maximized window that becomes fullscreen 'is still maximized' (from Win32's perspective), its prudent to also `ShowWindow(SW_MAXIMIZED)` prior to `SWP_FRAMECHANGED` (to explicitly make the window maximized). If not restoring to maximized, the restore position is adjusted by the new/ old work area. Additionally, the new/ old window DPI is used to adjust the size of the window by the DPI change (keeping the window's logical size the same). - The work area origin is checked first (shifting window rect by the change in origin) - The DPI is checked next, changing right/ bottom (size only) - Each edge of the window is compared against the corresponding edge of the work area, nudging the window back on-screen if hanging offscreen. By shifting right before left, bottom before top, the top-left is guaranteed on-screen. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Tried it out. Seemed to work on my machine. Jk, ran conhost/ terminal on mixed DPI system, max (or not), fullscreen, win+shift+left/ exit fullscreen/ maximize. Monitor unplug, etc.
2021-04-13 18:33:00 +02:00
// Restore the stored window position.
_RestoreFullscreenPosition(mi.rcWork);
Enable fullscreen mode (#3408) ## Summary of the Pull Request Enables the `toggleFullscreen` action to be able to enter fullscreen mode, bound by default to <kbd>alt+enter</kbd>. The action is bubbled up to the WindowsTerminal (Win32) layer, where the window resizes itself to take the entire size of the monitor. This largely reuses code from conhost. Conhost already had a fullscreen mode, so I figured I might as well re-use that. ## References Unfortunately there are still very thin borders around the window when the NonClientIslandWindow is fullscreened. I think I know where the problem is. However, that area of code is about to get a massive overhaul with #3064, so I didn't want to necessarily make it worse right now. A follow up should be filed to add support for "Always show / reveal / never show tabs in fullscreen mode". Currently, the only mode is "never show tabs". Additionally, some of this code (particularily re:drawing the nonclient area) could be re-used for #2238. ## PR Checklist * [x] Closes #531, #3411 * [x] I work here * [n/a] Tests added/passed 😭 * [x] Requires documentation to be updated ## Validation Steps Performed * Manually tested both the NonClientIslandWindow and the IslandWindow. * Cherry-pick commit 8e56bfe * Don't draw the tab strip when maximized (cherry picked from commit bac4be7c0f3ed1cdcd4f9ae8980fc98103538613) * Fix the vista window flash for the NCIW (cherry picked from commit 7d3a18a893c02bd2ed75026f2aac52e20321a1cf) * Some code cleanup for review (cherry picked from commit 9e22b7730bba426adcbfd9e7025f192dbf8efb32) * A tad bit more notes and cleanup * Update schema, docs * Most of the PR comments * I'm not sure this actually works, so I'm committing it to revert it and check * Update some comments that were lost. * Fix a build break? * oh no
2019-11-05 20:40:29 +01:00
}
}
}
2021-04-29 00:13:28 +02:00
// Method Description:
// - Call UnregisterHotKey once for each previously registered hotkey.
2021-04-29 00:13:28 +02:00
// Return Value:
// - <none>
void IslandWindow::UnregisterHotKey(const int index) noexcept
2021-04-29 00:13:28 +02:00
{
TraceLoggingWrite(
g_hWindowsTerminalProvider,
"UnregisterHotKey",
TraceLoggingDescription("Emitted when clearing previously set hotkeys"),
TraceLoggingInt64(index, "index", "the index of the hotkey to remove"),
TraceLoggingLevel(WINEVENT_LEVEL_VERBOSE),
TraceLoggingKeyword(TIL_KEYWORD_TRACE));
LOG_IF_WIN32_BOOL_FALSE(::UnregisterHotKey(_window.get(), index));
2021-04-29 00:13:28 +02:00
}
// Method Description:
// - Call RegisterHotKey to attempt to register that keybinding as a global hotkey.
2021-04-29 00:13:28 +02:00
// - When these keys are pressed, we'll get a WM_HOTKEY message with the payload
// containing the index we registered here.
// - Call UnregisterHotKey() before registering your hotkeys.
// See: https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-registerhotkey#remarks
2021-04-29 00:13:28 +02:00
// Arguments:
// - hotkey: The key-combination to register.
2021-04-29 00:13:28 +02:00
// Return Value:
// - <none>
bool IslandWindow::RegisterHotKey(const int index, const winrt::Microsoft::Terminal::Control::KeyChord& hotkey) noexcept
2021-04-29 00:13:28 +02:00
{
const auto vkey = hotkey.Vkey();
auto hotkeyFlags = MOD_NOREPEAT;
2021-04-29 00:13:28 +02:00
{
const auto modifiers = hotkey.Modifiers();
WI_SetFlagIf(hotkeyFlags, MOD_WIN, WI_IsFlagSet(modifiers, VirtualKeyModifiers::Windows));
WI_SetFlagIf(hotkeyFlags, MOD_ALT, WI_IsFlagSet(modifiers, VirtualKeyModifiers::Menu));
WI_SetFlagIf(hotkeyFlags, MOD_CONTROL, WI_IsFlagSet(modifiers, VirtualKeyModifiers::Control));
WI_SetFlagIf(hotkeyFlags, MOD_SHIFT, WI_IsFlagSet(modifiers, VirtualKeyModifiers::Shift));
2021-04-29 00:13:28 +02:00
}
// TODO GH#8888: We should display a warning of some kind if this fails.
// This can fail if something else already bound this hotkey.
const auto result = ::RegisterHotKey(_window.get(), index, hotkeyFlags, vkey);
LOG_IF_WIN32_BOOL_FALSE(result);
TraceLoggingWrite(g_hWindowsTerminalProvider,
"RegisterHotKey",
TraceLoggingDescription("Emitted when setting hotkeys"),
TraceLoggingInt64(index, "index", "the index of the hotkey to add"),
TraceLoggingUInt64(vkey, "vkey", "the key"),
TraceLoggingUInt64(WI_IsFlagSet(hotkeyFlags, MOD_WIN), "win", "is WIN in the modifiers"),
TraceLoggingUInt64(WI_IsFlagSet(hotkeyFlags, MOD_ALT), "alt", "is ALT in the modifiers"),
TraceLoggingUInt64(WI_IsFlagSet(hotkeyFlags, MOD_CONTROL), "control", "is CONTROL in the modifiers"),
TraceLoggingUInt64(WI_IsFlagSet(hotkeyFlags, MOD_SHIFT), "shift", "is SHIFT in the modifiers"),
TraceLoggingBool(result, "succeeded", "true if we succeeded"),
TraceLoggingLevel(WINEVENT_LEVEL_VERBOSE),
TraceLoggingKeyword(TIL_KEYWORD_TRACE));
return result;
2021-04-29 00:13:28 +02:00
}
// Method Description:
// - Summon the window, or possibly dismiss it. If toggleVisibility is true,
// then we'll dismiss (minimize) the window if it's currently active.
// Otherwise, we'll always just try to activate the window.
// Arguments:
// - toggleVisibility: controls how we should behave when already in the foreground.
// Return Value:
// - <none>
Add `"monitor": "any"|"toCurrent"|"toMouse"` setting to globalSummon (#10092) #### ⚠️ this pr targets #9977 ## Summary of the Pull Request This adds support for part of the `monitor` property for `globalSummon`. It also goes a little off-spec: ```json "monitor": "any"|"toCurrent"|"toMouse" ``` * `monitor`: This controls the monitor that the window will be summoned from/to - `"any"`: Summon the MRU window, regardless of which monitor it's currently on. - `"toCurrent"`/omitted: (_default_): Summon the MRU window **TO** the monitor with the current **foreground** window. - [**NEW**] `"toMouse"`: Summon the MRU window **TO** the monitor where the **mouse** cursor is. When I was playing with this, It felt like `toMouse` was always what I wanted, not `toCurrent`. We can always just comment that out if we think that's contentious - I'm aware I didn't originally spec that. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-60325291 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated 😢 ## Detailed Description of the Pull Request / Additional comments I made `toMouse` the default because it felt better. fite-me.jpg ## Validation Steps Performed my ever evolving blob: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-17 14:57:08 +02:00
winrt::fire_and_forget IslandWindow::SummonWindow(Remoting::SummonWindowBehavior args)
{
// On the foreground thread:
co_await winrt::resume_foreground(_rootGrid.Dispatcher());
_summonWindowRoutineBody(args);
}
// Method Description:
// - As above.
// BODGY: ARM64 BUILD FAILED WITH fatal error C1001: Internal compiler error
// when this was part of the coroutine body.
void IslandWindow::_summonWindowRoutineBody(Remoting::SummonWindowBehavior args)
{
Add `"monitor": "any"|"toCurrent"|"toMouse"` setting to globalSummon (#10092) #### ⚠️ this pr targets #9977 ## Summary of the Pull Request This adds support for part of the `monitor` property for `globalSummon`. It also goes a little off-spec: ```json "monitor": "any"|"toCurrent"|"toMouse" ``` * `monitor`: This controls the monitor that the window will be summoned from/to - `"any"`: Summon the MRU window, regardless of which monitor it's currently on. - `"toCurrent"`/omitted: (_default_): Summon the MRU window **TO** the monitor with the current **foreground** window. - [**NEW**] `"toMouse"`: Summon the MRU window **TO** the monitor where the **mouse** cursor is. When I was playing with this, It felt like `toMouse` was always what I wanted, not `toCurrent`. We can always just comment that out if we think that's contentious - I'm aware I didn't originally spec that. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-60325291 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated 😢 ## Detailed Description of the Pull Request / Additional comments I made `toMouse` the default because it felt better. fite-me.jpg ## Validation Steps Performed my ever evolving blob: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-17 14:57:08 +02:00
uint32_t actualDropdownDuration = args.DropdownDuration();
Add property to control dropdown speed of global summon (#9977) ## Summary of the Pull Request Adds the `dropdownDuration` property to `globalSummon`. This controls how fast the window appears on the screen when summoned from minimized. It similarly controls the speed for sliding out of view when the window is dismissed with `"toggleVisibility": true`. `dropdownDuration` specifies the duration in **milliseconds**. This defaults to `0` for `globalSummon`, and defaults to `200` for `quakeMode`. 200 was picked because, according to [`AnimateWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-animatewindow): > Typically, an animation takes 200 milliseconds to play. Do note that you won't be able to interact with the window during the animation! Input sent during the dropdown will arrive at the end of the animation, but input sent during the slide-up _won't_. Avoid setting this to large values! The gifs are in Teams. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-59030824 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I had the following previously in the doc comments, but it feels better in the PR body: - This was chosen because it was easier to implement and generally nicer than: * `AnimateWindow`, which would show the window borders for the duration of the animation, and occasionally just plain not work. Additionally, for `AnimateWindow` to work, the window much not be visible, so we'd need to first restore the window, then hide it, then animate it. That would flash the taskbar. * `SetWindowRgn` on the root HWND, which caused the xaml content to shift to the left, and caused a black bar to be drawn on the right of the window. Presumably, `SetWindowRgn` and `DwmExtendFrameIntoClientArea` did not play well with each other. * `SetWindowPos(..., SWP_NOSENDCHANGING)`, which worked the absolute best for longer animations, and is the closest to the actual implementation of `AnimateWindow`. This would resize the ROOT window, without sending resizes to the XAML island, allowing the content to _not_ reflow. but for a duration of 200ms, would only ever display ~2 frames. That's basically not even animation anymore, it's now just an "appear". Since that's how long the default animation is, if felt silly to have it basically not work by default. - If a future reader would like to implement this better, **they should feel free to**, and not mistake my notes here as expertise. These are research notes into the dark and terrible land that is Win32 programming. I'm no expert. ## Validation Steps Performed This is the blob of json I'm testing with these days: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, ``` * <kbd>ctrl+\`</kbd> will summon the quake window with a _quick_ animation * <kbd>ctrl+2</kbd> will summon the window with a s l o w animation
2021-05-17 14:28:46 +02:00
// If the user requested an animation, let's check if animations are enabled in the OS.
if (actualDropdownDuration > 0)
Add property to control dropdown speed of global summon (#9977) ## Summary of the Pull Request Adds the `dropdownDuration` property to `globalSummon`. This controls how fast the window appears on the screen when summoned from minimized. It similarly controls the speed for sliding out of view when the window is dismissed with `"toggleVisibility": true`. `dropdownDuration` specifies the duration in **milliseconds**. This defaults to `0` for `globalSummon`, and defaults to `200` for `quakeMode`. 200 was picked because, according to [`AnimateWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-animatewindow): > Typically, an animation takes 200 milliseconds to play. Do note that you won't be able to interact with the window during the animation! Input sent during the dropdown will arrive at the end of the animation, but input sent during the slide-up _won't_. Avoid setting this to large values! The gifs are in Teams. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-59030824 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I had the following previously in the doc comments, but it feels better in the PR body: - This was chosen because it was easier to implement and generally nicer than: * `AnimateWindow`, which would show the window borders for the duration of the animation, and occasionally just plain not work. Additionally, for `AnimateWindow` to work, the window much not be visible, so we'd need to first restore the window, then hide it, then animate it. That would flash the taskbar. * `SetWindowRgn` on the root HWND, which caused the xaml content to shift to the left, and caused a black bar to be drawn on the right of the window. Presumably, `SetWindowRgn` and `DwmExtendFrameIntoClientArea` did not play well with each other. * `SetWindowPos(..., SWP_NOSENDCHANGING)`, which worked the absolute best for longer animations, and is the closest to the actual implementation of `AnimateWindow`. This would resize the ROOT window, without sending resizes to the XAML island, allowing the content to _not_ reflow. but for a duration of 200ms, would only ever display ~2 frames. That's basically not even animation anymore, it's now just an "appear". Since that's how long the default animation is, if felt silly to have it basically not work by default. - If a future reader would like to implement this better, **they should feel free to**, and not mistake my notes here as expertise. These are research notes into the dark and terrible land that is Win32 programming. I'm no expert. ## Validation Steps Performed This is the blob of json I'm testing with these days: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, ``` * <kbd>ctrl+\`</kbd> will summon the quake window with a _quick_ animation * <kbd>ctrl+2</kbd> will summon the window with a s l o w animation
2021-05-17 14:28:46 +02:00
{
BOOL animationsEnabled = TRUE;
SystemParametersInfoW(SPI_GETCLIENTAREAANIMATION, 0, &animationsEnabled, 0);
if (!animationsEnabled)
{
// The OS has animations disabled - we should respect that and
// disable the animation here.
//
// We're doing this here, rather than in _doSlideAnimation, to
// preempt any other specific behavior that
// _globalActivateWindow/_globalDismissWindow might do if they think
// there should be an animation (like making the window appear with
// SetWindowPlacement rather than ShowWindow)
actualDropdownDuration = 0;
}
}
// * If the user doesn't want to toggleVisibility, then just always try to
// activate.
Add `"monitor": "any"|"toCurrent"|"toMouse"` setting to globalSummon (#10092) #### ⚠️ this pr targets #9977 ## Summary of the Pull Request This adds support for part of the `monitor` property for `globalSummon`. It also goes a little off-spec: ```json "monitor": "any"|"toCurrent"|"toMouse" ``` * `monitor`: This controls the monitor that the window will be summoned from/to - `"any"`: Summon the MRU window, regardless of which monitor it's currently on. - `"toCurrent"`/omitted: (_default_): Summon the MRU window **TO** the monitor with the current **foreground** window. - [**NEW**] `"toMouse"`: Summon the MRU window **TO** the monitor where the **mouse** cursor is. When I was playing with this, It felt like `toMouse` was always what I wanted, not `toCurrent`. We can always just comment that out if we think that's contentious - I'm aware I didn't originally spec that. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-60325291 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated 😢 ## Detailed Description of the Pull Request / Additional comments I made `toMouse` the default because it felt better. fite-me.jpg ## Validation Steps Performed my ever evolving blob: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-17 14:57:08 +02:00
// * If the user does want to toggleVisibility,
// - If we're the foreground window, ToMonitor == ToMouse, and the mouse is on the monitor we are
// - activate the window
// - else
// - dismiss the window
if (args.ToggleVisibility() && GetForegroundWindow() == _window.get())
{
Add `"monitor": "any"|"toCurrent"|"toMouse"` setting to globalSummon (#10092) #### ⚠️ this pr targets #9977 ## Summary of the Pull Request This adds support for part of the `monitor` property for `globalSummon`. It also goes a little off-spec: ```json "monitor": "any"|"toCurrent"|"toMouse" ``` * `monitor`: This controls the monitor that the window will be summoned from/to - `"any"`: Summon the MRU window, regardless of which monitor it's currently on. - `"toCurrent"`/omitted: (_default_): Summon the MRU window **TO** the monitor with the current **foreground** window. - [**NEW**] `"toMouse"`: Summon the MRU window **TO** the monitor where the **mouse** cursor is. When I was playing with this, It felt like `toMouse` was always what I wanted, not `toCurrent`. We can always just comment that out if we think that's contentious - I'm aware I didn't originally spec that. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-60325291 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated 😢 ## Detailed Description of the Pull Request / Additional comments I made `toMouse` the default because it felt better. fite-me.jpg ## Validation Steps Performed my ever evolving blob: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-17 14:57:08 +02:00
bool handled = false;
// They want to toggle the window when it is the FG window, and we are
// the FG window. However, if we're on a different monitor than the
// mouse, then we should move to that monitor instead of dismissing.
if (args.ToMonitor() == Remoting::MonitorBehavior::ToMouse)
{
const til::rectangle cursorMonitorRect{ _getMonitorForCursor().rcMonitor };
const til::rectangle currentMonitorRect{ _getMonitorForWindow(GetHandle()).rcMonitor };
if (cursorMonitorRect != currentMonitorRect)
{
// We're not on the same monitor as the mouse. Go to that monitor.
_globalActivateWindow(actualDropdownDuration, args.ToMonitor());
handled = true;
}
}
if (!handled)
{
_globalDismissWindow(actualDropdownDuration);
}
}
else
{
Add `"monitor": "any"|"toCurrent"|"toMouse"` setting to globalSummon (#10092) #### ⚠️ this pr targets #9977 ## Summary of the Pull Request This adds support for part of the `monitor` property for `globalSummon`. It also goes a little off-spec: ```json "monitor": "any"|"toCurrent"|"toMouse" ``` * `monitor`: This controls the monitor that the window will be summoned from/to - `"any"`: Summon the MRU window, regardless of which monitor it's currently on. - `"toCurrent"`/omitted: (_default_): Summon the MRU window **TO** the monitor with the current **foreground** window. - [**NEW**] `"toMouse"`: Summon the MRU window **TO** the monitor where the **mouse** cursor is. When I was playing with this, It felt like `toMouse` was always what I wanted, not `toCurrent`. We can always just comment that out if we think that's contentious - I'm aware I didn't originally spec that. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-60325291 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated 😢 ## Detailed Description of the Pull Request / Additional comments I made `toMouse` the default because it felt better. fite-me.jpg ## Validation Steps Performed my ever evolving blob: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-17 14:57:08 +02:00
_globalActivateWindow(actualDropdownDuration, args.ToMonitor());
}
}
Add property to control dropdown speed of global summon (#9977) ## Summary of the Pull Request Adds the `dropdownDuration` property to `globalSummon`. This controls how fast the window appears on the screen when summoned from minimized. It similarly controls the speed for sliding out of view when the window is dismissed with `"toggleVisibility": true`. `dropdownDuration` specifies the duration in **milliseconds**. This defaults to `0` for `globalSummon`, and defaults to `200` for `quakeMode`. 200 was picked because, according to [`AnimateWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-animatewindow): > Typically, an animation takes 200 milliseconds to play. Do note that you won't be able to interact with the window during the animation! Input sent during the dropdown will arrive at the end of the animation, but input sent during the slide-up _won't_. Avoid setting this to large values! The gifs are in Teams. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-59030824 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I had the following previously in the doc comments, but it feels better in the PR body: - This was chosen because it was easier to implement and generally nicer than: * `AnimateWindow`, which would show the window borders for the duration of the animation, and occasionally just plain not work. Additionally, for `AnimateWindow` to work, the window much not be visible, so we'd need to first restore the window, then hide it, then animate it. That would flash the taskbar. * `SetWindowRgn` on the root HWND, which caused the xaml content to shift to the left, and caused a black bar to be drawn on the right of the window. Presumably, `SetWindowRgn` and `DwmExtendFrameIntoClientArea` did not play well with each other. * `SetWindowPos(..., SWP_NOSENDCHANGING)`, which worked the absolute best for longer animations, and is the closest to the actual implementation of `AnimateWindow`. This would resize the ROOT window, without sending resizes to the XAML island, allowing the content to _not_ reflow. but for a duration of 200ms, would only ever display ~2 frames. That's basically not even animation anymore, it's now just an "appear". Since that's how long the default animation is, if felt silly to have it basically not work by default. - If a future reader would like to implement this better, **they should feel free to**, and not mistake my notes here as expertise. These are research notes into the dark and terrible land that is Win32 programming. I'm no expert. ## Validation Steps Performed This is the blob of json I'm testing with these days: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, ``` * <kbd>ctrl+\`</kbd> will summon the quake window with a _quick_ animation * <kbd>ctrl+2</kbd> will summon the window with a s l o w animation
2021-05-17 14:28:46 +02:00
// Method Description:
// - Helper for performing a sliding animation. This will animate our _Xaml
// Island_, either growing down or shrinking up, using SetWindowRgn.
// - This function does the entire animation on the main thread (the UI thread),
// and **DOES NOT YIELD IT**. The window will be animating for the entire
// duration of dropdownDuration.
// - At the end of the animation, we'll reset the window region, so that it's as
// if nothing occurred.
// Arguments:
// - dropdownDuration: The duration to play the animation, in milliseconds. If
// 0, we won't perform a dropdown animation.
// - down: if true, increase the height from top to bottom. otherwise, decrease
// the height, from bottom to top.
// Return Value:
// - <none>
void IslandWindow::_doSlideAnimation(const uint32_t dropdownDuration, const bool down)
{
til::rectangle fullWindowSize{ GetWindowRect() };
const double fullHeight = fullWindowSize.height<double>();
const double animationDuration = dropdownDuration; // use floating-point math throughout
const auto start = std::chrono::system_clock::now();
// Do at most dropdownDuration frames. After that, just bail straight to the
// final state.
for (uint32_t i = 0; i < dropdownDuration; i++)
{
const auto end = std::chrono::system_clock::now();
const auto millis = std::chrono::duration_cast<std::chrono::milliseconds>(end - start);
const double dt = ::base::saturated_cast<double>(millis.count());
if (dt > animationDuration)
{
break;
}
// If going down, increase the height over time. If going up, decrease the height.
const double currentHeight = ::base::saturated_cast<double>(
down ? ((dt / animationDuration) * fullHeight) :
((1.0 - (dt / animationDuration)) * fullHeight));
wil::unique_hrgn rgn{ CreateRectRgn(0,
0,
fullWindowSize.width<int>(),
::base::saturated_cast<int>(currentHeight)) };
SetWindowRgn(_interopWindowHandle, rgn.get(), true);
// Go immediately into another frame. This prevents the window from
// doing anything else (tearing our state). A Sleep() here will cause a
// weird stutter, and causes the animation to not be as smooth.
}
// Reset the window.
SetWindowRgn(_interopWindowHandle, nullptr, true);
}
Add `"monitor": "any"|"toCurrent"|"toMouse"` setting to globalSummon (#10092) #### ⚠️ this pr targets #9977 ## Summary of the Pull Request This adds support for part of the `monitor` property for `globalSummon`. It also goes a little off-spec: ```json "monitor": "any"|"toCurrent"|"toMouse" ``` * `monitor`: This controls the monitor that the window will be summoned from/to - `"any"`: Summon the MRU window, regardless of which monitor it's currently on. - `"toCurrent"`/omitted: (_default_): Summon the MRU window **TO** the monitor with the current **foreground** window. - [**NEW**] `"toMouse"`: Summon the MRU window **TO** the monitor where the **mouse** cursor is. When I was playing with this, It felt like `toMouse` was always what I wanted, not `toCurrent`. We can always just comment that out if we think that's contentious - I'm aware I didn't originally spec that. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-60325291 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated 😢 ## Detailed Description of the Pull Request / Additional comments I made `toMouse` the default because it felt better. fite-me.jpg ## Validation Steps Performed my ever evolving blob: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-17 14:57:08 +02:00
void IslandWindow::_dropdownWindow(const uint32_t dropdownDuration,
const Remoting::MonitorBehavior toMonitor)
Add property to control dropdown speed of global summon (#9977) ## Summary of the Pull Request Adds the `dropdownDuration` property to `globalSummon`. This controls how fast the window appears on the screen when summoned from minimized. It similarly controls the speed for sliding out of view when the window is dismissed with `"toggleVisibility": true`. `dropdownDuration` specifies the duration in **milliseconds**. This defaults to `0` for `globalSummon`, and defaults to `200` for `quakeMode`. 200 was picked because, according to [`AnimateWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-animatewindow): > Typically, an animation takes 200 milliseconds to play. Do note that you won't be able to interact with the window during the animation! Input sent during the dropdown will arrive at the end of the animation, but input sent during the slide-up _won't_. Avoid setting this to large values! The gifs are in Teams. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-59030824 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I had the following previously in the doc comments, but it feels better in the PR body: - This was chosen because it was easier to implement and generally nicer than: * `AnimateWindow`, which would show the window borders for the duration of the animation, and occasionally just plain not work. Additionally, for `AnimateWindow` to work, the window much not be visible, so we'd need to first restore the window, then hide it, then animate it. That would flash the taskbar. * `SetWindowRgn` on the root HWND, which caused the xaml content to shift to the left, and caused a black bar to be drawn on the right of the window. Presumably, `SetWindowRgn` and `DwmExtendFrameIntoClientArea` did not play well with each other. * `SetWindowPos(..., SWP_NOSENDCHANGING)`, which worked the absolute best for longer animations, and is the closest to the actual implementation of `AnimateWindow`. This would resize the ROOT window, without sending resizes to the XAML island, allowing the content to _not_ reflow. but for a duration of 200ms, would only ever display ~2 frames. That's basically not even animation anymore, it's now just an "appear". Since that's how long the default animation is, if felt silly to have it basically not work by default. - If a future reader would like to implement this better, **they should feel free to**, and not mistake my notes here as expertise. These are research notes into the dark and terrible land that is Win32 programming. I'm no expert. ## Validation Steps Performed This is the blob of json I'm testing with these days: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, ``` * <kbd>ctrl+\`</kbd> will summon the quake window with a _quick_ animation * <kbd>ctrl+2</kbd> will summon the window with a s l o w animation
2021-05-17 14:28:46 +02:00
{
Add `"monitor": "any"|"toCurrent"|"toMouse"` setting to globalSummon (#10092) #### ⚠️ this pr targets #9977 ## Summary of the Pull Request This adds support for part of the `monitor` property for `globalSummon`. It also goes a little off-spec: ```json "monitor": "any"|"toCurrent"|"toMouse" ``` * `monitor`: This controls the monitor that the window will be summoned from/to - `"any"`: Summon the MRU window, regardless of which monitor it's currently on. - `"toCurrent"`/omitted: (_default_): Summon the MRU window **TO** the monitor with the current **foreground** window. - [**NEW**] `"toMouse"`: Summon the MRU window **TO** the monitor where the **mouse** cursor is. When I was playing with this, It felt like `toMouse` was always what I wanted, not `toCurrent`. We can always just comment that out if we think that's contentious - I'm aware I didn't originally spec that. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-60325291 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated 😢 ## Detailed Description of the Pull Request / Additional comments I made `toMouse` the default because it felt better. fite-me.jpg ## Validation Steps Performed my ever evolving blob: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-17 14:57:08 +02:00
// First, get the window that's currently in the foreground. We'll need
// _this_ window to be able to appear on top of. If we just use
// GetForegroundWindow afer the SetWindowPlacement call, _we_ will be the
// foreground window.
const auto oldForegroundWindow = GetForegroundWindow();
Add property to control dropdown speed of global summon (#9977) ## Summary of the Pull Request Adds the `dropdownDuration` property to `globalSummon`. This controls how fast the window appears on the screen when summoned from minimized. It similarly controls the speed for sliding out of view when the window is dismissed with `"toggleVisibility": true`. `dropdownDuration` specifies the duration in **milliseconds**. This defaults to `0` for `globalSummon`, and defaults to `200` for `quakeMode`. 200 was picked because, according to [`AnimateWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-animatewindow): > Typically, an animation takes 200 milliseconds to play. Do note that you won't be able to interact with the window during the animation! Input sent during the dropdown will arrive at the end of the animation, but input sent during the slide-up _won't_. Avoid setting this to large values! The gifs are in Teams. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-59030824 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I had the following previously in the doc comments, but it feels better in the PR body: - This was chosen because it was easier to implement and generally nicer than: * `AnimateWindow`, which would show the window borders for the duration of the animation, and occasionally just plain not work. Additionally, for `AnimateWindow` to work, the window much not be visible, so we'd need to first restore the window, then hide it, then animate it. That would flash the taskbar. * `SetWindowRgn` on the root HWND, which caused the xaml content to shift to the left, and caused a black bar to be drawn on the right of the window. Presumably, `SetWindowRgn` and `DwmExtendFrameIntoClientArea` did not play well with each other. * `SetWindowPos(..., SWP_NOSENDCHANGING)`, which worked the absolute best for longer animations, and is the closest to the actual implementation of `AnimateWindow`. This would resize the ROOT window, without sending resizes to the XAML island, allowing the content to _not_ reflow. but for a duration of 200ms, would only ever display ~2 frames. That's basically not even animation anymore, it's now just an "appear". Since that's how long the default animation is, if felt silly to have it basically not work by default. - If a future reader would like to implement this better, **they should feel free to**, and not mistake my notes here as expertise. These are research notes into the dark and terrible land that is Win32 programming. I'm no expert. ## Validation Steps Performed This is the blob of json I'm testing with these days: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, ``` * <kbd>ctrl+\`</kbd> will summon the quake window with a _quick_ animation * <kbd>ctrl+2</kbd> will summon the window with a s l o w animation
2021-05-17 14:28:46 +02:00
// First, restore the window. SetWindowPlacement has a fun undocumented
// piece of functionality where it will restore the window position
// _without_ the animation, so use that instead of ShowWindow(SW_RESTORE).
WINDOWPLACEMENT wpc{};
wpc.length = sizeof(WINDOWPLACEMENT);
GetWindowPlacement(_window.get(), &wpc);
Hide `_quake` window on minimize ALWAYS (#10113) ## Summary of the Pull Request This is a scoped implementation of "hide on minimize", only to the `_quake` window. When minimized, the `_quake` window won't appear in the taskbar. IT ALSO WON'T APPEAR IN THE TRAY, BECAUSE WE DON'T HAVE ONE YET. I talked about this with @DHowett, and it seemed cool. Other windows will still minimize normally. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 * minimize to tray: #5727 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-61246940 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated - probably yea, but something <sub>something <sub>something</sub></sub> ## Detailed Description of the Pull Request / Additional comments After playing with it, it is in fact, cool. ALSO `LOG_IF_WIN32_BOOL_FALSE` should DEFINITELY not be used with `ShowWindow`. [`ShowWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-showwindow#return-value) returns false if the window was previously hidden, but doesn't `SetLastError`, so that macro will _throw_. ## Validation Steps Performed ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon", "name": "_quake" } }, // { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-18 12:44:42 +02:00
// If the window is hidden, SW_SHOW it first.
if (!IsWindowVisible(GetHandle()))
{
wpc.showCmd = SW_SHOW;
SetWindowPlacement(_window.get(), &wpc);
}
Add property to control dropdown speed of global summon (#9977) ## Summary of the Pull Request Adds the `dropdownDuration` property to `globalSummon`. This controls how fast the window appears on the screen when summoned from minimized. It similarly controls the speed for sliding out of view when the window is dismissed with `"toggleVisibility": true`. `dropdownDuration` specifies the duration in **milliseconds**. This defaults to `0` for `globalSummon`, and defaults to `200` for `quakeMode`. 200 was picked because, according to [`AnimateWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-animatewindow): > Typically, an animation takes 200 milliseconds to play. Do note that you won't be able to interact with the window during the animation! Input sent during the dropdown will arrive at the end of the animation, but input sent during the slide-up _won't_. Avoid setting this to large values! The gifs are in Teams. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-59030824 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I had the following previously in the doc comments, but it feels better in the PR body: - This was chosen because it was easier to implement and generally nicer than: * `AnimateWindow`, which would show the window borders for the duration of the animation, and occasionally just plain not work. Additionally, for `AnimateWindow` to work, the window much not be visible, so we'd need to first restore the window, then hide it, then animate it. That would flash the taskbar. * `SetWindowRgn` on the root HWND, which caused the xaml content to shift to the left, and caused a black bar to be drawn on the right of the window. Presumably, `SetWindowRgn` and `DwmExtendFrameIntoClientArea` did not play well with each other. * `SetWindowPos(..., SWP_NOSENDCHANGING)`, which worked the absolute best for longer animations, and is the closest to the actual implementation of `AnimateWindow`. This would resize the ROOT window, without sending resizes to the XAML island, allowing the content to _not_ reflow. but for a duration of 200ms, would only ever display ~2 frames. That's basically not even animation anymore, it's now just an "appear". Since that's how long the default animation is, if felt silly to have it basically not work by default. - If a future reader would like to implement this better, **they should feel free to**, and not mistake my notes here as expertise. These are research notes into the dark and terrible land that is Win32 programming. I'm no expert. ## Validation Steps Performed This is the blob of json I'm testing with these days: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, ``` * <kbd>ctrl+\`</kbd> will summon the quake window with a _quick_ animation * <kbd>ctrl+2</kbd> will summon the window with a s l o w animation
2021-05-17 14:28:46 +02:00
wpc.showCmd = SW_RESTORE;
SetWindowPlacement(_window.get(), &wpc);
Add `"monitor": "any"|"toCurrent"|"toMouse"` setting to globalSummon (#10092) #### ⚠️ this pr targets #9977 ## Summary of the Pull Request This adds support for part of the `monitor` property for `globalSummon`. It also goes a little off-spec: ```json "monitor": "any"|"toCurrent"|"toMouse" ``` * `monitor`: This controls the monitor that the window will be summoned from/to - `"any"`: Summon the MRU window, regardless of which monitor it's currently on. - `"toCurrent"`/omitted: (_default_): Summon the MRU window **TO** the monitor with the current **foreground** window. - [**NEW**] `"toMouse"`: Summon the MRU window **TO** the monitor where the **mouse** cursor is. When I was playing with this, It felt like `toMouse` was always what I wanted, not `toCurrent`. We can always just comment that out if we think that's contentious - I'm aware I didn't originally spec that. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-60325291 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated 😢 ## Detailed Description of the Pull Request / Additional comments I made `toMouse` the default because it felt better. fite-me.jpg ## Validation Steps Performed my ever evolving blob: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-17 14:57:08 +02:00
// Possibly go to the monitor of the mouse / old foreground window.
_moveToMonitor(oldForegroundWindow, toMonitor);
Add property to control dropdown speed of global summon (#9977) ## Summary of the Pull Request Adds the `dropdownDuration` property to `globalSummon`. This controls how fast the window appears on the screen when summoned from minimized. It similarly controls the speed for sliding out of view when the window is dismissed with `"toggleVisibility": true`. `dropdownDuration` specifies the duration in **milliseconds**. This defaults to `0` for `globalSummon`, and defaults to `200` for `quakeMode`. 200 was picked because, according to [`AnimateWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-animatewindow): > Typically, an animation takes 200 milliseconds to play. Do note that you won't be able to interact with the window during the animation! Input sent during the dropdown will arrive at the end of the animation, but input sent during the slide-up _won't_. Avoid setting this to large values! The gifs are in Teams. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-59030824 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I had the following previously in the doc comments, but it feels better in the PR body: - This was chosen because it was easier to implement and generally nicer than: * `AnimateWindow`, which would show the window borders for the duration of the animation, and occasionally just plain not work. Additionally, for `AnimateWindow` to work, the window much not be visible, so we'd need to first restore the window, then hide it, then animate it. That would flash the taskbar. * `SetWindowRgn` on the root HWND, which caused the xaml content to shift to the left, and caused a black bar to be drawn on the right of the window. Presumably, `SetWindowRgn` and `DwmExtendFrameIntoClientArea` did not play well with each other. * `SetWindowPos(..., SWP_NOSENDCHANGING)`, which worked the absolute best for longer animations, and is the closest to the actual implementation of `AnimateWindow`. This would resize the ROOT window, without sending resizes to the XAML island, allowing the content to _not_ reflow. but for a duration of 200ms, would only ever display ~2 frames. That's basically not even animation anymore, it's now just an "appear". Since that's how long the default animation is, if felt silly to have it basically not work by default. - If a future reader would like to implement this better, **they should feel free to**, and not mistake my notes here as expertise. These are research notes into the dark and terrible land that is Win32 programming. I'm no expert. ## Validation Steps Performed This is the blob of json I'm testing with these days: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, ``` * <kbd>ctrl+\`</kbd> will summon the quake window with a _quick_ animation * <kbd>ctrl+2</kbd> will summon the window with a s l o w animation
2021-05-17 14:28:46 +02:00
// Now that we're visible, animate the dropdown.
_doSlideAnimation(dropdownDuration, true);
}
void IslandWindow::_slideUpWindow(const uint32_t dropdownDuration)
{
// First, animate the window sliding up.
_doSlideAnimation(dropdownDuration, false);
// Then, use SetWindowPlacement to minimize without the animation.
WINDOWPLACEMENT wpc{};
wpc.length = sizeof(WINDOWPLACEMENT);
GetWindowPlacement(_window.get(), &wpc);
wpc.showCmd = SW_MINIMIZE;
SetWindowPlacement(_window.get(), &wpc);
}
// Method Description:
// - Force activate this window. This method will bring us to the foreground and
// activate us. If the window is minimized, it will restore the window. If the
// window is on another desktop, the OS will switch to that desktop.
Add property to control dropdown speed of global summon (#9977) ## Summary of the Pull Request Adds the `dropdownDuration` property to `globalSummon`. This controls how fast the window appears on the screen when summoned from minimized. It similarly controls the speed for sliding out of view when the window is dismissed with `"toggleVisibility": true`. `dropdownDuration` specifies the duration in **milliseconds**. This defaults to `0` for `globalSummon`, and defaults to `200` for `quakeMode`. 200 was picked because, according to [`AnimateWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-animatewindow): > Typically, an animation takes 200 milliseconds to play. Do note that you won't be able to interact with the window during the animation! Input sent during the dropdown will arrive at the end of the animation, but input sent during the slide-up _won't_. Avoid setting this to large values! The gifs are in Teams. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-59030824 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I had the following previously in the doc comments, but it feels better in the PR body: - This was chosen because it was easier to implement and generally nicer than: * `AnimateWindow`, which would show the window borders for the duration of the animation, and occasionally just plain not work. Additionally, for `AnimateWindow` to work, the window much not be visible, so we'd need to first restore the window, then hide it, then animate it. That would flash the taskbar. * `SetWindowRgn` on the root HWND, which caused the xaml content to shift to the left, and caused a black bar to be drawn on the right of the window. Presumably, `SetWindowRgn` and `DwmExtendFrameIntoClientArea` did not play well with each other. * `SetWindowPos(..., SWP_NOSENDCHANGING)`, which worked the absolute best for longer animations, and is the closest to the actual implementation of `AnimateWindow`. This would resize the ROOT window, without sending resizes to the XAML island, allowing the content to _not_ reflow. but for a duration of 200ms, would only ever display ~2 frames. That's basically not even animation anymore, it's now just an "appear". Since that's how long the default animation is, if felt silly to have it basically not work by default. - If a future reader would like to implement this better, **they should feel free to**, and not mistake my notes here as expertise. These are research notes into the dark and terrible land that is Win32 programming. I'm no expert. ## Validation Steps Performed This is the blob of json I'm testing with these days: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, ``` * <kbd>ctrl+\`</kbd> will summon the quake window with a _quick_ animation * <kbd>ctrl+2</kbd> will summon the window with a s l o w animation
2021-05-17 14:28:46 +02:00
// - If the window is minimized, and dropdownDuration is greater than 0, we'll
// perform a "slide in" animation. We won't do this if the window is already
// on the screen (since that seems silly).
// Arguments:
Add property to control dropdown speed of global summon (#9977) ## Summary of the Pull Request Adds the `dropdownDuration` property to `globalSummon`. This controls how fast the window appears on the screen when summoned from minimized. It similarly controls the speed for sliding out of view when the window is dismissed with `"toggleVisibility": true`. `dropdownDuration` specifies the duration in **milliseconds**. This defaults to `0` for `globalSummon`, and defaults to `200` for `quakeMode`. 200 was picked because, according to [`AnimateWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-animatewindow): > Typically, an animation takes 200 milliseconds to play. Do note that you won't be able to interact with the window during the animation! Input sent during the dropdown will arrive at the end of the animation, but input sent during the slide-up _won't_. Avoid setting this to large values! The gifs are in Teams. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-59030824 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I had the following previously in the doc comments, but it feels better in the PR body: - This was chosen because it was easier to implement and generally nicer than: * `AnimateWindow`, which would show the window borders for the duration of the animation, and occasionally just plain not work. Additionally, for `AnimateWindow` to work, the window much not be visible, so we'd need to first restore the window, then hide it, then animate it. That would flash the taskbar. * `SetWindowRgn` on the root HWND, which caused the xaml content to shift to the left, and caused a black bar to be drawn on the right of the window. Presumably, `SetWindowRgn` and `DwmExtendFrameIntoClientArea` did not play well with each other. * `SetWindowPos(..., SWP_NOSENDCHANGING)`, which worked the absolute best for longer animations, and is the closest to the actual implementation of `AnimateWindow`. This would resize the ROOT window, without sending resizes to the XAML island, allowing the content to _not_ reflow. but for a duration of 200ms, would only ever display ~2 frames. That's basically not even animation anymore, it's now just an "appear". Since that's how long the default animation is, if felt silly to have it basically not work by default. - If a future reader would like to implement this better, **they should feel free to**, and not mistake my notes here as expertise. These are research notes into the dark and terrible land that is Win32 programming. I'm no expert. ## Validation Steps Performed This is the blob of json I'm testing with these days: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, ``` * <kbd>ctrl+\`</kbd> will summon the quake window with a _quick_ animation * <kbd>ctrl+2</kbd> will summon the window with a s l o w animation
2021-05-17 14:28:46 +02:00
// - dropdownDuration: The duration to play the dropdown animation, in
// milliseconds. If 0, we won't perform a dropdown animation.
// Return Value:
// - <none>
Add `"monitor": "any"|"toCurrent"|"toMouse"` setting to globalSummon (#10092) #### ⚠️ this pr targets #9977 ## Summary of the Pull Request This adds support for part of the `monitor` property for `globalSummon`. It also goes a little off-spec: ```json "monitor": "any"|"toCurrent"|"toMouse" ``` * `monitor`: This controls the monitor that the window will be summoned from/to - `"any"`: Summon the MRU window, regardless of which monitor it's currently on. - `"toCurrent"`/omitted: (_default_): Summon the MRU window **TO** the monitor with the current **foreground** window. - [**NEW**] `"toMouse"`: Summon the MRU window **TO** the monitor where the **mouse** cursor is. When I was playing with this, It felt like `toMouse` was always what I wanted, not `toCurrent`. We can always just comment that out if we think that's contentious - I'm aware I didn't originally spec that. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-60325291 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated 😢 ## Detailed Description of the Pull Request / Additional comments I made `toMouse` the default because it felt better. fite-me.jpg ## Validation Steps Performed my ever evolving blob: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-17 14:57:08 +02:00
void IslandWindow::_globalActivateWindow(const uint32_t dropdownDuration,
const Remoting::MonitorBehavior toMonitor)
{
Add `"monitor": "any"|"toCurrent"|"toMouse"` setting to globalSummon (#10092) #### ⚠️ this pr targets #9977 ## Summary of the Pull Request This adds support for part of the `monitor` property for `globalSummon`. It also goes a little off-spec: ```json "monitor": "any"|"toCurrent"|"toMouse" ``` * `monitor`: This controls the monitor that the window will be summoned from/to - `"any"`: Summon the MRU window, regardless of which monitor it's currently on. - `"toCurrent"`/omitted: (_default_): Summon the MRU window **TO** the monitor with the current **foreground** window. - [**NEW**] `"toMouse"`: Summon the MRU window **TO** the monitor where the **mouse** cursor is. When I was playing with this, It felt like `toMouse` was always what I wanted, not `toCurrent`. We can always just comment that out if we think that's contentious - I'm aware I didn't originally spec that. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-60325291 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated 😢 ## Detailed Description of the Pull Request / Additional comments I made `toMouse` the default because it felt better. fite-me.jpg ## Validation Steps Performed my ever evolving blob: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-17 14:57:08 +02:00
// First, get the window that's currently in the foreground. We'll need
// _this_ window to be able to appear on top of. If we just use
// GetForegroundWindow afer the SetWindowPlacement/ShowWindow call, _we_
// will be the foreground window.
const auto oldForegroundWindow = GetForegroundWindow();
// From: https://stackoverflow.com/a/59659421
// > The trick is to make windows think that our process and the target
// > window (hwnd) are related by attaching the threads (using
// > AttachThreadInput API) and using an alternative API: BringWindowToTop.
// If the window is minimized, then restore it. We don't want to do this
// always though, because if you SW_RESTORE a maximized window, it will
// restore-down the window.
if (IsIconic(_window.get()))
{
Add property to control dropdown speed of global summon (#9977) ## Summary of the Pull Request Adds the `dropdownDuration` property to `globalSummon`. This controls how fast the window appears on the screen when summoned from minimized. It similarly controls the speed for sliding out of view when the window is dismissed with `"toggleVisibility": true`. `dropdownDuration` specifies the duration in **milliseconds**. This defaults to `0` for `globalSummon`, and defaults to `200` for `quakeMode`. 200 was picked because, according to [`AnimateWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-animatewindow): > Typically, an animation takes 200 milliseconds to play. Do note that you won't be able to interact with the window during the animation! Input sent during the dropdown will arrive at the end of the animation, but input sent during the slide-up _won't_. Avoid setting this to large values! The gifs are in Teams. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-59030824 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I had the following previously in the doc comments, but it feels better in the PR body: - This was chosen because it was easier to implement and generally nicer than: * `AnimateWindow`, which would show the window borders for the duration of the animation, and occasionally just plain not work. Additionally, for `AnimateWindow` to work, the window much not be visible, so we'd need to first restore the window, then hide it, then animate it. That would flash the taskbar. * `SetWindowRgn` on the root HWND, which caused the xaml content to shift to the left, and caused a black bar to be drawn on the right of the window. Presumably, `SetWindowRgn` and `DwmExtendFrameIntoClientArea` did not play well with each other. * `SetWindowPos(..., SWP_NOSENDCHANGING)`, which worked the absolute best for longer animations, and is the closest to the actual implementation of `AnimateWindow`. This would resize the ROOT window, without sending resizes to the XAML island, allowing the content to _not_ reflow. but for a duration of 200ms, would only ever display ~2 frames. That's basically not even animation anymore, it's now just an "appear". Since that's how long the default animation is, if felt silly to have it basically not work by default. - If a future reader would like to implement this better, **they should feel free to**, and not mistake my notes here as expertise. These are research notes into the dark and terrible land that is Win32 programming. I'm no expert. ## Validation Steps Performed This is the blob of json I'm testing with these days: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, ``` * <kbd>ctrl+\`</kbd> will summon the quake window with a _quick_ animation * <kbd>ctrl+2</kbd> will summon the window with a s l o w animation
2021-05-17 14:28:46 +02:00
if (dropdownDuration > 0)
{
Add `"monitor": "any"|"toCurrent"|"toMouse"` setting to globalSummon (#10092) #### ⚠️ this pr targets #9977 ## Summary of the Pull Request This adds support for part of the `monitor` property for `globalSummon`. It also goes a little off-spec: ```json "monitor": "any"|"toCurrent"|"toMouse" ``` * `monitor`: This controls the monitor that the window will be summoned from/to - `"any"`: Summon the MRU window, regardless of which monitor it's currently on. - `"toCurrent"`/omitted: (_default_): Summon the MRU window **TO** the monitor with the current **foreground** window. - [**NEW**] `"toMouse"`: Summon the MRU window **TO** the monitor where the **mouse** cursor is. When I was playing with this, It felt like `toMouse` was always what I wanted, not `toCurrent`. We can always just comment that out if we think that's contentious - I'm aware I didn't originally spec that. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-60325291 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated 😢 ## Detailed Description of the Pull Request / Additional comments I made `toMouse` the default because it felt better. fite-me.jpg ## Validation Steps Performed my ever evolving blob: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-17 14:57:08 +02:00
_dropdownWindow(dropdownDuration, toMonitor);
Add property to control dropdown speed of global summon (#9977) ## Summary of the Pull Request Adds the `dropdownDuration` property to `globalSummon`. This controls how fast the window appears on the screen when summoned from minimized. It similarly controls the speed for sliding out of view when the window is dismissed with `"toggleVisibility": true`. `dropdownDuration` specifies the duration in **milliseconds**. This defaults to `0` for `globalSummon`, and defaults to `200` for `quakeMode`. 200 was picked because, according to [`AnimateWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-animatewindow): > Typically, an animation takes 200 milliseconds to play. Do note that you won't be able to interact with the window during the animation! Input sent during the dropdown will arrive at the end of the animation, but input sent during the slide-up _won't_. Avoid setting this to large values! The gifs are in Teams. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-59030824 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I had the following previously in the doc comments, but it feels better in the PR body: - This was chosen because it was easier to implement and generally nicer than: * `AnimateWindow`, which would show the window borders for the duration of the animation, and occasionally just plain not work. Additionally, for `AnimateWindow` to work, the window much not be visible, so we'd need to first restore the window, then hide it, then animate it. That would flash the taskbar. * `SetWindowRgn` on the root HWND, which caused the xaml content to shift to the left, and caused a black bar to be drawn on the right of the window. Presumably, `SetWindowRgn` and `DwmExtendFrameIntoClientArea` did not play well with each other. * `SetWindowPos(..., SWP_NOSENDCHANGING)`, which worked the absolute best for longer animations, and is the closest to the actual implementation of `AnimateWindow`. This would resize the ROOT window, without sending resizes to the XAML island, allowing the content to _not_ reflow. but for a duration of 200ms, would only ever display ~2 frames. That's basically not even animation anymore, it's now just an "appear". Since that's how long the default animation is, if felt silly to have it basically not work by default. - If a future reader would like to implement this better, **they should feel free to**, and not mistake my notes here as expertise. These are research notes into the dark and terrible land that is Win32 programming. I'm no expert. ## Validation Steps Performed This is the blob of json I'm testing with these days: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, ``` * <kbd>ctrl+\`</kbd> will summon the quake window with a _quick_ animation * <kbd>ctrl+2</kbd> will summon the window with a s l o w animation
2021-05-17 14:28:46 +02:00
}
else
{
Hide `_quake` window on minimize ALWAYS (#10113) ## Summary of the Pull Request This is a scoped implementation of "hide on minimize", only to the `_quake` window. When minimized, the `_quake` window won't appear in the taskbar. IT ALSO WON'T APPEAR IN THE TRAY, BECAUSE WE DON'T HAVE ONE YET. I talked about this with @DHowett, and it seemed cool. Other windows will still minimize normally. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 * minimize to tray: #5727 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-61246940 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated - probably yea, but something <sub>something <sub>something</sub></sub> ## Detailed Description of the Pull Request / Additional comments After playing with it, it is in fact, cool. ALSO `LOG_IF_WIN32_BOOL_FALSE` should DEFINITELY not be used with `ShowWindow`. [`ShowWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-showwindow#return-value) returns false if the window was previously hidden, but doesn't `SetLastError`, so that macro will _throw_. ## Validation Steps Performed ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon", "name": "_quake" } }, // { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-18 12:44:42 +02:00
// If the window is hidden, SW_SHOW it first. Note that hidden !=
// minimized. A hidden window doesn't appear in the taskbar, while a
// minimized window will. If you don't do this, then we won't be
// able to properly set this as the foreground window.
if (!IsWindowVisible(GetHandle()))
{
ShowWindow(_window.get(), SW_SHOW);
}
ShowWindow(_window.get(), SW_RESTORE);
Add `"monitor": "any"|"toCurrent"|"toMouse"` setting to globalSummon (#10092) #### ⚠️ this pr targets #9977 ## Summary of the Pull Request This adds support for part of the `monitor` property for `globalSummon`. It also goes a little off-spec: ```json "monitor": "any"|"toCurrent"|"toMouse" ``` * `monitor`: This controls the monitor that the window will be summoned from/to - `"any"`: Summon the MRU window, regardless of which monitor it's currently on. - `"toCurrent"`/omitted: (_default_): Summon the MRU window **TO** the monitor with the current **foreground** window. - [**NEW**] `"toMouse"`: Summon the MRU window **TO** the monitor where the **mouse** cursor is. When I was playing with this, It felt like `toMouse` was always what I wanted, not `toCurrent`. We can always just comment that out if we think that's contentious - I'm aware I didn't originally spec that. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-60325291 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated 😢 ## Detailed Description of the Pull Request / Additional comments I made `toMouse` the default because it felt better. fite-me.jpg ## Validation Steps Performed my ever evolving blob: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-17 14:57:08 +02:00
// Once we've been restored, throw us on the active monitor.
_moveToMonitor(oldForegroundWindow, toMonitor);
Add property to control dropdown speed of global summon (#9977) ## Summary of the Pull Request Adds the `dropdownDuration` property to `globalSummon`. This controls how fast the window appears on the screen when summoned from minimized. It similarly controls the speed for sliding out of view when the window is dismissed with `"toggleVisibility": true`. `dropdownDuration` specifies the duration in **milliseconds**. This defaults to `0` for `globalSummon`, and defaults to `200` for `quakeMode`. 200 was picked because, according to [`AnimateWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-animatewindow): > Typically, an animation takes 200 milliseconds to play. Do note that you won't be able to interact with the window during the animation! Input sent during the dropdown will arrive at the end of the animation, but input sent during the slide-up _won't_. Avoid setting this to large values! The gifs are in Teams. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-59030824 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I had the following previously in the doc comments, but it feels better in the PR body: - This was chosen because it was easier to implement and generally nicer than: * `AnimateWindow`, which would show the window borders for the duration of the animation, and occasionally just plain not work. Additionally, for `AnimateWindow` to work, the window much not be visible, so we'd need to first restore the window, then hide it, then animate it. That would flash the taskbar. * `SetWindowRgn` on the root HWND, which caused the xaml content to shift to the left, and caused a black bar to be drawn on the right of the window. Presumably, `SetWindowRgn` and `DwmExtendFrameIntoClientArea` did not play well with each other. * `SetWindowPos(..., SWP_NOSENDCHANGING)`, which worked the absolute best for longer animations, and is the closest to the actual implementation of `AnimateWindow`. This would resize the ROOT window, without sending resizes to the XAML island, allowing the content to _not_ reflow. but for a duration of 200ms, would only ever display ~2 frames. That's basically not even animation anymore, it's now just an "appear". Since that's how long the default animation is, if felt silly to have it basically not work by default. - If a future reader would like to implement this better, **they should feel free to**, and not mistake my notes here as expertise. These are research notes into the dark and terrible land that is Win32 programming. I'm no expert. ## Validation Steps Performed This is the blob of json I'm testing with these days: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, ``` * <kbd>ctrl+\`</kbd> will summon the quake window with a _quick_ animation * <kbd>ctrl+2</kbd> will summon the window with a s l o w animation
2021-05-17 14:28:46 +02:00
}
}
else
{
Add `"monitor": "any"|"toCurrent"|"toMouse"` setting to globalSummon (#10092) #### ⚠️ this pr targets #9977 ## Summary of the Pull Request This adds support for part of the `monitor` property for `globalSummon`. It also goes a little off-spec: ```json "monitor": "any"|"toCurrent"|"toMouse" ``` * `monitor`: This controls the monitor that the window will be summoned from/to - `"any"`: Summon the MRU window, regardless of which monitor it's currently on. - `"toCurrent"`/omitted: (_default_): Summon the MRU window **TO** the monitor with the current **foreground** window. - [**NEW**] `"toMouse"`: Summon the MRU window **TO** the monitor where the **mouse** cursor is. When I was playing with this, It felt like `toMouse` was always what I wanted, not `toCurrent`. We can always just comment that out if we think that's contentious - I'm aware I didn't originally spec that. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-60325291 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated 😢 ## Detailed Description of the Pull Request / Additional comments I made `toMouse` the default because it felt better. fite-me.jpg ## Validation Steps Performed my ever evolving blob: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-17 14:57:08 +02:00
const DWORD windowThreadProcessId = GetWindowThreadProcessId(oldForegroundWindow, nullptr);
Add property to control dropdown speed of global summon (#9977) ## Summary of the Pull Request Adds the `dropdownDuration` property to `globalSummon`. This controls how fast the window appears on the screen when summoned from minimized. It similarly controls the speed for sliding out of view when the window is dismissed with `"toggleVisibility": true`. `dropdownDuration` specifies the duration in **milliseconds**. This defaults to `0` for `globalSummon`, and defaults to `200` for `quakeMode`. 200 was picked because, according to [`AnimateWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-animatewindow): > Typically, an animation takes 200 milliseconds to play. Do note that you won't be able to interact with the window during the animation! Input sent during the dropdown will arrive at the end of the animation, but input sent during the slide-up _won't_. Avoid setting this to large values! The gifs are in Teams. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-59030824 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I had the following previously in the doc comments, but it feels better in the PR body: - This was chosen because it was easier to implement and generally nicer than: * `AnimateWindow`, which would show the window borders for the duration of the animation, and occasionally just plain not work. Additionally, for `AnimateWindow` to work, the window much not be visible, so we'd need to first restore the window, then hide it, then animate it. That would flash the taskbar. * `SetWindowRgn` on the root HWND, which caused the xaml content to shift to the left, and caused a black bar to be drawn on the right of the window. Presumably, `SetWindowRgn` and `DwmExtendFrameIntoClientArea` did not play well with each other. * `SetWindowPos(..., SWP_NOSENDCHANGING)`, which worked the absolute best for longer animations, and is the closest to the actual implementation of `AnimateWindow`. This would resize the ROOT window, without sending resizes to the XAML island, allowing the content to _not_ reflow. but for a duration of 200ms, would only ever display ~2 frames. That's basically not even animation anymore, it's now just an "appear". Since that's how long the default animation is, if felt silly to have it basically not work by default. - If a future reader would like to implement this better, **they should feel free to**, and not mistake my notes here as expertise. These are research notes into the dark and terrible land that is Win32 programming. I'm no expert. ## Validation Steps Performed This is the blob of json I'm testing with these days: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, ``` * <kbd>ctrl+\`</kbd> will summon the quake window with a _quick_ animation * <kbd>ctrl+2</kbd> will summon the window with a s l o w animation
2021-05-17 14:28:46 +02:00
const DWORD currentThreadId = GetCurrentThreadId();
LOG_IF_WIN32_BOOL_FALSE(AttachThreadInput(windowThreadProcessId, currentThreadId, true));
// Just in case, add the thread detach as a scope_exit, to make _sure_ we do it.
auto detachThread = wil::scope_exit([windowThreadProcessId, currentThreadId]() {
LOG_IF_WIN32_BOOL_FALSE(AttachThreadInput(windowThreadProcessId, currentThreadId, false));
});
LOG_IF_WIN32_BOOL_FALSE(BringWindowToTop(_window.get()));
Hide `_quake` window on minimize ALWAYS (#10113) ## Summary of the Pull Request This is a scoped implementation of "hide on minimize", only to the `_quake` window. When minimized, the `_quake` window won't appear in the taskbar. IT ALSO WON'T APPEAR IN THE TRAY, BECAUSE WE DON'T HAVE ONE YET. I talked about this with @DHowett, and it seemed cool. Other windows will still minimize normally. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 * minimize to tray: #5727 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-61246940 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated - probably yea, but something <sub>something <sub>something</sub></sub> ## Detailed Description of the Pull Request / Additional comments After playing with it, it is in fact, cool. ALSO `LOG_IF_WIN32_BOOL_FALSE` should DEFINITELY not be used with `ShowWindow`. [`ShowWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-showwindow#return-value) returns false if the window was previously hidden, but doesn't `SetLastError`, so that macro will _throw_. ## Validation Steps Performed ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon", "name": "_quake" } }, // { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-18 12:44:42 +02:00
ShowWindow(_window.get(), SW_SHOW);
Add property to control dropdown speed of global summon (#9977) ## Summary of the Pull Request Adds the `dropdownDuration` property to `globalSummon`. This controls how fast the window appears on the screen when summoned from minimized. It similarly controls the speed for sliding out of view when the window is dismissed with `"toggleVisibility": true`. `dropdownDuration` specifies the duration in **milliseconds**. This defaults to `0` for `globalSummon`, and defaults to `200` for `quakeMode`. 200 was picked because, according to [`AnimateWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-animatewindow): > Typically, an animation takes 200 milliseconds to play. Do note that you won't be able to interact with the window during the animation! Input sent during the dropdown will arrive at the end of the animation, but input sent during the slide-up _won't_. Avoid setting this to large values! The gifs are in Teams. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-59030824 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I had the following previously in the doc comments, but it feels better in the PR body: - This was chosen because it was easier to implement and generally nicer than: * `AnimateWindow`, which would show the window borders for the duration of the animation, and occasionally just plain not work. Additionally, for `AnimateWindow` to work, the window much not be visible, so we'd need to first restore the window, then hide it, then animate it. That would flash the taskbar. * `SetWindowRgn` on the root HWND, which caused the xaml content to shift to the left, and caused a black bar to be drawn on the right of the window. Presumably, `SetWindowRgn` and `DwmExtendFrameIntoClientArea` did not play well with each other. * `SetWindowPos(..., SWP_NOSENDCHANGING)`, which worked the absolute best for longer animations, and is the closest to the actual implementation of `AnimateWindow`. This would resize the ROOT window, without sending resizes to the XAML island, allowing the content to _not_ reflow. but for a duration of 200ms, would only ever display ~2 frames. That's basically not even animation anymore, it's now just an "appear". Since that's how long the default animation is, if felt silly to have it basically not work by default. - If a future reader would like to implement this better, **they should feel free to**, and not mistake my notes here as expertise. These are research notes into the dark and terrible land that is Win32 programming. I'm no expert. ## Validation Steps Performed This is the blob of json I'm testing with these days: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, ``` * <kbd>ctrl+\`</kbd> will summon the quake window with a _quick_ animation * <kbd>ctrl+2</kbd> will summon the window with a s l o w animation
2021-05-17 14:28:46 +02:00
// Activate the window too. This will force us to the virtual desktop this
// window is on, if it's on another virtual desktop.
LOG_LAST_ERROR_IF_NULL(SetActiveWindow(_window.get()));
Add `"monitor": "any"|"toCurrent"|"toMouse"` setting to globalSummon (#10092) #### ⚠️ this pr targets #9977 ## Summary of the Pull Request This adds support for part of the `monitor` property for `globalSummon`. It also goes a little off-spec: ```json "monitor": "any"|"toCurrent"|"toMouse" ``` * `monitor`: This controls the monitor that the window will be summoned from/to - `"any"`: Summon the MRU window, regardless of which monitor it's currently on. - `"toCurrent"`/omitted: (_default_): Summon the MRU window **TO** the monitor with the current **foreground** window. - [**NEW**] `"toMouse"`: Summon the MRU window **TO** the monitor where the **mouse** cursor is. When I was playing with this, It felt like `toMouse` was always what I wanted, not `toCurrent`. We can always just comment that out if we think that's contentious - I'm aware I didn't originally spec that. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-60325291 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated 😢 ## Detailed Description of the Pull Request / Additional comments I made `toMouse` the default because it felt better. fite-me.jpg ## Validation Steps Performed my ever evolving blob: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-17 14:57:08 +02:00
// Throw us on the active monitor.
_moveToMonitor(oldForegroundWindow, toMonitor);
}
}
// Method Description:
// - Minimize the window. This is called when the window is summoned, but is
// already active
Add property to control dropdown speed of global summon (#9977) ## Summary of the Pull Request Adds the `dropdownDuration` property to `globalSummon`. This controls how fast the window appears on the screen when summoned from minimized. It similarly controls the speed for sliding out of view when the window is dismissed with `"toggleVisibility": true`. `dropdownDuration` specifies the duration in **milliseconds**. This defaults to `0` for `globalSummon`, and defaults to `200` for `quakeMode`. 200 was picked because, according to [`AnimateWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-animatewindow): > Typically, an animation takes 200 milliseconds to play. Do note that you won't be able to interact with the window during the animation! Input sent during the dropdown will arrive at the end of the animation, but input sent during the slide-up _won't_. Avoid setting this to large values! The gifs are in Teams. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-59030824 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I had the following previously in the doc comments, but it feels better in the PR body: - This was chosen because it was easier to implement and generally nicer than: * `AnimateWindow`, which would show the window borders for the duration of the animation, and occasionally just plain not work. Additionally, for `AnimateWindow` to work, the window much not be visible, so we'd need to first restore the window, then hide it, then animate it. That would flash the taskbar. * `SetWindowRgn` on the root HWND, which caused the xaml content to shift to the left, and caused a black bar to be drawn on the right of the window. Presumably, `SetWindowRgn` and `DwmExtendFrameIntoClientArea` did not play well with each other. * `SetWindowPos(..., SWP_NOSENDCHANGING)`, which worked the absolute best for longer animations, and is the closest to the actual implementation of `AnimateWindow`. This would resize the ROOT window, without sending resizes to the XAML island, allowing the content to _not_ reflow. but for a duration of 200ms, would only ever display ~2 frames. That's basically not even animation anymore, it's now just an "appear". Since that's how long the default animation is, if felt silly to have it basically not work by default. - If a future reader would like to implement this better, **they should feel free to**, and not mistake my notes here as expertise. These are research notes into the dark and terrible land that is Win32 programming. I'm no expert. ## Validation Steps Performed This is the blob of json I'm testing with these days: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, ``` * <kbd>ctrl+\`</kbd> will summon the quake window with a _quick_ animation * <kbd>ctrl+2</kbd> will summon the window with a s l o w animation
2021-05-17 14:28:46 +02:00
// - If dropdownDuration is greater than 0, we'll perform a "slide in"
// animation, before minimizing the window.
// Arguments:
Add property to control dropdown speed of global summon (#9977) ## Summary of the Pull Request Adds the `dropdownDuration` property to `globalSummon`. This controls how fast the window appears on the screen when summoned from minimized. It similarly controls the speed for sliding out of view when the window is dismissed with `"toggleVisibility": true`. `dropdownDuration` specifies the duration in **milliseconds**. This defaults to `0` for `globalSummon`, and defaults to `200` for `quakeMode`. 200 was picked because, according to [`AnimateWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-animatewindow): > Typically, an animation takes 200 milliseconds to play. Do note that you won't be able to interact with the window during the animation! Input sent during the dropdown will arrive at the end of the animation, but input sent during the slide-up _won't_. Avoid setting this to large values! The gifs are in Teams. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-59030824 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I had the following previously in the doc comments, but it feels better in the PR body: - This was chosen because it was easier to implement and generally nicer than: * `AnimateWindow`, which would show the window borders for the duration of the animation, and occasionally just plain not work. Additionally, for `AnimateWindow` to work, the window much not be visible, so we'd need to first restore the window, then hide it, then animate it. That would flash the taskbar. * `SetWindowRgn` on the root HWND, which caused the xaml content to shift to the left, and caused a black bar to be drawn on the right of the window. Presumably, `SetWindowRgn` and `DwmExtendFrameIntoClientArea` did not play well with each other. * `SetWindowPos(..., SWP_NOSENDCHANGING)`, which worked the absolute best for longer animations, and is the closest to the actual implementation of `AnimateWindow`. This would resize the ROOT window, without sending resizes to the XAML island, allowing the content to _not_ reflow. but for a duration of 200ms, would only ever display ~2 frames. That's basically not even animation anymore, it's now just an "appear". Since that's how long the default animation is, if felt silly to have it basically not work by default. - If a future reader would like to implement this better, **they should feel free to**, and not mistake my notes here as expertise. These are research notes into the dark and terrible land that is Win32 programming. I'm no expert. ## Validation Steps Performed This is the blob of json I'm testing with these days: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, ``` * <kbd>ctrl+\`</kbd> will summon the quake window with a _quick_ animation * <kbd>ctrl+2</kbd> will summon the window with a s l o w animation
2021-05-17 14:28:46 +02:00
// - dropdownDuration: The duration to play the slide-up animation, in
// milliseconds. If 0, we won't perform a slide-up animation.
// Return Value:
// - <none>
Add property to control dropdown speed of global summon (#9977) ## Summary of the Pull Request Adds the `dropdownDuration` property to `globalSummon`. This controls how fast the window appears on the screen when summoned from minimized. It similarly controls the speed for sliding out of view when the window is dismissed with `"toggleVisibility": true`. `dropdownDuration` specifies the duration in **milliseconds**. This defaults to `0` for `globalSummon`, and defaults to `200` for `quakeMode`. 200 was picked because, according to [`AnimateWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-animatewindow): > Typically, an animation takes 200 milliseconds to play. Do note that you won't be able to interact with the window during the animation! Input sent during the dropdown will arrive at the end of the animation, but input sent during the slide-up _won't_. Avoid setting this to large values! The gifs are in Teams. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-59030824 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I had the following previously in the doc comments, but it feels better in the PR body: - This was chosen because it was easier to implement and generally nicer than: * `AnimateWindow`, which would show the window borders for the duration of the animation, and occasionally just plain not work. Additionally, for `AnimateWindow` to work, the window much not be visible, so we'd need to first restore the window, then hide it, then animate it. That would flash the taskbar. * `SetWindowRgn` on the root HWND, which caused the xaml content to shift to the left, and caused a black bar to be drawn on the right of the window. Presumably, `SetWindowRgn` and `DwmExtendFrameIntoClientArea` did not play well with each other. * `SetWindowPos(..., SWP_NOSENDCHANGING)`, which worked the absolute best for longer animations, and is the closest to the actual implementation of `AnimateWindow`. This would resize the ROOT window, without sending resizes to the XAML island, allowing the content to _not_ reflow. but for a duration of 200ms, would only ever display ~2 frames. That's basically not even animation anymore, it's now just an "appear". Since that's how long the default animation is, if felt silly to have it basically not work by default. - If a future reader would like to implement this better, **they should feel free to**, and not mistake my notes here as expertise. These are research notes into the dark and terrible land that is Win32 programming. I'm no expert. ## Validation Steps Performed This is the blob of json I'm testing with these days: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, ``` * <kbd>ctrl+\`</kbd> will summon the quake window with a _quick_ animation * <kbd>ctrl+2</kbd> will summon the window with a s l o w animation
2021-05-17 14:28:46 +02:00
void IslandWindow::_globalDismissWindow(const uint32_t dropdownDuration)
{
Add property to control dropdown speed of global summon (#9977) ## Summary of the Pull Request Adds the `dropdownDuration` property to `globalSummon`. This controls how fast the window appears on the screen when summoned from minimized. It similarly controls the speed for sliding out of view when the window is dismissed with `"toggleVisibility": true`. `dropdownDuration` specifies the duration in **milliseconds**. This defaults to `0` for `globalSummon`, and defaults to `200` for `quakeMode`. 200 was picked because, according to [`AnimateWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-animatewindow): > Typically, an animation takes 200 milliseconds to play. Do note that you won't be able to interact with the window during the animation! Input sent during the dropdown will arrive at the end of the animation, but input sent during the slide-up _won't_. Avoid setting this to large values! The gifs are in Teams. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-59030824 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I had the following previously in the doc comments, but it feels better in the PR body: - This was chosen because it was easier to implement and generally nicer than: * `AnimateWindow`, which would show the window borders for the duration of the animation, and occasionally just plain not work. Additionally, for `AnimateWindow` to work, the window much not be visible, so we'd need to first restore the window, then hide it, then animate it. That would flash the taskbar. * `SetWindowRgn` on the root HWND, which caused the xaml content to shift to the left, and caused a black bar to be drawn on the right of the window. Presumably, `SetWindowRgn` and `DwmExtendFrameIntoClientArea` did not play well with each other. * `SetWindowPos(..., SWP_NOSENDCHANGING)`, which worked the absolute best for longer animations, and is the closest to the actual implementation of `AnimateWindow`. This would resize the ROOT window, without sending resizes to the XAML island, allowing the content to _not_ reflow. but for a duration of 200ms, would only ever display ~2 frames. That's basically not even animation anymore, it's now just an "appear". Since that's how long the default animation is, if felt silly to have it basically not work by default. - If a future reader would like to implement this better, **they should feel free to**, and not mistake my notes here as expertise. These are research notes into the dark and terrible land that is Win32 programming. I'm no expert. ## Validation Steps Performed This is the blob of json I'm testing with these days: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, ``` * <kbd>ctrl+\`</kbd> will summon the quake window with a _quick_ animation * <kbd>ctrl+2</kbd> will summon the window with a s l o w animation
2021-05-17 14:28:46 +02:00
if (dropdownDuration > 0)
{
_slideUpWindow(dropdownDuration);
}
else
{
Hide `_quake` window on minimize ALWAYS (#10113) ## Summary of the Pull Request This is a scoped implementation of "hide on minimize", only to the `_quake` window. When minimized, the `_quake` window won't appear in the taskbar. IT ALSO WON'T APPEAR IN THE TRAY, BECAUSE WE DON'T HAVE ONE YET. I talked about this with @DHowett, and it seemed cool. Other windows will still minimize normally. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 * minimize to tray: #5727 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-61246940 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated - probably yea, but something <sub>something <sub>something</sub></sub> ## Detailed Description of the Pull Request / Additional comments After playing with it, it is in fact, cool. ALSO `LOG_IF_WIN32_BOOL_FALSE` should DEFINITELY not be used with `ShowWindow`. [`ShowWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-showwindow#return-value) returns false if the window was previously hidden, but doesn't `SetLastError`, so that macro will _throw_. ## Validation Steps Performed ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon", "name": "_quake" } }, // { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-18 12:44:42 +02:00
ShowWindow(_window.get(), SW_MINIMIZE);
Add property to control dropdown speed of global summon (#9977) ## Summary of the Pull Request Adds the `dropdownDuration` property to `globalSummon`. This controls how fast the window appears on the screen when summoned from minimized. It similarly controls the speed for sliding out of view when the window is dismissed with `"toggleVisibility": true`. `dropdownDuration` specifies the duration in **milliseconds**. This defaults to `0` for `globalSummon`, and defaults to `200` for `quakeMode`. 200 was picked because, according to [`AnimateWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-animatewindow): > Typically, an animation takes 200 milliseconds to play. Do note that you won't be able to interact with the window during the animation! Input sent during the dropdown will arrive at the end of the animation, but input sent during the slide-up _won't_. Avoid setting this to large values! The gifs are in Teams. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-59030824 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I had the following previously in the doc comments, but it feels better in the PR body: - This was chosen because it was easier to implement and generally nicer than: * `AnimateWindow`, which would show the window borders for the duration of the animation, and occasionally just plain not work. Additionally, for `AnimateWindow` to work, the window much not be visible, so we'd need to first restore the window, then hide it, then animate it. That would flash the taskbar. * `SetWindowRgn` on the root HWND, which caused the xaml content to shift to the left, and caused a black bar to be drawn on the right of the window. Presumably, `SetWindowRgn` and `DwmExtendFrameIntoClientArea` did not play well with each other. * `SetWindowPos(..., SWP_NOSENDCHANGING)`, which worked the absolute best for longer animations, and is the closest to the actual implementation of `AnimateWindow`. This would resize the ROOT window, without sending resizes to the XAML island, allowing the content to _not_ reflow. but for a duration of 200ms, would only ever display ~2 frames. That's basically not even animation anymore, it's now just an "appear". Since that's how long the default animation is, if felt silly to have it basically not work by default. - If a future reader would like to implement this better, **they should feel free to**, and not mistake my notes here as expertise. These are research notes into the dark and terrible land that is Win32 programming. I'm no expert. ## Validation Steps Performed This is the blob of json I'm testing with these days: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, ``` * <kbd>ctrl+\`</kbd> will summon the quake window with a _quick_ animation * <kbd>ctrl+2</kbd> will summon the window with a s l o w animation
2021-05-17 14:28:46 +02:00
}
}
Add `"monitor": "any"|"toCurrent"|"toMouse"` setting to globalSummon (#10092) #### ⚠️ this pr targets #9977 ## Summary of the Pull Request This adds support for part of the `monitor` property for `globalSummon`. It also goes a little off-spec: ```json "monitor": "any"|"toCurrent"|"toMouse" ``` * `monitor`: This controls the monitor that the window will be summoned from/to - `"any"`: Summon the MRU window, regardless of which monitor it's currently on. - `"toCurrent"`/omitted: (_default_): Summon the MRU window **TO** the monitor with the current **foreground** window. - [**NEW**] `"toMouse"`: Summon the MRU window **TO** the monitor where the **mouse** cursor is. When I was playing with this, It felt like `toMouse` was always what I wanted, not `toCurrent`. We can always just comment that out if we think that's contentious - I'm aware I didn't originally spec that. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-60325291 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated 😢 ## Detailed Description of the Pull Request / Additional comments I made `toMouse` the default because it felt better. fite-me.jpg ## Validation Steps Performed my ever evolving blob: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-17 14:57:08 +02:00
// Method Description:
// - Get the monitor the mouse cursor is currently on
// Arguments:
// - dropdownDuration: The duration to play the slide-up animation, in
// milliseconds. If 0, we won't perform a slide-up animation.
// Return Value:
// - The MONITORINFO for the monitor the mouse cursor is on
MONITORINFO IslandWindow::_getMonitorForCursor()
{
POINT p{};
GetCursorPos(&p);
// Get the monitor info for the window's current monitor.
MONITORINFO activeMonitor{};
activeMonitor.cbSize = sizeof(activeMonitor);
GetMonitorInfo(MonitorFromPoint(p, MONITOR_DEFAULTTONEAREST), &activeMonitor);
return activeMonitor;
}
// Method Description:
// - Get the monitor for a given HWND
// Arguments:
// - <none>
// Return Value:
// - The MONITORINFO for the given HWND
MONITORINFO IslandWindow::_getMonitorForWindow(HWND foregroundWindow)
{
// Get the monitor info for the window's current monitor.
MONITORINFO activeMonitor{};
activeMonitor.cbSize = sizeof(activeMonitor);
GetMonitorInfo(MonitorFromWindow(foregroundWindow, MONITOR_DEFAULTTONEAREST), &activeMonitor);
return activeMonitor;
}
// Method Description:
// - Based on the value in toMonitor, move the window to the monitor of the
// given HWND, the monitor of the mouse pointer, or just leave it where it is.
// Arguments:
// - oldForegroundWindow: when toMonitor is ToCurrent, we'll move to the monitor
// of this HWND. Otherwise, this param is ignored.
// - toMonitor: Controls which monitor we should move to.
// Return Value:
// - <none>
void IslandWindow::_moveToMonitor(HWND oldForegroundWindow, Remoting::MonitorBehavior toMonitor)
{
if (toMonitor == Remoting::MonitorBehavior::ToCurrent)
{
_moveToMonitorOf(oldForegroundWindow);
}
else if (toMonitor == Remoting::MonitorBehavior::ToMouse)
{
_moveToMonitorOfMouse();
}
}
// Method Description:
// - Move our window to the monitor the mouse is on.
// Arguments:
// - <none>
// Return Value:
// - <none>
void IslandWindow::_moveToMonitorOfMouse()
{
_moveToMonitor(_getMonitorForCursor());
}
// Method Description:
// - Move our window to the monitor that the given HWND is on.
// Arguments:
// - <none>
// Return Value:
// - <none>
void IslandWindow::_moveToMonitorOf(HWND foregroundWindow)
{
_moveToMonitor(_getMonitorForWindow(foregroundWindow));
}
// Method Description:
// - Move our window to the given monitor. This will do nothing if we're already
// on that monitor.
// - We'll retain the same relative position on the new monitor as we had on the
// old monitor.
// Arguments:
// - activeMonitor: the monitor to move to.
// Return Value:
// - <none>
void IslandWindow::_moveToMonitor(const MONITORINFO activeMonitor)
{
// Get the monitor info for the window's current monitor.
const auto currentMonitor = _getMonitorForWindow(GetHandle());
const til::rectangle currentRect{ currentMonitor.rcMonitor };
const til::rectangle activeRect{ activeMonitor.rcMonitor };
if (currentRect != activeRect)
{
const til::rectangle currentWindowRect{ GetWindowRect() };
const til::point offset{ currentWindowRect.origin() - currentRect.origin() };
const til::point newOrigin{ activeRect.origin() + offset };
SetWindowPos(GetHandle(),
0,
newOrigin.x<int>(),
newOrigin.y<int>(),
currentWindowRect.width<int>(),
currentWindowRect.height<int>(),
SWP_NOZORDER | SWP_NOSIZE | SWP_NOACTIVATE);
// GH#10274, GH#10182: Re-evaluate the size of the quake window when we
// move to another monitor.
if (IsQuakeWindow())
{
_enterQuakeMode();
}
Add `"monitor": "any"|"toCurrent"|"toMouse"` setting to globalSummon (#10092) #### ⚠️ this pr targets #9977 ## Summary of the Pull Request This adds support for part of the `monitor` property for `globalSummon`. It also goes a little off-spec: ```json "monitor": "any"|"toCurrent"|"toMouse" ``` * `monitor`: This controls the monitor that the window will be summoned from/to - `"any"`: Summon the MRU window, regardless of which monitor it's currently on. - `"toCurrent"`/omitted: (_default_): Summon the MRU window **TO** the monitor with the current **foreground** window. - [**NEW**] `"toMouse"`: Summon the MRU window **TO** the monitor where the **mouse** cursor is. When I was playing with this, It felt like `toMouse` was always what I wanted, not `toCurrent`. We can always just comment that out if we think that's contentious - I'm aware I didn't originally spec that. ## References * Original thread: #653 * Spec: #9274 * megathread: #8888 ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-60325291 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated 😢 ## Detailed Description of the Pull Request / Additional comments I made `toMouse` the default because it felt better. fite-me.jpg ## Validation Steps Performed my ever evolving blob: ```jsonc { "keys": "ctrl+`", "command": { "action": "quakeMode" } }, { "keys": "ctrl+1", "command": { "action": "globalSummon" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "desktop": "toCurrent" } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "toggleVisibility": false } }, // { "keys": "ctrl+2", "command": { "action": "globalSummon", "dropdownDuration": 2000 } }, { "keys": "ctrl+2", "command": { "action": "globalSummon", "monitor": "any" } }, // { "keys": "ctrl+3", "command": { "action": "globalSummon", "desktop": "onCurrent" } }, { "keys": "ctrl+3", "command": { "action": "globalSummon", "monitor": "toMouse" } }, // { "keys": "ctrl+4", "command": { "action": "globalSummon", "desktop": "any" } }, { "keys": "ctrl+4", "command": { "action": "globalSummon", "monitor": "toMouse", "dropdownDuration": 500 } }, { "keys": "ctrl+5", "command": { "action": "globalSummon", "dropdownDuration": 500 } }, ```
2021-05-17 14:57:08 +02:00
}
}
Make the window name `_quake` special (#9785) ## Summary of the Pull Request This PR adds some special behavior to the window named "\_quake". * When creating the quake window, it ignores "initialRows" and "initialCols" and opens on the top half of the monitor. - It uses `initialPosition` to determine which monitor this is * It cannot be moved * It can only be vertically resized on the bottom border. * It's always in focus mode. - We should probably have an issue tracking "Allow showing tabs in focus mode"? Maybe? - This one element is maybe the one I'm least attached to When renaming a window to "\_quake", it adopts all those behaviors as well. It does not exit focus mode when leaving QM, nor does it resize back. That seemed unnecessary. ## References * As spec'ed in #9274 * See also #8888 ## PR Checklist * [x] In the pursuit of #653 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated, but I'm not gonna do any of that till quake mode is totally done. ## Detailed Description of the Pull Request / Additional comments Note that this doesn't do things like: * dropdown * global hotkey summon * summon to the current monitor * summon to the current desktop I'm doing #653 _very_ piecemeal, to try and make the PRs less egregious. ## Validation Steps Performed * validated that center on launch still works * validated that QM works on different monitors based on `initialPosition` * validated entering/exiting QM behaves as expected ## TODO! * [ ] When snapping the quake window between desktops with <kbd>win+shift+arrow</kbd>, the window doesn't horizontally re-size to the new monitor dimensions. It should.
2021-04-26 21:36:23 +02:00
bool IslandWindow::IsQuakeWindow() const noexcept
{
return _isQuakeWindow;
}
void IslandWindow::IsQuakeWindow(bool isQuakeWindow) noexcept
{
if (_isQuakeWindow != isQuakeWindow)
{
_isQuakeWindow = isQuakeWindow;
// Don't enter quake mode if we don't have an HWND yet
if (IsQuakeWindow() && _window)
{
_enterQuakeMode();
}
}
}
// Method Description:
// - Enter quake mode for the monitor this window is currently on. This involves
// resizing it to the top half of the monitor.
// Arguments:
// - <none>
// Return Value:
// - <none>
Make the window name `_quake` special (#9785) ## Summary of the Pull Request This PR adds some special behavior to the window named "\_quake". * When creating the quake window, it ignores "initialRows" and "initialCols" and opens on the top half of the monitor. - It uses `initialPosition` to determine which monitor this is * It cannot be moved * It can only be vertically resized on the bottom border. * It's always in focus mode. - We should probably have an issue tracking "Allow showing tabs in focus mode"? Maybe? - This one element is maybe the one I'm least attached to When renaming a window to "\_quake", it adopts all those behaviors as well. It does not exit focus mode when leaving QM, nor does it resize back. That seemed unnecessary. ## References * As spec'ed in #9274 * See also #8888 ## PR Checklist * [x] In the pursuit of #653 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated, but I'm not gonna do any of that till quake mode is totally done. ## Detailed Description of the Pull Request / Additional comments Note that this doesn't do things like: * dropdown * global hotkey summon * summon to the current monitor * summon to the current desktop I'm doing #653 _very_ piecemeal, to try and make the PRs less egregious. ## Validation Steps Performed * validated that center on launch still works * validated that QM works on different monitors based on `initialPosition` * validated entering/exiting QM behaves as expected ## TODO! * [ ] When snapping the quake window between desktops with <kbd>win+shift+arrow</kbd>, the window doesn't horizontally re-size to the new monitor dimensions. It should.
2021-04-26 21:36:23 +02:00
void IslandWindow::_enterQuakeMode()
{
if (!_window)
{
return;
}
RECT windowRect = GetWindowRect();
HMONITOR hmon = MonitorFromRect(&windowRect, MONITOR_DEFAULTTONEAREST);
// Get the size and position of the window that we should occupy
const auto newRect{ _getQuakeModeSize(hmon) };
SetWindowPos(GetHandle(),
HWND_TOP,
newRect.left<int>(),
newRect.top<int>(),
newRect.width<int>(),
newRect.height<int>(),
SWP_SHOWWINDOW | SWP_FRAMECHANGED | SWP_NOACTIVATE);
}
// Method Description:
// - Get the size and position of the window that a "quake mode" should occupy
// on the given monitor.
// - The window will occupy the top half of the monitor.
// Arguments:
// - <none>
// Return Value:
// - <none>
til::rectangle IslandWindow::_getQuakeModeSize(HMONITOR hmon)
{
Make the window name `_quake` special (#9785) ## Summary of the Pull Request This PR adds some special behavior to the window named "\_quake". * When creating the quake window, it ignores "initialRows" and "initialCols" and opens on the top half of the monitor. - It uses `initialPosition` to determine which monitor this is * It cannot be moved * It can only be vertically resized on the bottom border. * It's always in focus mode. - We should probably have an issue tracking "Allow showing tabs in focus mode"? Maybe? - This one element is maybe the one I'm least attached to When renaming a window to "\_quake", it adopts all those behaviors as well. It does not exit focus mode when leaving QM, nor does it resize back. That seemed unnecessary. ## References * As spec'ed in #9274 * See also #8888 ## PR Checklist * [x] In the pursuit of #653 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated, but I'm not gonna do any of that till quake mode is totally done. ## Detailed Description of the Pull Request / Additional comments Note that this doesn't do things like: * dropdown * global hotkey summon * summon to the current monitor * summon to the current desktop I'm doing #653 _very_ piecemeal, to try and make the PRs less egregious. ## Validation Steps Performed * validated that center on launch still works * validated that QM works on different monitors based on `initialPosition` * validated entering/exiting QM behaves as expected ## TODO! * [ ] When snapping the quake window between desktops with <kbd>win+shift+arrow</kbd>, the window doesn't horizontally re-size to the new monitor dimensions. It should.
2021-04-26 21:36:23 +02:00
MONITORINFO nearestMonitorInfo;
UINT dpix = USER_DEFAULT_SCREEN_DPI;
UINT dpiy = USER_DEFAULT_SCREEN_DPI;
// If this fails, we'll use the default of 96. I think it can only fail for
// bad parameters, which we won't have, so no big deal.
LOG_IF_FAILED(GetDpiForMonitor(hmon, MDT_EFFECTIVE_DPI, &dpix, &dpiy));
nearestMonitorInfo.cbSize = sizeof(MONITORINFO);
// Get monitor dimensions:
GetMonitorInfo(hmon, &nearestMonitorInfo);
const til::size desktopDimensions{ (nearestMonitorInfo.rcWork.right - nearestMonitorInfo.rcWork.left),
(nearestMonitorInfo.rcWork.bottom - nearestMonitorInfo.rcWork.top) };
// If we just use rcWork by itself, we'll fail to account for the invisible
// space reserved for the resize handles. So retrieve that size here.
const til::size ncSize{ GetTotalNonClientExclusiveSize(dpix) };
const til::size availableSpace = desktopDimensions + ncSize;
// GH#10201 - The borders are still visible in quake mode, so make us 1px
// smaller on either side to account for that, so they don't hang onto
// adjacent monitors.
Make the window name `_quake` special (#9785) ## Summary of the Pull Request This PR adds some special behavior to the window named "\_quake". * When creating the quake window, it ignores "initialRows" and "initialCols" and opens on the top half of the monitor. - It uses `initialPosition` to determine which monitor this is * It cannot be moved * It can only be vertically resized on the bottom border. * It's always in focus mode. - We should probably have an issue tracking "Allow showing tabs in focus mode"? Maybe? - This one element is maybe the one I'm least attached to When renaming a window to "\_quake", it adopts all those behaviors as well. It does not exit focus mode when leaving QM, nor does it resize back. That seemed unnecessary. ## References * As spec'ed in #9274 * See also #8888 ## PR Checklist * [x] In the pursuit of #653 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated, but I'm not gonna do any of that till quake mode is totally done. ## Detailed Description of the Pull Request / Additional comments Note that this doesn't do things like: * dropdown * global hotkey summon * summon to the current monitor * summon to the current desktop I'm doing #653 _very_ piecemeal, to try and make the PRs less egregious. ## Validation Steps Performed * validated that center on launch still works * validated that QM works on different monitors based on `initialPosition` * validated entering/exiting QM behaves as expected ## TODO! * [ ] When snapping the quake window between desktops with <kbd>win+shift+arrow</kbd>, the window doesn't horizontally re-size to the new monitor dimensions. It should.
2021-04-26 21:36:23 +02:00
const til::point origin{
::base::ClampSub<long>(nearestMonitorInfo.rcWork.left, (ncSize.width() / 2)) + 1,
Make the window name `_quake` special (#9785) ## Summary of the Pull Request This PR adds some special behavior to the window named "\_quake". * When creating the quake window, it ignores "initialRows" and "initialCols" and opens on the top half of the monitor. - It uses `initialPosition` to determine which monitor this is * It cannot be moved * It can only be vertically resized on the bottom border. * It's always in focus mode. - We should probably have an issue tracking "Allow showing tabs in focus mode"? Maybe? - This one element is maybe the one I'm least attached to When renaming a window to "\_quake", it adopts all those behaviors as well. It does not exit focus mode when leaving QM, nor does it resize back. That seemed unnecessary. ## References * As spec'ed in #9274 * See also #8888 ## PR Checklist * [x] In the pursuit of #653 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated, but I'm not gonna do any of that till quake mode is totally done. ## Detailed Description of the Pull Request / Additional comments Note that this doesn't do things like: * dropdown * global hotkey summon * summon to the current monitor * summon to the current desktop I'm doing #653 _very_ piecemeal, to try and make the PRs less egregious. ## Validation Steps Performed * validated that center on launch still works * validated that QM works on different monitors based on `initialPosition` * validated entering/exiting QM behaves as expected ## TODO! * [ ] When snapping the quake window between desktops with <kbd>win+shift+arrow</kbd>, the window doesn't horizontally re-size to the new monitor dimensions. It should.
2021-04-26 21:36:23 +02:00
(nearestMonitorInfo.rcWork.top)
};
const til::size dimensions{
availableSpace.width() - 2,
Make the window name `_quake` special (#9785) ## Summary of the Pull Request This PR adds some special behavior to the window named "\_quake". * When creating the quake window, it ignores "initialRows" and "initialCols" and opens on the top half of the monitor. - It uses `initialPosition` to determine which monitor this is * It cannot be moved * It can only be vertically resized on the bottom border. * It's always in focus mode. - We should probably have an issue tracking "Allow showing tabs in focus mode"? Maybe? - This one element is maybe the one I'm least attached to When renaming a window to "\_quake", it adopts all those behaviors as well. It does not exit focus mode when leaving QM, nor does it resize back. That seemed unnecessary. ## References * As spec'ed in #9274 * See also #8888 ## PR Checklist * [x] In the pursuit of #653 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated, but I'm not gonna do any of that till quake mode is totally done. ## Detailed Description of the Pull Request / Additional comments Note that this doesn't do things like: * dropdown * global hotkey summon * summon to the current monitor * summon to the current desktop I'm doing #653 _very_ piecemeal, to try and make the PRs less egregious. ## Validation Steps Performed * validated that center on launch still works * validated that QM works on different monitors based on `initialPosition` * validated entering/exiting QM behaves as expected ## TODO! * [ ] When snapping the quake window between desktops with <kbd>win+shift+arrow</kbd>, the window doesn't horizontally re-size to the new monitor dimensions. It should.
2021-04-26 21:36:23 +02:00
availableSpace.height() / 2
};
return til::rectangle{ origin, dimensions };
Make the window name `_quake` special (#9785) ## Summary of the Pull Request This PR adds some special behavior to the window named "\_quake". * When creating the quake window, it ignores "initialRows" and "initialCols" and opens on the top half of the monitor. - It uses `initialPosition` to determine which monitor this is * It cannot be moved * It can only be vertically resized on the bottom border. * It's always in focus mode. - We should probably have an issue tracking "Allow showing tabs in focus mode"? Maybe? - This one element is maybe the one I'm least attached to When renaming a window to "\_quake", it adopts all those behaviors as well. It does not exit focus mode when leaving QM, nor does it resize back. That seemed unnecessary. ## References * As spec'ed in #9274 * See also #8888 ## PR Checklist * [x] In the pursuit of #653 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated, but I'm not gonna do any of that till quake mode is totally done. ## Detailed Description of the Pull Request / Additional comments Note that this doesn't do things like: * dropdown * global hotkey summon * summon to the current monitor * summon to the current desktop I'm doing #653 _very_ piecemeal, to try and make the PRs less egregious. ## Validation Steps Performed * validated that center on launch still works * validated that QM works on different monitors based on `initialPosition` * validated entering/exiting QM behaves as expected ## TODO! * [ ] When snapping the quake window between desktops with <kbd>win+shift+arrow</kbd>, the window doesn't horizontally re-size to the new monitor dimensions. It should.
2021-04-26 21:36:23 +02:00
}
void IslandWindow::HideWindow()
{
ShowWindow(GetHandle(), SW_HIDE);
}
void IslandWindow::SetMinimizeToNotificationAreaBehavior(bool MinimizeToNotificationArea) noexcept
{
_minimizeToNotificationArea = MinimizeToNotificationArea;
}
// Method Description:
// - Opens the window's system menu.
// - The system menu is the menu that opens when the user presses Alt+Space or
// right clicks on the title bar.
// - Before updating the menu, we update the buttons like "Maximize" and
// "Restore" so that they are grayed out depending on the window's state.
// Arguments:
// - cursorX: the cursor's X position in screen coordinates
// - cursorY: the cursor's Y position in screen coordinates
void IslandWindow::OpenSystemMenu(const std::optional<int> mouseX, const std::optional<int> mouseY) const noexcept
{
const auto systemMenu = GetSystemMenu(_window.get(), FALSE);
WINDOWPLACEMENT placement;
if (!GetWindowPlacement(_window.get(), &placement))
{
return;
}
const bool isMaximized = placement.showCmd == SW_SHOWMAXIMIZED;
// Update the options based on window state.
MENUITEMINFO mii;
mii.cbSize = sizeof(MENUITEMINFO);
mii.fMask = MIIM_STATE;
mii.fType = MFT_STRING;
auto setState = [&](UINT item, bool enabled) {
mii.fState = enabled ? MF_ENABLED : MF_DISABLED;
SetMenuItemInfo(systemMenu, item, FALSE, &mii);
};
setState(SC_RESTORE, isMaximized);
setState(SC_MOVE, !isMaximized);
setState(SC_SIZE, !isMaximized);
setState(SC_MINIMIZE, true);
setState(SC_MAXIMIZE, !isMaximized);
setState(SC_CLOSE, true);
SetMenuDefaultItem(systemMenu, UINT_MAX, FALSE);
int xPos;
int yPos;
if (mouseX && mouseY)
{
xPos = mouseX.value();
yPos = mouseY.value();
}
else
{
RECT windowPos;
::GetWindowRect(GetHandle(), &windowPos);
xPos = windowPos.left;
yPos = windowPos.top;
}
const auto ret = TrackPopupMenu(systemMenu, TPM_RETURNCMD, xPos, yPos, 0, _window.get(), nullptr);
if (ret != 0)
{
PostMessage(_window.get(), WM_SYSCOMMAND, ret, 0);
}
}
void IslandWindow::AddToSystemMenu(const winrt::hstring& itemLabel, winrt::delegate<void()> callback)
{
const HMENU systemMenu = GetSystemMenu(_window.get(), FALSE);
UINT wID = _systemMenuNextItemId;
MENUITEMINFOW item;
item.cbSize = sizeof(MENUITEMINFOW);
item.fMask = MIIM_STATE | MIIM_ID | MIIM_STRING;
item.fState = MF_ENABLED;
item.wID = wID;
item.dwTypeData = const_cast<LPWSTR>(itemLabel.c_str());
item.cch = static_cast<UINT>(itemLabel.size());
if (LOG_LAST_ERROR_IF(!InsertMenuItemW(systemMenu, wID, FALSE, &item)))
{
return;
}
_systemMenuItems.insert({ wID, { itemLabel, callback } });
_systemMenuNextItemId++;
}
void IslandWindow::RemoveFromSystemMenu(const winrt::hstring& itemLabel)
{
const HMENU systemMenu = GetSystemMenu(_window.get(), FALSE);
int itemCount = GetMenuItemCount(systemMenu);
if (LOG_LAST_ERROR_IF(itemCount == -1))
{
return;
}
auto it = std::find_if(_systemMenuItems.begin(), _systemMenuItems.end(), [&itemLabel](const std::pair<UINT, SystemMenuItemInfo>& elem) {
return elem.second.label == itemLabel;
});
if (it == _systemMenuItems.end())
{
return;
}
if (LOG_LAST_ERROR_IF(!DeleteMenu(systemMenu, it->first, MF_BYCOMMAND)))
{
return;
}
_systemMenuItems.erase(it->first);
}
DEFINE_EVENT(IslandWindow, DragRegionClicked, _DragRegionClickedHandlers, winrt::delegate<>);
DEFINE_EVENT(IslandWindow, WindowCloseButtonClicked, _windowCloseButtonClickedHandler, winrt::delegate<>);