This adds [`XamlStyler.Console`] to our solution, and calls it when we
format the code, to also format
our .xaml files.
* `XamlStyler.Console` is a dotnet tool so it needs to be restored with
`dotnet tool restore`
* I've added a set of rules to approximately follow [@cmaneu's XAML guidelines].
Those guidelines also recommend things based on the code-behind, which
this tool can't figure out, but also _don't matter that much_.
* There's an extra step to strip BOMs from the output, since Xaml Styler
adds a BOM by default. Some had them before and others didn't. BOMs
have been nothing but trouble though.
[`XamlStyler.Console`]: https://github.com/Xavalon/XamlStyler
[@cmaneu's XAML guidelines]: https://github.com/cmaneu/xaml-coding-guidelines
<!-- 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
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>
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
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:
New appearance with this PR:
Most important deltas highlighted with red circles:
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.
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
* 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.
* 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 e038b5d921.
* 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?
