maxmustermann/terminal
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
terminal/src/cascadia/TerminalApp/TabRowControl.xaml

86 lines
5.4 KiB
Plaintext
Raw Normal View History

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
<!-- Copyright (c) Microsoft Corporation. All rights reserved. Licensed under
the MIT License. See LICENSE in the project root for license information. -->
Upgrade to Microsoft.UI.Xaml 2.2 (#3027) * We had to move to the final API: * Items -> TabItems * Items.VectorChanged -> TabItemsChanged * TabClose -> TabCloseRequested * TabViewItem.Icon -> TabViewItem.IconSource * TabRowControl has been converted to a ContentPresenter, which simplifies its logic a little bit. * TerminalPage now differentiates MUX and WUX a little better * Because of the change from Icon to IconSource in TabViewItem, Utils::GetColoredIcon needed to be augmented to support MUX IconSources. It was still necessary to use for WUX, so it's been templatized. * I moved us from WUX SplitButton to MUX SplitButton and brought the style in line with the one typically provided by TabView. * Some of our local controls have had their backgrounds removed so they're more amenable to being placed on other surfaces. * I'm suppressing the TabView's padding. * I removed a number of apparently dead methods from App. * I've simplified the dragbar's sizing logic and eventing. * The winmd harvester needed to be taught to not try to copy winmds for framework packages. * We now only initialize the terminal once we know the size Closes #1896. Closes #444. Closes #857. Closes #771. Closes #760.
2019-10-15 07:41:43 +02:00
<ContentPresenter
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
x:Class="TerminalApp.TabRowControl"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="using:TerminalApp"
xmlns:mux="using:Microsoft.UI.Xaml.Controls"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d">
Upgrade to Microsoft.UI.Xaml 2.2 (#3027) * We had to move to the final API: * Items -> TabItems * Items.VectorChanged -> TabItemsChanged * TabClose -> TabCloseRequested * TabViewItem.Icon -> TabViewItem.IconSource * TabRowControl has been converted to a ContentPresenter, which simplifies its logic a little bit. * TerminalPage now differentiates MUX and WUX a little better * Because of the change from Icon to IconSource in TabViewItem, Utils::GetColoredIcon needed to be augmented to support MUX IconSources. It was still necessary to use for WUX, so it's been templatized. * I moved us from WUX SplitButton to MUX SplitButton and brought the style in line with the one typically provided by TabView. * Some of our local controls have had their backgrounds removed so they're more amenable to being placed on other surfaces. * I'm suppressing the TabView's padding. * I removed a number of apparently dead methods from App. * I've simplified the dragbar's sizing logic and eventing. * The winmd harvester needed to be taught to not try to copy winmds for framework packages. * We now only initialize the terminal once we know the size Closes #1896. Closes #444. Closes #857. Closes #771. Closes #760.
2019-10-15 07:41:43 +02:00
<mux:TabView x:Name="TabView"
VerticalAlignment="Bottom"
HorizontalContentAlignment="Stretch"
IsAddTabButtonVisible="false"
Add tab width modes: equal and titleLength (#3876) * tab sizing functionality * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * updated variable names to match spec * added to defaults.json * fixed merge conflict Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
2020-01-10 01:16:54 +01:00
TabWidthMode="Equal"
Add support for tab drag and drop (#3478) * Add support for tag drag and drop Co-authored-by: James Clarke (WDG) <jeclarke@ntdev.microsoft.com>
2019-11-08 18:27:20 +01:00
CanReorderTabs="True"
CanDragTabs="True"
AllowDropTabs="True">
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
Upgrade to Microsoft.UI.Xaml 2.2 (#3027) * We had to move to the final API: * Items -> TabItems * Items.VectorChanged -> TabItemsChanged * TabClose -> TabCloseRequested * TabViewItem.Icon -> TabViewItem.IconSource * TabRowControl has been converted to a ContentPresenter, which simplifies its logic a little bit. * TerminalPage now differentiates MUX and WUX a little better * Because of the change from Icon to IconSource in TabViewItem, Utils::GetColoredIcon needed to be augmented to support MUX IconSources. It was still necessary to use for WUX, so it's been templatized. * I moved us from WUX SplitButton to MUX SplitButton and brought the style in line with the one typically provided by TabView. * Some of our local controls have had their backgrounds removed so they're more amenable to being placed on other surfaces. * I'm suppressing the TabView's padding. * I removed a number of apparently dead methods from App. * I've simplified the dragbar's sizing logic and eventing. * The winmd harvester needed to be taught to not try to copy winmds for framework packages. * We now only initialize the terminal once we know the size Closes #1896. Closes #444. Closes #857. Closes #771. Closes #760.
2019-10-15 07:41:43 +02:00
<mux:TabView.TabStripFooter>
<mux:SplitButton
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
x:Name="NewTabButton"
Polish AutomationProperties and UIA Tree Navigation (#4805) AutomationProperties of interest in this PR include... - Name: the name of a UI element (generally used as the main identifier for it) - HelpText: an additional description for a more complex UI element - AccessibilityView[1] - Raw: hide from the UIA tree. Only navigate to this if you know what you're doing - Control: a control without any content in it. Basically, a point at which the user can make a decision as to how to navigate the tree or invoke an action. - Content: a control that also has content to present to the user. I set a few more AutomationProperties throughout Windows Terminal... - MinMaxClose Control: hidden (we can/should rely on the true buttons that we are hiding) - SplitButton: Name and Help text (currently ignored due to #4804, but having it in the resource file won't cause any problems) - SearchBox: added a more specific name to the close button - BackgroundImage: hide it ## References A few additional work items have been created for tracking... - SplitButton: https://github.com/microsoft/terminal/issues/4804 ## PR Checklist * [X] Closes #2099 * [X] Closes #2102 ## Validation Steps Performed Verified using Accessibility Insights and Inspect.exe [1] https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-treeoverview
2020-03-05 23:32:46 +01:00
x:Uid="NewTabSplitButton"
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
Click="OnNewTabButtonClick"
VerticalAlignment="Stretch"
Upgrade to Microsoft.UI.Xaml 2.2 (#3027) * We had to move to the final API: * Items -> TabItems * Items.VectorChanged -> TabItemsChanged * TabClose -> TabCloseRequested * TabViewItem.Icon -> TabViewItem.IconSource * TabRowControl has been converted to a ContentPresenter, which simplifies its logic a little bit. * TerminalPage now differentiates MUX and WUX a little better * Because of the change from Icon to IconSource in TabViewItem, Utils::GetColoredIcon needed to be augmented to support MUX IconSources. It was still necessary to use for WUX, so it's been templatized. * I moved us from WUX SplitButton to MUX SplitButton and brought the style in line with the one typically provided by TabView. * Some of our local controls have had their backgrounds removed so they're more amenable to being placed on other surfaces. * I'm suppressing the TabView's padding. * I removed a number of apparently dead methods from App. * I've simplified the dragbar's sizing logic and eventing. * The winmd harvester needed to be taught to not try to copy winmds for framework packages. * We now only initialize the terminal once we know the size Closes #1896. Closes #444. Closes #857. Closes #771. Closes #760.
2019-10-15 07:41:43 +02:00
HorizontalAlignment="Left"
Content="&#xE710;"
UseLayoutRounding="true"
FontFamily="Segoe MDL2 Assets"
FontWeight="SemiLight"
Polish AutomationProperties and UIA Tree Navigation (#4805) AutomationProperties of interest in this PR include... - Name: the name of a UI element (generally used as the main identifier for it) - HelpText: an additional description for a more complex UI element - AccessibilityView[1] - Raw: hide from the UIA tree. Only navigate to this if you know what you're doing - Control: a control without any content in it. Basically, a point at which the user can make a decision as to how to navigate the tree or invoke an action. - Content: a control that also has content to present to the user. I set a few more AutomationProperties throughout Windows Terminal... - MinMaxClose Control: hidden (we can/should rely on the true buttons that we are hiding) - SplitButton: Name and Help text (currently ignored due to #4804, but having it in the resource file won't cause any problems) - SearchBox: added a more specific name to the close button - BackgroundImage: hide it ## References A few additional work items have been created for tracking... - SplitButton: https://github.com/microsoft/terminal/issues/4804 ## PR Checklist * [X] Closes #2099 * [X] Closes #2102 ## Validation Steps Performed Verified using Accessibility Insights and Inspect.exe [1] https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-treeoverview
2020-03-05 23:32:46 +01:00
FontSize="12"
Update the shape of our custom NewTab button to match MUX's TabView button (#6766) The MUX TabView control has a uniquely-shaped [+] button. TerminalApp doesn't use it: instead, it has a SplitView button that is styled to look like MUX's official button. However, it doesn't get the button's shape right. This PR updates TerminalApp's custom button to look more like MUX's. The difference is that MUX only rounds the top two corners, and it uses a bigger radius. Without matching MUX's radius, the upper-left corner of the button makes an awkward asymmetric divot with the abutting tab. There's also a spot in the lower-left corner that just looks like someone accidentally spilled a few pixels on the floor. Current appearance before this PR: ![oldlight](https://user-images.githubusercontent.com/10259764/86410863-74ca5e80-bc70-11ea-8c15-4ae22998b209.png) New appearance with this PR: ![newlight](https://user-images.githubusercontent.com/10259764/86410871-772cb880-bc70-11ea-972c-13332f1a1bdb.png) Most important deltas highlighted with red circles: ![marklight](https://user-images.githubusercontent.com/10259764/86410877-78f67c00-bc70-11ea-8a6d-696cfbd89b1d.png) Note that this PR does *not* attempt to fix the colors. The colors are also just slightly different from what MUX uses. I'll save that for a separate PR, since all those screenshots would clutter this up this PR.
2020-07-06 16:13:23 +02:00
BorderThickness="0"
CornerRadius="{Binding Source={ThemeResource OverlayCornerRadius}, Converter={StaticResource TopCornerRadiusFilterConverter}}"
Polish AutomationProperties and UIA Tree Navigation (#4805) AutomationProperties of interest in this PR include... - Name: the name of a UI element (generally used as the main identifier for it) - HelpText: an additional description for a more complex UI element - AccessibilityView[1] - Raw: hide from the UIA tree. Only navigate to this if you know what you're doing - Control: a control without any content in it. Basically, a point at which the user can make a decision as to how to navigate the tree or invoke an action. - Content: a control that also has content to present to the user. I set a few more AutomationProperties throughout Windows Terminal... - MinMaxClose Control: hidden (we can/should rely on the true buttons that we are hiding) - SplitButton: Name and Help text (currently ignored due to #4804, but having it in the resource file won't cause any problems) - SearchBox: added a more specific name to the close button - BackgroundImage: hide it ## References A few additional work items have been created for tracking... - SplitButton: https://github.com/microsoft/terminal/issues/4804 ## PR Checklist * [X] Closes #2099 * [X] Closes #2102 ## Validation Steps Performed Verified using Accessibility Insights and Inspect.exe [1] https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-treeoverview
2020-03-05 23:32:46 +01:00
AutomationProperties.AccessibilityView="Control">
Inform user that holding alt opens a new pane (#7866) Adds a tooltip to the new tab button and menu to let the user know that holding alt will open a new pane instead. Fixes #7851 Co-authored-by: Pankaj Bhojwani <pabhojwa@microsoft.com>
2020-10-13 02:14:02 +02:00
<ToolTipService.ToolTip>
<ToolTip Placement="Mouse">
<TextBlock IsTextSelectionEnabled="False">
Allow shift+click on a profile to open a new window (#9429) <!-- 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 Shift+click on a profile to open a new wt window with that profile. Or, shift+click on the '+' button to open a new wt window with the default profile. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9395 * [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. * [x] I work here <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Manual testing
2021-03-10 19:32:54 +01:00
<Run x:Uid="NewTabRun"/> <LineBreak/>
Inform user that holding alt opens a new pane (#7866) Adds a tooltip to the new tab button and menu to let the user know that holding alt will open a new pane instead. Fixes #7851 Co-authored-by: Pankaj Bhojwani <pabhojwa@microsoft.com>
2020-10-13 02:14:02 +02:00
<Run x:Uid="NewPaneRun"
Allow shift+click on a profile to open a new window (#9429) <!-- 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 Shift+click on a profile to open a new wt window with that profile. Or, shift+click on the '+' button to open a new wt window with the default profile. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9395 * [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. * [x] I work here <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Manual testing
2021-03-10 19:32:54 +01:00
FontStyle="Italic"/> <LineBreak/>
<Run x:Uid="NewWindowRun"
FontStyle="Italic"/>
Inform user that holding alt opens a new pane (#7866) Adds a tooltip to the new tab button and menu to let the user know that holding alt will open a new pane instead. Fixes #7851 Co-authored-by: Pankaj Bhojwani <pabhojwa@microsoft.com>
2020-10-13 02:14:02 +02:00
</TextBlock>
</ToolTip>
</ToolTipService.ToolTip>
Upgrade to Microsoft.UI.Xaml 2.2 (#3027) * We had to move to the final API: * Items -> TabItems * Items.VectorChanged -> TabItemsChanged * TabClose -> TabCloseRequested * TabViewItem.Icon -> TabViewItem.IconSource * TabRowControl has been converted to a ContentPresenter, which simplifies its logic a little bit. * TerminalPage now differentiates MUX and WUX a little better * Because of the change from Icon to IconSource in TabViewItem, Utils::GetColoredIcon needed to be augmented to support MUX IconSources. It was still necessary to use for WUX, so it's been templatized. * I moved us from WUX SplitButton to MUX SplitButton and brought the style in line with the one typically provided by TabView. * Some of our local controls have had their backgrounds removed so they're more amenable to being placed on other surfaces. * I'm suppressing the TabView's padding. * I removed a number of apparently dead methods from App. * I've simplified the dragbar's sizing logic and eventing. * The winmd harvester needed to be taught to not try to copy winmds for framework packages. * We now only initialize the terminal once we know the size Closes #1896. Closes #444. Closes #857. Closes #771. Closes #760.
2019-10-15 07:41:43 +02:00
<!-- U+E710 is the fancy plus icon. -->
<mux:SplitButton.Resources>
<!-- Override the SplitButton* resources to match the tab view's button's styles. -->
<ResourceDictionary>
<ResourceDictionary.ThemeDictionaries>
<ResourceDictionary x:Key="Light">
Update colors of our custom NewTab button to match MUX's TabView (#6812) Update colors of our custom NewTab button to match MUX's TabView button MUX has a NewTab button, but Terminal uses a homemade lookalike. The version in Terminal doesn't use the same brush color resources as MUX's button, so it looks very slightly different. This PR updates Terminal's button to use the exact same colors that MUX uses. I literally copied these brush names out of MUX source code. ## References This is the color version of the layout fix #6766 This is a prerequisite for fixing #5360 ## Detailed Description of the Pull Request / Additional comments The real reason that this matters is that once you flip on `ApplicationHighContrastAdjustment::None`, the existing colors will not work at all. The existing brushes are themed to black foreground on a black background when High Contrast (HC) Black theme is enabled. The only thing that's saving you is `ApplicationHighContrastAdjustment::Auto` is automatically backplating the glyphs on the buttons, which (by design) hides the fact that the colors are poor. The backplates are those ugly squares inside the buttons on the HC themes. Before I can push a PR that disables automatic backplating (set `ApplicationHighContrastAdjustment` to `None`), we'll need to select better brushes that work in HC mode. MUX has already selected brushes that work great in all modes, so it just makes sense to use their brushes. The one very subtle difference here is that, for non-HC themes, the glyph's foreground has a bit more contrast when the button is in hovered/pressed states. Again this slight difference hardly matters now, but using the correct brushes will become critical when we try to remove the HC backplating. Closes #6812
2020-07-07 22:40:01 +02:00
<StaticResource x:Key="SplitButtonBackground" ResourceKey="TabViewButtonBackground" />
<StaticResource x:Key="SplitButtonForeground" ResourceKey="TabViewButtonForeground" />
Upgrade to Microsoft.UI.Xaml 2.2 (#3027) * We had to move to the final API: * Items -> TabItems * Items.VectorChanged -> TabItemsChanged * TabClose -> TabCloseRequested * TabViewItem.Icon -> TabViewItem.IconSource * TabRowControl has been converted to a ContentPresenter, which simplifies its logic a little bit. * TerminalPage now differentiates MUX and WUX a little better * Because of the change from Icon to IconSource in TabViewItem, Utils::GetColoredIcon needed to be augmented to support MUX IconSources. It was still necessary to use for WUX, so it's been templatized. * I moved us from WUX SplitButton to MUX SplitButton and brought the style in line with the one typically provided by TabView. * Some of our local controls have had their backgrounds removed so they're more amenable to being placed on other surfaces. * I'm suppressing the TabView's padding. * I removed a number of apparently dead methods from App. * I've simplified the dragbar's sizing logic and eventing. * The winmd harvester needed to be taught to not try to copy winmds for framework packages. * We now only initialize the terminal once we know the size Closes #1896. Closes #444. Closes #857. Closes #771. Closes #760.
2019-10-15 07:41:43 +02:00
<StaticResource x:Key="SplitButtonBackgroundPressed" ResourceKey="TabViewItemHeaderBackgroundPressed" />
Update colors of our custom NewTab button to match MUX's TabView (#6812) Update colors of our custom NewTab button to match MUX's TabView button MUX has a NewTab button, but Terminal uses a homemade lookalike. The version in Terminal doesn't use the same brush color resources as MUX's button, so it looks very slightly different. This PR updates Terminal's button to use the exact same colors that MUX uses. I literally copied these brush names out of MUX source code. ## References This is the color version of the layout fix #6766 This is a prerequisite for fixing #5360 ## Detailed Description of the Pull Request / Additional comments The real reason that this matters is that once you flip on `ApplicationHighContrastAdjustment::None`, the existing colors will not work at all. The existing brushes are themed to black foreground on a black background when High Contrast (HC) Black theme is enabled. The only thing that's saving you is `ApplicationHighContrastAdjustment::Auto` is automatically backplating the glyphs on the buttons, which (by design) hides the fact that the colors are poor. The backplates are those ugly squares inside the buttons on the HC themes. Before I can push a PR that disables automatic backplating (set `ApplicationHighContrastAdjustment` to `None`), we'll need to select better brushes that work in HC mode. MUX has already selected brushes that work great in all modes, so it just makes sense to use their brushes. The one very subtle difference here is that, for non-HC themes, the glyph's foreground has a bit more contrast when the button is in hovered/pressed states. Again this slight difference hardly matters now, but using the correct brushes will become critical when we try to remove the HC backplating. Closes #6812
2020-07-07 22:40:01 +02:00
<StaticResource x:Key="SplitButtonForegroundPressed" ResourceKey="TabViewItemHeaderForegroundPressed" />
Upgrade to Microsoft.UI.Xaml 2.2 (#3027) * We had to move to the final API: * Items -> TabItems * Items.VectorChanged -> TabItemsChanged * TabClose -> TabCloseRequested * TabViewItem.Icon -> TabViewItem.IconSource * TabRowControl has been converted to a ContentPresenter, which simplifies its logic a little bit. * TerminalPage now differentiates MUX and WUX a little better * Because of the change from Icon to IconSource in TabViewItem, Utils::GetColoredIcon needed to be augmented to support MUX IconSources. It was still necessary to use for WUX, so it's been templatized. * I moved us from WUX SplitButton to MUX SplitButton and brought the style in line with the one typically provided by TabView. * Some of our local controls have had their backgrounds removed so they're more amenable to being placed on other surfaces. * I'm suppressing the TabView's padding. * I removed a number of apparently dead methods from App. * I've simplified the dragbar's sizing logic and eventing. * The winmd harvester needed to be taught to not try to copy winmds for framework packages. * We now only initialize the terminal once we know the size Closes #1896. Closes #444. Closes #857. Closes #771. Closes #760.
2019-10-15 07:41:43 +02:00
<StaticResource x:Key="SplitButtonBackgroundPointerOver" ResourceKey="TabViewItemHeaderBackgroundPointerOver" />
Update colors of our custom NewTab button to match MUX's TabView (#6812) Update colors of our custom NewTab button to match MUX's TabView button MUX has a NewTab button, but Terminal uses a homemade lookalike. The version in Terminal doesn't use the same brush color resources as MUX's button, so it looks very slightly different. This PR updates Terminal's button to use the exact same colors that MUX uses. I literally copied these brush names out of MUX source code. ## References This is the color version of the layout fix #6766 This is a prerequisite for fixing #5360 ## Detailed Description of the Pull Request / Additional comments The real reason that this matters is that once you flip on `ApplicationHighContrastAdjustment::None`, the existing colors will not work at all. The existing brushes are themed to black foreground on a black background when High Contrast (HC) Black theme is enabled. The only thing that's saving you is `ApplicationHighContrastAdjustment::Auto` is automatically backplating the glyphs on the buttons, which (by design) hides the fact that the colors are poor. The backplates are those ugly squares inside the buttons on the HC themes. Before I can push a PR that disables automatic backplating (set `ApplicationHighContrastAdjustment` to `None`), we'll need to select better brushes that work in HC mode. MUX has already selected brushes that work great in all modes, so it just makes sense to use their brushes. The one very subtle difference here is that, for non-HC themes, the glyph's foreground has a bit more contrast when the button is in hovered/pressed states. Again this slight difference hardly matters now, but using the correct brushes will become critical when we try to remove the HC backplating. Closes #6812
2020-07-07 22:40:01 +02:00
<StaticResource x:Key="SplitButtonForegroundPointerOver" ResourceKey="TabViewItemHeaderForegroundPointerOver" />
Upgrade to Microsoft.UI.Xaml 2.2 (#3027) * We had to move to the final API: * Items -> TabItems * Items.VectorChanged -> TabItemsChanged * TabClose -> TabCloseRequested * TabViewItem.Icon -> TabViewItem.IconSource * TabRowControl has been converted to a ContentPresenter, which simplifies its logic a little bit. * TerminalPage now differentiates MUX and WUX a little better * Because of the change from Icon to IconSource in TabViewItem, Utils::GetColoredIcon needed to be augmented to support MUX IconSources. It was still necessary to use for WUX, so it's been templatized. * I moved us from WUX SplitButton to MUX SplitButton and brought the style in line with the one typically provided by TabView. * Some of our local controls have had their backgrounds removed so they're more amenable to being placed on other surfaces. * I'm suppressing the TabView's padding. * I removed a number of apparently dead methods from App. * I've simplified the dragbar's sizing logic and eventing. * The winmd harvester needed to be taught to not try to copy winmds for framework packages. * We now only initialize the terminal once we know the size Closes #1896. Closes #444. Closes #857. Closes #771. Closes #760.
2019-10-15 07:41:43 +02:00
</ResourceDictionary>
<ResourceDictionary x:Key="Dark">
Update colors of our custom NewTab button to match MUX's TabView (#6812) Update colors of our custom NewTab button to match MUX's TabView button MUX has a NewTab button, but Terminal uses a homemade lookalike. The version in Terminal doesn't use the same brush color resources as MUX's button, so it looks very slightly different. This PR updates Terminal's button to use the exact same colors that MUX uses. I literally copied these brush names out of MUX source code. ## References This is the color version of the layout fix #6766 This is a prerequisite for fixing #5360 ## Detailed Description of the Pull Request / Additional comments The real reason that this matters is that once you flip on `ApplicationHighContrastAdjustment::None`, the existing colors will not work at all. The existing brushes are themed to black foreground on a black background when High Contrast (HC) Black theme is enabled. The only thing that's saving you is `ApplicationHighContrastAdjustment::Auto` is automatically backplating the glyphs on the buttons, which (by design) hides the fact that the colors are poor. The backplates are those ugly squares inside the buttons on the HC themes. Before I can push a PR that disables automatic backplating (set `ApplicationHighContrastAdjustment` to `None`), we'll need to select better brushes that work in HC mode. MUX has already selected brushes that work great in all modes, so it just makes sense to use their brushes. The one very subtle difference here is that, for non-HC themes, the glyph's foreground has a bit more contrast when the button is in hovered/pressed states. Again this slight difference hardly matters now, but using the correct brushes will become critical when we try to remove the HC backplating. Closes #6812
2020-07-07 22:40:01 +02:00
<StaticResource x:Key="SplitButtonBackground" ResourceKey="TabViewButtonBackground" />
<StaticResource x:Key="SplitButtonForeground" ResourceKey="TabViewButtonForeground" />
Upgrade to Microsoft.UI.Xaml 2.2 (#3027) * We had to move to the final API: * Items -> TabItems * Items.VectorChanged -> TabItemsChanged * TabClose -> TabCloseRequested * TabViewItem.Icon -> TabViewItem.IconSource * TabRowControl has been converted to a ContentPresenter, which simplifies its logic a little bit. * TerminalPage now differentiates MUX and WUX a little better * Because of the change from Icon to IconSource in TabViewItem, Utils::GetColoredIcon needed to be augmented to support MUX IconSources. It was still necessary to use for WUX, so it's been templatized. * I moved us from WUX SplitButton to MUX SplitButton and brought the style in line with the one typically provided by TabView. * Some of our local controls have had their backgrounds removed so they're more amenable to being placed on other surfaces. * I'm suppressing the TabView's padding. * I removed a number of apparently dead methods from App. * I've simplified the dragbar's sizing logic and eventing. * The winmd harvester needed to be taught to not try to copy winmds for framework packages. * We now only initialize the terminal once we know the size Closes #1896. Closes #444. Closes #857. Closes #771. Closes #760.
2019-10-15 07:41:43 +02:00
<StaticResource x:Key="SplitButtonBackgroundPressed" ResourceKey="TabViewItemHeaderBackgroundPressed" />
Update colors of our custom NewTab button to match MUX's TabView (#6812) Update colors of our custom NewTab button to match MUX's TabView button MUX has a NewTab button, but Terminal uses a homemade lookalike. The version in Terminal doesn't use the same brush color resources as MUX's button, so it looks very slightly different. This PR updates Terminal's button to use the exact same colors that MUX uses. I literally copied these brush names out of MUX source code. ## References This is the color version of the layout fix #6766 This is a prerequisite for fixing #5360 ## Detailed Description of the Pull Request / Additional comments The real reason that this matters is that once you flip on `ApplicationHighContrastAdjustment::None`, the existing colors will not work at all. The existing brushes are themed to black foreground on a black background when High Contrast (HC) Black theme is enabled. The only thing that's saving you is `ApplicationHighContrastAdjustment::Auto` is automatically backplating the glyphs on the buttons, which (by design) hides the fact that the colors are poor. The backplates are those ugly squares inside the buttons on the HC themes. Before I can push a PR that disables automatic backplating (set `ApplicationHighContrastAdjustment` to `None`), we'll need to select better brushes that work in HC mode. MUX has already selected brushes that work great in all modes, so it just makes sense to use their brushes. The one very subtle difference here is that, for non-HC themes, the glyph's foreground has a bit more contrast when the button is in hovered/pressed states. Again this slight difference hardly matters now, but using the correct brushes will become critical when we try to remove the HC backplating. Closes #6812
2020-07-07 22:40:01 +02:00
<StaticResource x:Key="SplitButtonForegroundPressed" ResourceKey="TabViewItemHeaderForegroundPressed" />
Upgrade to Microsoft.UI.Xaml 2.2 (#3027) * We had to move to the final API: * Items -> TabItems * Items.VectorChanged -> TabItemsChanged * TabClose -> TabCloseRequested * TabViewItem.Icon -> TabViewItem.IconSource * TabRowControl has been converted to a ContentPresenter, which simplifies its logic a little bit. * TerminalPage now differentiates MUX and WUX a little better * Because of the change from Icon to IconSource in TabViewItem, Utils::GetColoredIcon needed to be augmented to support MUX IconSources. It was still necessary to use for WUX, so it's been templatized. * I moved us from WUX SplitButton to MUX SplitButton and brought the style in line with the one typically provided by TabView. * Some of our local controls have had their backgrounds removed so they're more amenable to being placed on other surfaces. * I'm suppressing the TabView's padding. * I removed a number of apparently dead methods from App. * I've simplified the dragbar's sizing logic and eventing. * The winmd harvester needed to be taught to not try to copy winmds for framework packages. * We now only initialize the terminal once we know the size Closes #1896. Closes #444. Closes #857. Closes #771. Closes #760.
2019-10-15 07:41:43 +02:00
<StaticResource x:Key="SplitButtonBackgroundPointerOver" ResourceKey="TabViewItemHeaderBackgroundPointerOver" />
Update colors of our custom NewTab button to match MUX's TabView (#6812) Update colors of our custom NewTab button to match MUX's TabView button MUX has a NewTab button, but Terminal uses a homemade lookalike. The version in Terminal doesn't use the same brush color resources as MUX's button, so it looks very slightly different. This PR updates Terminal's button to use the exact same colors that MUX uses. I literally copied these brush names out of MUX source code. ## References This is the color version of the layout fix #6766 This is a prerequisite for fixing #5360 ## Detailed Description of the Pull Request / Additional comments The real reason that this matters is that once you flip on `ApplicationHighContrastAdjustment::None`, the existing colors will not work at all. The existing brushes are themed to black foreground on a black background when High Contrast (HC) Black theme is enabled. The only thing that's saving you is `ApplicationHighContrastAdjustment::Auto` is automatically backplating the glyphs on the buttons, which (by design) hides the fact that the colors are poor. The backplates are those ugly squares inside the buttons on the HC themes. Before I can push a PR that disables automatic backplating (set `ApplicationHighContrastAdjustment` to `None`), we'll need to select better brushes that work in HC mode. MUX has already selected brushes that work great in all modes, so it just makes sense to use their brushes. The one very subtle difference here is that, for non-HC themes, the glyph's foreground has a bit more contrast when the button is in hovered/pressed states. Again this slight difference hardly matters now, but using the correct brushes will become critical when we try to remove the HC backplating. Closes #6812
2020-07-07 22:40:01 +02:00
<StaticResource x:Key="SplitButtonForegroundPointerOver" ResourceKey="TabViewItemHeaderForegroundPointerOver" />
Upgrade to Microsoft.UI.Xaml 2.2 (#3027) * We had to move to the final API: * Items -> TabItems * Items.VectorChanged -> TabItemsChanged * TabClose -> TabCloseRequested * TabViewItem.Icon -> TabViewItem.IconSource * TabRowControl has been converted to a ContentPresenter, which simplifies its logic a little bit. * TerminalPage now differentiates MUX and WUX a little better * Because of the change from Icon to IconSource in TabViewItem, Utils::GetColoredIcon needed to be augmented to support MUX IconSources. It was still necessary to use for WUX, so it's been templatized. * I moved us from WUX SplitButton to MUX SplitButton and brought the style in line with the one typically provided by TabView. * Some of our local controls have had their backgrounds removed so they're more amenable to being placed on other surfaces. * I'm suppressing the TabView's padding. * I removed a number of apparently dead methods from App. * I've simplified the dragbar's sizing logic and eventing. * The winmd harvester needed to be taught to not try to copy winmds for framework packages. * We now only initialize the terminal once we know the size Closes #1896. Closes #444. Closes #857. Closes #771. Closes #760.
2019-10-15 07:41:43 +02:00
</ResourceDictionary>
<ResourceDictionary x:Key="HighContrast">
Update colors of our custom NewTab button to match MUX's TabView (#6812) Update colors of our custom NewTab button to match MUX's TabView button MUX has a NewTab button, but Terminal uses a homemade lookalike. The version in Terminal doesn't use the same brush color resources as MUX's button, so it looks very slightly different. This PR updates Terminal's button to use the exact same colors that MUX uses. I literally copied these brush names out of MUX source code. ## References This is the color version of the layout fix #6766 This is a prerequisite for fixing #5360 ## Detailed Description of the Pull Request / Additional comments The real reason that this matters is that once you flip on `ApplicationHighContrastAdjustment::None`, the existing colors will not work at all. The existing brushes are themed to black foreground on a black background when High Contrast (HC) Black theme is enabled. The only thing that's saving you is `ApplicationHighContrastAdjustment::Auto` is automatically backplating the glyphs on the buttons, which (by design) hides the fact that the colors are poor. The backplates are those ugly squares inside the buttons on the HC themes. Before I can push a PR that disables automatic backplating (set `ApplicationHighContrastAdjustment` to `None`), we'll need to select better brushes that work in HC mode. MUX has already selected brushes that work great in all modes, so it just makes sense to use their brushes. The one very subtle difference here is that, for non-HC themes, the glyph's foreground has a bit more contrast when the button is in hovered/pressed states. Again this slight difference hardly matters now, but using the correct brushes will become critical when we try to remove the HC backplating. Closes #6812
2020-07-07 22:40:01 +02:00
<StaticResource x:Key="SplitButtonBackground" ResourceKey="TabViewButtonBackground" />
<StaticResource x:Key="SplitButtonForeground" ResourceKey="TabViewButtonForeground" />
Upgrade to Microsoft.UI.Xaml 2.2 (#3027) * We had to move to the final API: * Items -> TabItems * Items.VectorChanged -> TabItemsChanged * TabClose -> TabCloseRequested * TabViewItem.Icon -> TabViewItem.IconSource * TabRowControl has been converted to a ContentPresenter, which simplifies its logic a little bit. * TerminalPage now differentiates MUX and WUX a little better * Because of the change from Icon to IconSource in TabViewItem, Utils::GetColoredIcon needed to be augmented to support MUX IconSources. It was still necessary to use for WUX, so it's been templatized. * I moved us from WUX SplitButton to MUX SplitButton and brought the style in line with the one typically provided by TabView. * Some of our local controls have had their backgrounds removed so they're more amenable to being placed on other surfaces. * I'm suppressing the TabView's padding. * I removed a number of apparently dead methods from App. * I've simplified the dragbar's sizing logic and eventing. * The winmd harvester needed to be taught to not try to copy winmds for framework packages. * We now only initialize the terminal once we know the size Closes #1896. Closes #444. Closes #857. Closes #771. Closes #760.
2019-10-15 07:41:43 +02:00
<StaticResource x:Key="SplitButtonBackgroundPressed" ResourceKey="TabViewItemHeaderBackgroundPressed" />
Update colors of our custom NewTab button to match MUX's TabView (#6812) Update colors of our custom NewTab button to match MUX's TabView button MUX has a NewTab button, but Terminal uses a homemade lookalike. The version in Terminal doesn't use the same brush color resources as MUX's button, so it looks very slightly different. This PR updates Terminal's button to use the exact same colors that MUX uses. I literally copied these brush names out of MUX source code. ## References This is the color version of the layout fix #6766 This is a prerequisite for fixing #5360 ## Detailed Description of the Pull Request / Additional comments The real reason that this matters is that once you flip on `ApplicationHighContrastAdjustment::None`, the existing colors will not work at all. The existing brushes are themed to black foreground on a black background when High Contrast (HC) Black theme is enabled. The only thing that's saving you is `ApplicationHighContrastAdjustment::Auto` is automatically backplating the glyphs on the buttons, which (by design) hides the fact that the colors are poor. The backplates are those ugly squares inside the buttons on the HC themes. Before I can push a PR that disables automatic backplating (set `ApplicationHighContrastAdjustment` to `None`), we'll need to select better brushes that work in HC mode. MUX has already selected brushes that work great in all modes, so it just makes sense to use their brushes. The one very subtle difference here is that, for non-HC themes, the glyph's foreground has a bit more contrast when the button is in hovered/pressed states. Again this slight difference hardly matters now, but using the correct brushes will become critical when we try to remove the HC backplating. Closes #6812
2020-07-07 22:40:01 +02:00
<StaticResource x:Key="SplitButtonForegroundPressed" ResourceKey="TabViewItemHeaderForegroundPressed" />
Upgrade to Microsoft.UI.Xaml 2.2 (#3027) * We had to move to the final API: * Items -> TabItems * Items.VectorChanged -> TabItemsChanged * TabClose -> TabCloseRequested * TabViewItem.Icon -> TabViewItem.IconSource * TabRowControl has been converted to a ContentPresenter, which simplifies its logic a little bit. * TerminalPage now differentiates MUX and WUX a little better * Because of the change from Icon to IconSource in TabViewItem, Utils::GetColoredIcon needed to be augmented to support MUX IconSources. It was still necessary to use for WUX, so it's been templatized. * I moved us from WUX SplitButton to MUX SplitButton and brought the style in line with the one typically provided by TabView. * Some of our local controls have had their backgrounds removed so they're more amenable to being placed on other surfaces. * I'm suppressing the TabView's padding. * I removed a number of apparently dead methods from App. * I've simplified the dragbar's sizing logic and eventing. * The winmd harvester needed to be taught to not try to copy winmds for framework packages. * We now only initialize the terminal once we know the size Closes #1896. Closes #444. Closes #857. Closes #771. Closes #760.
2019-10-15 07:41:43 +02:00
<StaticResource x:Key="SplitButtonBackgroundPointerOver" ResourceKey="TabViewItemHeaderBackgroundPointerOver" />
Update colors of our custom NewTab button to match MUX's TabView (#6812) Update colors of our custom NewTab button to match MUX's TabView button MUX has a NewTab button, but Terminal uses a homemade lookalike. The version in Terminal doesn't use the same brush color resources as MUX's button, so it looks very slightly different. This PR updates Terminal's button to use the exact same colors that MUX uses. I literally copied these brush names out of MUX source code. ## References This is the color version of the layout fix #6766 This is a prerequisite for fixing #5360 ## Detailed Description of the Pull Request / Additional comments The real reason that this matters is that once you flip on `ApplicationHighContrastAdjustment::None`, the existing colors will not work at all. The existing brushes are themed to black foreground on a black background when High Contrast (HC) Black theme is enabled. The only thing that's saving you is `ApplicationHighContrastAdjustment::Auto` is automatically backplating the glyphs on the buttons, which (by design) hides the fact that the colors are poor. The backplates are those ugly squares inside the buttons on the HC themes. Before I can push a PR that disables automatic backplating (set `ApplicationHighContrastAdjustment` to `None`), we'll need to select better brushes that work in HC mode. MUX has already selected brushes that work great in all modes, so it just makes sense to use their brushes. The one very subtle difference here is that, for non-HC themes, the glyph's foreground has a bit more contrast when the button is in hovered/pressed states. Again this slight difference hardly matters now, but using the correct brushes will become critical when we try to remove the HC backplating. Closes #6812
2020-07-07 22:40:01 +02:00
<StaticResource x:Key="SplitButtonForegroundPointerOver" ResourceKey="TabViewItemHeaderForegroundPointerOver" />
Upgrade to Microsoft.UI.Xaml 2.2 (#3027) * We had to move to the final API: * Items -> TabItems * Items.VectorChanged -> TabItemsChanged * TabClose -> TabCloseRequested * TabViewItem.Icon -> TabViewItem.IconSource * TabRowControl has been converted to a ContentPresenter, which simplifies its logic a little bit. * TerminalPage now differentiates MUX and WUX a little better * Because of the change from Icon to IconSource in TabViewItem, Utils::GetColoredIcon needed to be augmented to support MUX IconSources. It was still necessary to use for WUX, so it's been templatized. * I moved us from WUX SplitButton to MUX SplitButton and brought the style in line with the one typically provided by TabView. * Some of our local controls have had their backgrounds removed so they're more amenable to being placed on other surfaces. * I'm suppressing the TabView's padding. * I removed a number of apparently dead methods from App. * I've simplified the dragbar's sizing logic and eventing. * The winmd harvester needed to be taught to not try to copy winmds for framework packages. * We now only initialize the terminal once we know the size Closes #1896. Closes #444. Closes #857. Closes #771. Closes #760.
2019-10-15 07:41:43 +02:00
</ResourceDictionary>
</ResourceDictionary.ThemeDictionaries>
</ResourceDictionary>
</mux:SplitButton.Resources>
</mux:SplitButton>
</mux:TabView.TabStripFooter>
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
</mux:TabView>
Upgrade to Microsoft.UI.Xaml 2.2 (#3027) * We had to move to the final API: * Items -> TabItems * Items.VectorChanged -> TabItemsChanged * TabClose -> TabCloseRequested * TabViewItem.Icon -> TabViewItem.IconSource * TabRowControl has been converted to a ContentPresenter, which simplifies its logic a little bit. * TerminalPage now differentiates MUX and WUX a little better * Because of the change from Icon to IconSource in TabViewItem, Utils::GetColoredIcon needed to be augmented to support MUX IconSources. It was still necessary to use for WUX, so it's been templatized. * I moved us from WUX SplitButton to MUX SplitButton and brought the style in line with the one typically provided by TabView. * Some of our local controls have had their backgrounds removed so they're more amenable to being placed on other surfaces. * I'm suppressing the TabView's padding. * I removed a number of apparently dead methods from App. * I've simplified the dragbar's sizing logic and eventing. * The winmd harvester needed to be taught to not try to copy winmds for framework packages. * We now only initialize the terminal once we know the size Closes #1896. Closes #444. Closes #857. Closes #771. Closes #760.
2019-10-15 07:41:43 +02:00
</ContentPresenter>
Reference in a new issue Copy permalink