The plus glyph will probably shrink, I commented on the TabControl issue, and it seems they will push the change, to match the smaller glyph used by UWP Edge.

Yeah, I think we can all agree "make the tabs like Edge Chrome" is nice, but "make the tabs like the promo video" is even better ... 😣

I think the UWP Edge had nicer tabs than Edge Chrome. 🤔

Personally I wish they'd make Edge Chrome's tabs like UWP Edge, but nobody asked me...

Yeah, yeah, but ... either of them is waaaay ahead of Terminal 🤡
Edgium has almost 20 pixels above the tabs that are ugly ... but ... draggable!
And with both of them, you can at least tell which tab is active 🙄

There is no PRACTICAL use for acrylic when coding. However transparency is very useful. It means I can view code beneath the Terminal window like this:

Please add an adjustment for the BLUR factor that acrylic uses. I can't read blurred out text.

Also if the Terminal did not go black when inactive like this:

it would be really useful to be able to have a pin button which pinned the terminal above all other windows. This would enable seamless switching between the terminal and whatever code editor you are using (especially if you can read code beneath the Terminal window.)
I suggest that the acrylic theme should stay active instead of "going black" if an "Always on top" feature is added and enabled.

What it could look like:

The pin icon, to pin the Terminal above all windows.
@nacorv,

I would like to know if "Always on top" is a feature that would be considered.

Selecting and dragging anywhere within the tab area currently does not move the window. This makes it necessary to move the mouse to the right of the tab area, which leaves a very small amount of titlebar which can be used to move the window. Please change this. No rush!

1. Turning on acrylic in Powershell makes the purple parameters like -abc appear near invisible.

Resolution: 4K
Display Scaling: 100%

Light theme:

Dark theme:

Resizing the window causes the UI to disapper/reappear. I am using the Windows Store Preview Version 0.2.1715.0

Fullscreen:

Resized:

If the window is not big enough, all the other tabs are hidden.

If the tab bar can't be acrylic, that's a major shame.
Anything that can be done to make them integrate better would be most welcome

The non drag-able tab/title bar is the #1 complaint I've heard from everyone that has tried the early builds

Split panes need some visual polish, make it clear which is in focus, some animation even as it opens

When maximised on my 2nd monitor (1366x768 laptop built-in display, not set as main), the edges of the app are cut off:

Tabs show the path to the executable instead of the name of the app; if the path is too long, the "x" to close the tab is pushed off the right side of the tab and is invisible.

Clicking "Settings" attempts to open a JSON file. I'm guessing that the UI for that hasn't been built yet. :)

As an addition to @robster2001's comments, it'd be nice if each tab showed the actual path like Ubuntu and if it was in administrator mode (e.g. Command Prompt (Admin) - C:currentpaththatyouarein).

When you don't have terminal maximized, as I usually don't, the issue #857 combined with the long titles allows for much less tabs than what it could be.

The tabs are just too wide to be useful. Perhaps just show the executable and give the path/etc information when you hover over the tab in a tooltip or something.

Two things:
Panes are not bound by default _because_ they are incomplete. If you enable them yourself, YMMV.

If you want a custom tab title, you should look at how to set that up for your shell. It’ll benefit you everywhere you use your shell. By making powershell set the title, you change the title for Windows Terminal, legacy console, VSCode, ConEmu and a bunch of other things. It can even change in the middle of a session!

Panes epic: #1000

I couldn't find anywhere along the caption at the top of the window that allowed me to drag and move the window. I had to resort to keyboard shortcuts.

two-finger scrolling doesn't work, although it works great on cmd.com and PowerShell.

Tabs cannot be moved/rearranged.

Default bar does not respect the Win10 Dark Theme:

I tried to find settings, but didn't find it!
Some other apps does not respect either, so I think is not considered on this version

My first impression of Terminal, installed today via the Store preview was:

• What's wrong with the colors? Why is it part black, part white?
  
• Wow, can't wait to try the tabs
• Oh wow, that's a big plus sign

Is there anything we can do about the color of the titlebar? It should be all black, right?

+1 @guibirow

Messing around with my windows settings I could fix it:

Active (Firefox in the back, Terminal in front)

Inactive (Firefox in the back, Terminal in front)

Looks like some applications continue to load the settings from windows, maybe windows dark theme does not set all collors correctly, I had to enable the option to apply the accent to title bar and window borders.

And set the _AccentColorInactive_ in the registry [_ComputerHKEY_CURRENT_USERSoftwareMicrosoftWindowsDWM_]

The design would be much better if the "+ /" moved to the left (like below) and the rest become just the title bar like all other applicaitons, I think they tried to copy firefox and didn't work very well!

I can't 'pop a tab out' or drag it to another window. I'd like that feature.

Where Emoji font when used for example yarn, npm ?

Tab titlebar definitely needs cleaning up. Based on the official video made to promote the Terminal, and Edgemium, I came up with these changes (mock ups):

Before:

After:

Full list of changes in mock up:

• Reduced window border size to 1px to be consistent with the rest of Windows
• Aligned window controls (close, max, min) properly in the titlebar
• Made tabs a bit taller to be consistent with new Edge tabs
• Reduced corner radius to be consistent with new Edge tabs
• Added inner rounded corners to the base of tabs to be consistent with new Edge and official video
• Added drop shadow to make tabs more visible against the background, and to be consistent with new Edge
• Made the plus icon properly sized
• Moved the tab management buttons next to the tabs
• Made the background spread across the entire titlebar

EDIT: This was just an issue with the bottom line not being large enough to fit a whole character, as pointed out by @DHowett-MSFT below

Padding (bottom) is not 0 when maximized. Not sure if this is a known issue or intended, so putting it in this thread.

@mikelui huh, that's probably because there aren't enough pixels to fit another whole character cell on screen. the Terminal much prefers to display full rows, as that's how it models the terminal world.

Fullscreen:

Resized:

If the window is not big enough, all the other tabs are hidden.

If you rotate the mouse wheel, you will see the tabs slide. It works for atleast for Store Terminal Preview v0.2.1715.0 . But narrowing of icons, such as Chromium-based browsers, would be more nice.

@DHowett-MSFT Also i found out another gui bug, if window too small for showing new tab and we create a new tab, new tab created but not show until we re-size the Terminal window.

Microsoft Windows 10 Pro Insider Preview [Version 10.0.18875.1000]
Microsoft Terminal (Store Preview) [Version 0.2.1715.0]

@DHowett-MSFT Yes! I see that now while playing around with sizing. I'm used to using fullscreen (vs maximized), where the lack of a title bar makes the spacing better.

Make the initial window size as I left on previous time when closing.

grabbing and moving the application is not easy, need a larger area to grab the window. The whole path of the exe is overkill, it takes too much space. just Powershell or Cmd would be nice. while running node or python in cmd , tab can show "cmd : node" or "cmd : python"
Tabs can have the color theme of the scheme used in that specific terminal instead of just darker black or fade black, similar color to the terminal scheme may make finding a terminal easy.
edit
few more issues found

Also, not that important compared to other missing/broken UI things but still: the mouse pointer should be the text one (Ꮖ) when moving over some text in the terminal and not the pointer (↖) one since text is selectable.

Any chance Alt+F4 behaviour can mimic other Windows 10 functionality (close everything now) please? Ctrl+w * how ever many tabs are open is quite laborious. As is finding the top right X when I am in keyboard warrior mode :D.

I've tried setting closeWindow in settings.json but alt+F4 does not register as a valid command (console prints "S").

Out of curiosity, would it not be possible to use the underlying APIs that support WPF’s WindowChrome, cut out the native title bar and window borders entirely and build it all using XAML? I feel there’d be more control available this way and the end result would be cleaner and less dependent on the OS

I was initially expecting that split screen feature would have been already there, but it's not...
It would be much more convenient than navigating between tabs.

Terminator on Linux and iTerm on macOS has it neatly implemented.

Any plans?

Selecting and dragging anywhere within the tab area currently does not move the window. This makes it necessary to move the mouse to the right of the tab area, which leaves a very small amount of titlebar which can be used to move the window. Please change this. No rush!

see #1500

@LeeChang-GitHub #608, also, you know powershell and CMD have a way to set the title themselves, right? You don’t need to rename the tab when you can make the shell do it.

I need the name of the terminal to be editable.
I searched for this question but couldn't find it. Is this a reasonable requirement?

Dude, why did you delete your comment and move it after my response?

Dude, why did you delete your comment and move it after my response?

Sorry, that question was too bad. I edited it again, and I didn't receive your reply at that time.
so sorry

@LeeChang-GitHub it’s okay! 😄

I would like to know if "Always on top" is a feature that would be considered.

@grigala

I was initially expecting that split screen feature would have been already there, but it's not...
It would be much more convenient than navigating between tabs.

Terminator on Linux and iTerm on macOS has it neatly implemented.

Any plans?

1000 shows the plans and how far along they are 👍

Scrollbar should ignore the right padding or expand to the right when hovered. It is fine if it takes in count the top and the bottom.

Scrollbar in its collapsed form

Scrollbar in its wide form

The scrollbar in its collapsed form looks alright. The space between the text and the line is ok, but should follow the padding preferences. Right now it doesn't.

The scrollbar in its wide form follows the padding only on the right side and has some, but not the preferred, padding on the left side. The left padding should follow the preferences and the right padding should completely disappear. This would allow users to quickly throw their mouse cursor to the right when they wanna quickly scroll up a long distance and the window is maximized.

Additionally the scrollbar should have no delay of expanding when hovered and the scrollbar background should be transparent, so the blur (if toggled on) can be visible.

Edit:
This has been resolved in #1778. Thanks!!

Most Apps (like Chrome, or explorer.exe etc) allow user to resize the window by grab on the Window's shadow. But It seems that terminal only allow user to grab on a narrow NotClient Area(about 2 pixels).
Seem's the system default shadow doesn't work?

I have a possible solution.

1. Remove the system shadow (By changing Window style to WS_MINIMIZEBOX | WS_MAXIMIZEBOX | WS_POPUP | WS_THICKFRAME and handle WM_NCCALCSIZE message, you can use AdjustWindowRect to calculate the size.)
2. Add four small shadow window (WS_EX_OVERLAPPED | WS_EX_TOOLWINDOW) around the window, and render shadow manually (by handling main windows's WM_WINDOWPOSCHANGED to move the shadow window, handlling WM_SIZE to render the shadow window, maybe Gaussina Blur ?)
   3 handle the shadow window's WM_SETCURSOR message, and WM_LBUTTONDOWN (Send WM_SYSCOMMAND to the main window to simulate grabbing)

Besides, Use Window Subclassing technology to capture message and send WM_SYSCOMMAND when handling WM_LBUTTONDOWN may fix the proble that title bar can't be grabbed.

To expand on https://github.com/microsoft/terminal/issues/1375#issuecomment-504686188, Terminal should maybe organize themes into theme family names and light/dark subcategories, sort of like VSCode. I.e. if I set the theme to e.g. "Campbell" and switch Windows app colors from light to dark, I'd expect Termianl to switch from Campbell Light to Campbell Dark. This would save manual fiddling. Specifying "Campbell Dark" as the theme would pin appearance to the dark theme, if you always want it to be dark. Or something.

The tabs space doesn't resize correctly when moving the window between monitors with different scalings, in some cases covering even the minimize button:

Monitor 1, 1920x1080 resolution, 100% scaling:

Monitor 2, 4k resolution (3840x2160), 200% scaling:

Cursor color should be defined by the theme. The default cursor color set in the profile is white, which is useless on a light theme.

@madig - You can change the cursor colour by setting cursorColor in profiles.json

@madig - You can change the cursor colour by setting cursorColor in profiles.json

Yes, but the theme should define it so you don't have to edit theme name _and_ cursor color when you want to switch around.

I also noted that it's much harder than usual to get the mouse cursor to be in the window-resize configuration when positioning it on the bottom-right corner of the terminal window.

Maybe #1517.

A context/system menu for the App. Win32 apps have this in the upper-left corner. Some, like Edge, use the ellipsis in the upper-right. Is the current drop-down an intended replacement?

The upper-left style is useful when moving / resizing etc by keyboard.

I got the impression from the Build presentation we'd have split pane like functionality, is this planned?

@jwhipp #1000

Icons seem to be missing?

Looks like you’ve got an outdated profile from the first open source release. Probably delete it.

Thanks, that worked!

However, I found another bug:

I frequently double-click on title bars to maximise or restore a window. The clickable area of the window (green) was all the way over the right when I only had one tab open. It looked like I could click to the left of the plus (new tab) menu.

ConEmu doesn't have this issue since the title bar is above the tabs. Double-clicks in the tab area result in a new tab which what I'd like to see with the new Windows Terminal, but I'm sure I'll adjust to whatever we eventually land on.

Regarding the tabs etc. it would be great if they could visually behave similar as those in e.g. Edge: the "+ v" button always being next to the latest tab; making the area (if any) between the last tab and the "+ v" button receiving mouse events (by passing them to the parent window); having "<" and ">" scrolling buttons appearing (similarly to e.g. in Firefox) when there are too many tabs.

I frequently double-click on title bars to maximise or restore a window. The clickable area of the window (green) was all the way over the right when I only had one tab open.

Which also means, that we can't drag the terminal window (I mean you _can_, but then you really need to be sure you just get that tiny sweet spot...)

Tabs in title bar is bad. Don't do it. PLEASE. don't do it. You're using too much area for multiple tasks.

Having tab titles the entire path to the command interpreter is also bad. That the tab names can get longer than maybe 20 characters, is bad. Much shorter maximum tab size. Tabs below the title bar. Much smaller tabs.

It’s an option. Options. Configuration. Lists of short sentences. Turn them off. :smile:

@brianly Set "showTabsInTitlebar" : false in the settings.

Thanks @zadjii-msft! Also worth linking: https://github.com/microsoft/terminal/issues/771

When adding a new tab with few already opened to fill the space on tab space like this

new tab is created, but icon is folded.

any new created tab after that is invisible.
Resizing window fixes issue.

It's not possible to rearrange tabs.
Additionally when closing the only tab with middle mouse button this happens:

Something visible on screen or in a menu for controlling zoom would be great. As well as a way to reset zoom from Ctrl+Scroll. No way to tell if I'm at 200% zoom or not.

For example, chrome has this menu item in their hamburger menu. All it needs is one line. Clicking on the value resets it to 100%.

I'd love to be able to affect the tab color and possibly the border color for a given console. For example, instead of coloring the PowerShell background all blue, just have the tab and border be blue but have the background be whatever easy-on-the-eyes color I want.

If possible... it might be interesting to be able to affect those things from the running console environment. For example, if my PowerShell console starts up and sets an environment value like WINDOWS_TERMINAL_BORDER_COLOR=#ff0000 because it's an admin console, have the border switch colors to red. You could do a lot of interesting things from a PowerShell profile or .bashrc that way.

@DHowett-MSFT @DHowett I saw that there is a way of extending acrylic into the title bar. Maybe this could work?

Clicking on a tab in the terminal doesn't always seem to give the tab focus.

• Open Terminal with your favorite shell.
• Click on some other window or app.
• Click on the _tab_ for your shell in Terminal. The cursor doesn't show up and typing doesn't work. You have to click the Terminal window title bar (that little bit between the "+" and the minimize/maximize buttons, the only part that currently allows the window to move) and _that_ is what gives focus back to the shell.

Maximize window button doesn't look like in most apps. It looks more like a minimize button:

@krzysdz you're running a build out of this repository that just had the first non-client drawing changes merged. I'll have to ask you to not report UI issues in it. #1625.

Not a huge fan of how the + button works. I keep clicking it to add a new tab, forgetting that it just makes a new tab in the default shell (which is pretty annoying). I'd love for an option that lets me have a drop down like the one that appears when clicking the down arrow, so I can select from the list of available shells when adding a new tab.

Well at that point why not just click the dropdown arrow?

There is nothing preventing me from clicking the dropdown arrow, this is purely a UX issue. Functionally speaking, it doesn't make a lot of sense to me to click a button that bears no symbolic indication that it adds a tab in order to perform that action.

Shouldn't acrylic be enabled by default for PowerShell? Having cmd looking better than PowerShell by default is not a great sign imo. It would also be better to welcome the user by showing off the eye candy.

Default settings:

With cmd:
image

With PowerShell:
image

Related profiles:
image

EDIT: turned the images into links, that took too much space, sorry

So is this just a reskin or a container for the original consoles (cmd, wsl, and ps)?

I was hoping for a better terminal like those found in Linux or Mac OSX. Cmdr is a good example of what you should be aiming for. Mostly I would just like a terminal that supports CTRL-C and CTRL-V and seamless WSL integration.

@deusprogrammer it's a terminal, exactly like ConEmu (the terminal cmder uses). Cmder is a bit unique because it bundles a terminal and shell improvements for people who use the cmd shell.

I would like to know if "Always on top" is a feature that would be considered.

I would like to see this feature as well.

Maybe a minor thing, but acrylic doesn't mean anything to anyone not familiar with UWP and/or Windows app dev. A friendlier name (translucent or something) would help.

The title bar isn't acrylic, sorry, that one probably can't happen given our architecture

This should be enabled when WinUI 3 released
Ref: microsoft/microsoft-ui-xaml#888

Just tried the terminal, first thing that knocks me off is...

Y U NO DRAG ON THIS AREA? it's annoying, heck!

Yes, this knocks off you and the four hundred other folks who reported it. :smile: Track #1625 and #564 for actual progress on the top part of the window.

@DHowett-MSFT , if not mentioned please do consider keeping both acrylic and transparency option in the settings, acrylic makes it consistent with the system but doesn't make much sense for an application like terminal, where the ability to see what is behind can be quite productive. It would be more helpful to have a transparency option. Let it come acrylic on by default and transparency can be toggled manually.

@DHowett-MSFT wrote :

[...]

• The tabs don't look as good as you'd like #702

[...]

• The plus button is too big, too small, too wide, too narrow

[...]

that funny or salty?

It seems that the tab titles don't respect any of the fontSize settings:

it would be really useful to be able to have a hot key to active terminal like yakuake terminal.

It seems that the tab titles don't respect any of the fontSize settings:

I believe that's to be expected. The tabs seem to follow the desktop font size, being considered as part of the window header/bar.

it would be really useful to be able to have a hot key to active terminal like yakuake terminal.

Not familiar with that terminal, but there's a ton of things you can hotkey in the settings.json, to open, close, switch, etc.

Two thoughts off the bat about adopting the "common tab use" (see also https://github.com/microsoft/terminal/issues/615)

1. Tabs should squash/shrink when there's not enough space for them
2. The plus button should anchor to the right side of the last tab, not to the top right of the window

General feedback for OP. Obviously, it is understood that this is an early release/preview but we can already see a very solid design and concept.

I dig the tabs, the level of customization (esp. with the executable customization!), the real-time updates to changes in settings.json, and the different type of terminals that can be had in a single executable.

Beyond the above items mentioned and polishing, I'd appreciate to have a built-in way of logging what goes to standard output in any terminal window, ideally allowing for all to be logged in one file, or multiple files. Also, I'd add the option to "clone" or "duplicate" and place the tabs in windows/rows/columns the way its possible to do it in vs code.

Thanks for your hard work, gonna be looking forward the next release!

I'm using the dark theme but am still seeing a white border and header are still white. Anyone else having this problem? I couldn't find anything in the JSON that modifies this.

I have the same problem :(

I'm using the dark theme but am still seeing a white border and header are still white.

This is not fixable with the settings currently. This is a future work item, partially being tracked in #1625

I'd appreciate to have a built-in way of logging what goes to standard output in any terminal window, ideally allowing for all to be logged in one file, or multiple files.

642

place the tabs in windows/rows/columns the way its possible to do it in vs code.

1000

@DHowett-MSFT take a look at the way this app manages tabs,
https://github.com/JasonStein/Notepads

Okay, done. What was I looking for?

You can also look at Fluent Terminal for inspiration. It has pretty good UI.

1. When using Powershell Core I would get a second chevron randomly appear at the console, would look D:\>> (sorry, no repro steps)
2. I cannot drag text then Copy-Paste, this is a feature I've come to expect with Powershell

UI is ugly now, and i want a beautiful UI which can makes me work better.

Tabs show the path to the executable instead of the name of the app; if the path is too long, the "x" to close the tab is pushed off the right side of the tab and is invisible.

Also tabTitle actually not work

Tabs show the path to the executable instead of the name of the app; if the path is too long, the "x" to close the tab is pushed off the right side of the tab and is invisible.

Also tabTitle actually not work

@Serega124 that is odd, as they work just fine for me. I named one tab wsl and the other cmd.
Are you running the latest dev build?

@imjasonmiller I am running the Store version

@Serega124, I think the tabTitle feature hasn't been released yet for the Store version. I think you might have to wait until they push another update for the Store version or you can build it from source.

The resize handle at the bottom-right on the Windows Store build is super small, it's kind of a frustrating UI target to interact with.

Feature request : Easy toggle between themes or use the Windows theme.

As a developer I work indoors and outdoors. Indoors on a UHD screen I prefer a dark theme. Outdoors a dark theme becomes unreadable on my laptop screen at full brightness. A light theme is useable

The resize handle at the bottom-right on the Windows Store build is super small, it's kind of a frustrating UI target to interact with.

That's true!
The sensible area in the corners is really small, so resizing the window is quite impossible.
I'm attaching a gif that can be helpful @DHowett-MSFT:

When I resize the window, the scroll bar stops moving the text up and down. Effectively useless until the command prompt reaches bottom of window.

Have to mention it now though, thank you for embarking on this project. A badly needed solution for Windows

Text background colors get messed up on resize

I assume it is related to "The non-client area looks wrong;" and is a work in progress, but the most recent build seems to have introduced a one pixel white border at the bottom for me:

Could this be related to this recent change?

Thanks for all the work so far!

@imjasonmiller if you want a riot (the sad sort), read the TODO at the bottom of #1948 :smile:

• [ ] Double click to non-client area should maximize the Window.
• [ ] Click/Right click icon should display Minimize/Maximize/Close menu
• [ ] When you click Cascade Windows , Show windows stacked etc is completely ignored by Terminal
• [ ] Alt+F4 doesn't close the Window

I believe is an expected behavior for a Windows user that a double click on the non-client maximize the window, also when you use shell to resize/tile windows the Terminal should just behave as any other window.

Right now my Terminal is unmovable, and is impossible to reach the settings menu.

It seems Terminal is a foreign application using a non-native UI toolkit.

Using the mouse:
You cannot context-menu-click on tabs to close them or see a context menu like in the past consoles, you also can't close tabs higher than the first (their X's get obscured by add tab button / setting menu button due to width constraints)

Ideally you should have ALT+ENTER and SHIFT+F10 and mouse/touch right click enabled.

Also +1 for reordering tabs

Updating text breaks sometimes.

This is especially an issue with editors like emacs

@RosalesJ Hey could you actually file another issue for that one? That doesn't actually fit in with the giant bucket of UI issues, and might be a much more atomic bug we could fix. Make sure to include repro steps and tools your using. Thanks!

The new tab menu doesn't move with the window:

Trying to close the app by clicking the X on the single tab results in the app crashing!

When the opacity is configured, it only works when the window is focused.
When focused:

When not focused:

Is there a way to make it work or it's supposed to work like that?

Edit: another thing that I noticed in the screenshots above is that non-focused terminal windows don't apply the Windows Accent color, going blank. When focused, the windows accent color is there.

@jean-lourenco I believe the blur thing is intentional, as other applications like the Settings app do the same thing

Really hoping for soon tab scrolling support (the indication, instead of mouse wheel only).

As my scrolling is not working as intended, now I cannot see the tabs I have..

Bad spacing with non-monospace font.

version 0.3.2112.0

This happens on initial loading. Maximizing -> Restoring window corrects this.

I just updated to 0.2.1831.0 in 18950.1000. In an Ubuntu shell (now WSL 2), I can't scroll back the buffer. It looks like the flashing cursor is pulling the focus back to the bottom line every time I try to scroll up with both the keyboard and the mouse wheel.

It also looks like a new line is sent on every scroll up too, so the text I want to see gets further away on each attempt!

Powershell and Dos windows do not do this

@tomfakes migrated this one to #2196, as it is absolutely not a UI polish issue

怎么才能让窗口失去焦点的时候保持Acrylic效果

The ability to drag the window by the whole tab bar is slightly misleading; you can still not grab the title bar by the area above the tabs or by grabbing tabs proper. If you have a lot of tabs open, that means you're still stuck with a tiny drag area.

Is that something planned on being addressed? It appears #564 was closed.

Maximizing terminal when window is across two monitors causes bars to bleed across monitor.

I know this is sort of "off topic", but the issue tracker is the only place to leave feedback and this seems to be the best suited thread: Thank you. I know the Terminal is not finished yet and there are a lot of things that need to be fixed, but it's on a good way. I like how it feels and looks. I like the configuration, the support for "CMD", powershell, WSL, etc.
Keep up the good work ^^ (and sorry cluttering up the issue tracker ;))

Glad this project is in the works - big step up over traditional cmd/powershell. I noticed that when closing the window after resizing rapidly causes a ghost window to show up with many borders:

This isn't really a major issue, just thought I'd report seeing it for the record.

+1

+1

@ammoniak thank you :smile:

I'm not sure if this is a bug or a feature.

AltGr+4 (§) (portuguese keyboard) does not get deleted as I'm trying AltGr sequences.

Victor Mono font renders really strangely.

https://github.com/rubjo/victor-mono/

@offero that's a nice-looking font; this may be #696

(or a variation thereof)

Can we get an option to hide the plus sign and/or the down arrow in the tabs area? When the down arrow would be hidden, it would be possible to right-click the plus sign which would then do the dropdown thing like the down arrow does. When the plus sign would be hidden, we would still be able to launch more tabs using the dropdown. Maybe we could hide both and then the right-clicking would happen on the rest of the titlebar?

I am honestly not loving the tabs in title bar as it's unruly when you have many, grabbing the title bar to move the window isn't working well still. Some of the Linux terminals have put tabs above the terminal itself and this configurable. I am sure this has a lot to do with Linux window managers being many and having different rules. Another option is make the terminals a drop down (see screenshot of Tilix). As it stands right now, if I 10 tabs open, how is this UI going to be usable? Mouse scrolling through is ok but it doesn't even give you a total of how many tabs are open.

Just my two cents. :)

Drop Down showing terminals/tabs:

I didn't see this mentioned in the thread, but if you want a smaller title tab, just add this setting to a profile:
"tabTitle": "MyCmd",

While this is very helpful, I would love to have the ability to dynamically increment a number so I can have:
| MyCmd 1 | MyCmd 2 | MyPosh 1 | MyPosh 2 |

And/or dynamically change the tab color based as new tabs are added - same color order each time so I know that Red = 1st tab, White = 2nd tab, Blue = 3rd tab, etc.

@jwhipp You can always set "showTabsInTitlebar" to false to get tabs below the titlebar.

@PedersenThomas That's #2028

@jwhipp You can always set "showTabsInTitlebar" to false to get tabs below the titlebar.

Ah! Didn't know about this...tried it just now. While it does is move the tab UI down, which ultimately allows one to more easily move the window, it still leaves the unruly tab ui. I just think this could be done better and in a more usable way. One thing that could work if you don't like the Tilix way is to shrink the tab size as more terminals appear. That would at least give the end user a sense of what's there more easily.

I'm guessing the massively thick window borders are a known issue?

When moving the terminal window with the dropdown list open, the dropdown list moves with a delay. I know that this has been reported but I think that to close the dropdown list when clicking outside the list is also a solution.

Most other application I have tested with similar dropdown list/menu/navigation closes when moving the window or clicking outside the list.

To my knowledge previously reported bugs have been to fix the delay. Not to close the list when moving the window by dragging the top bar. Which I think is a viable solution.

_By dropdown list I mean the list with profiles (WSL, Powershell), Settings and Feedback._

I honestly expected the terminal tab GUI to match what edge chromium looks like:

I'd agree that the height of the tabs seems a bit small

Change the Ubuntu icon to the one orange one used in the store please.

You can do that yourself.
This baby can hold so many icons

Change the Ubuntu icon to the one orange one used in the store please.

You can do that yourself.

Yeah but the default icon should be consistent, better to change it in once place than a few hundred thousand users' systems.

I'm pretty sure we're legally not allowed to ship any specific distro's branding directly. Something something copyright law. We are allowed to ship the tux penguin, hence why _all_ the distros use that penguin. @bitcrazed can @ me if I'm wrong on that.

Not sure if this has been suggested/asked already, but I am not a fan of each of the tabs being a different length, and I was wondering if there is a setting I can change to make it more browser-like in that each tab is the same length, and just has the type of terminal in the name.

I use a lot of tabs when working on unix, so I'm used to not getting any information from the tab heading and would prefer smaller tabs

Hi there,
some design advice and a concept.
Separate the + from the settings menu, I think there is no good reason to put settings and profiles/new tabs in one place.
Take advantage of the whole title bar height for the tab.
Hover/Active should be darker than the normal title bar, not vice versa like now. (For dark mode invert colors).
Remove window border or make it optional in the settings, it does not look great at all.
In the third image the font color is red to indicate that the terminal is running in “Administrative Mode”.
Add some padding by default, looks strange at the moment without padding.

i'm working on a settings ui at the moment, i will post images as i have time to finish it.

1564 is the issue for implementing settings UI.

It should probably be linked to from this issue.

Re. 3rd party logos etc., @zadjii-msft is correct - Microsoft cannot ship logos for 3rd party products. However, we ___might___ be able to find a way for distro vendors to provide their logo somewhere Terminal can easily locate and incorporate it. Will noodle on this a little.

@jwlodek & @Fisico - Appreciate your feedback, but PLEASE do not discuss specific feature asks here - let's stick to one-subject-per-issue otherwise we'll never keep track of things. Thanks.

Folks, I wish to ask for you to please provide a mode without any tabs and minimal or no window decorations? All I want is a single and clean terminal screen. I already miss a fullscreen toggle too.

@oblitum you should check your configuration file. If you toggle alwaysShowTabs and showTabsInTitlebar, you’ll have something closer to what you want.

@DHowett I tried it before but it didn't help, I got the tabs removed, but window decoration got white, which is worse than leaving the tabs, at least I get all decoration as dark with it.

Is it possible to have the terminal fullscreen in some way? Toggle or configuration. I see there's FullScreen in codebase, but I didn't find a setting.

Re. 3rd party logos etc., @zadjii-msft is correct - Microsoft cannot ship logos for 3rd party products. However, we _might_ be able to find a way for distro vendors to provide their logo somewhere Terminal can easily locate and incorporate it. Will noodle on this a little.

@bitcrazed
What if the list of available "profiles" existed in a user folder, which other distros in the Windows Store could be added to on install. Then this is separate from the settings/profile JSON file. And the Settings UI could display these available profiles and allow a user to add them.

Part of adding their distribution to the list of available ones, would include an icon entry, or even adding colour-schemes like Ubuntu's colorscheme.

@DHowett-MSFT Looking at the MinMaxClose control, is there a reason why those button sizes were chosen?

The three buttons are 36 x 45.

Looking at Win32 (Notepad and Wordpad), it's window controls are 29 x 45.

Looking at UWP (Calculator and Your Phone), it's window controls are 32 x 46.

@mdtauk : There doesn't seem to have a standard / consensus on the size of these buttons on other Windows apps as well (as you can see) 🤣

@mdtauk Depending on what UI framework an app is built, you may see system buttons of slightly different sizes and shapes. For example:

• Win32 apps like Notepad rely on the OS (GDI/DComp) to draw system controls and so get a standard sized title bar
• Chrome / Edgeium draws its own non-client area in order to get its tabs up into the title bar, and draws its own system buttons ... aligned to the top edge of its Window for ... 'reasons'
• Terminal also draws its own non-client area to get its tabs up into the title bar region, and in order to make the tabs fit, we have a taller title/tab bar.

In Terminal, we chose to scale & center the system buttons in the available title bar space, which results in them being a little bigger, but still square and in proportion:

Interestingly, despite Terminal's system controls each being a little larger, they're proportionally grouped a little closer together which keeps the system control cluster about the same width as the Win32 system-drawn control cluster:

Compared to UWP apps like Mail, again, Terminal needs a slightly taller title bar area , but our system buttons are slightly larger, but squarer, and the symbols themselves are only 2 pixels larger when rendered on my 4K screen @ 200% scaling.

All this said, we may tweak things just a little in the future, but we think that our design and layout is clean, accessible, and proportionally sound.

Let us know if you disagree by filing an issue so it can be tracked and discussed.

@mdtauk Re. settings, note that we're working on a bunch of cool improvements in this space. Stay tuned for the next couple of releases ;)

@bitcrazed Thank you 💙 That response was very interesting. I am just glad it wasn't a "that's good enough" decision :P Window controls are one of the least consistent element in Windows, so I was curious.

And by comparison, Edgium keeps the window controls as normal, but top aligned, rather than centred.

Once the border is drawn properly, it wont look as different.

Can anyone please answer whether I can have fullscreen in any way? I just want the whole screen without any of those windows controls at all.

Can anyone please answer whether I can have fullscreen in any way? I just want the whole screen without any of those windows controls at all.

@oblitum I know I mentioned Tablet Mode as needing to support a true Full Screen option, where window controls only appear when you mouse over the top or swipe from the top. If that is implemented, there could be an option to Full screen on maximize - perhaps even with a change of glyph for the Maximize button

Why don't you use WinUi to draw the titlebar and the tabs? It would make things more consistent.

https://github.com/microsoft/microsoft-ui-xaml

@mdtauk ok. I'm just asking for whatever trick, registry setting or something, no need for a Tablet Mode implemented to get it working. I'm asking because I see there's FullScreen in the codebase, and some reference to registry, but no idea whether it can work today.

Why don't you use WinUi to draw the titlebar and the tabs? It would make things more consistent.

https://github.com/microsoft/microsoft-ui-xaml

Due to the necessity of the project, they have to override the default Win32 window drawing, but the TabBar, and the Window controls are implemented as Xaml controls.

WinUI controls

@lazylazyllama The Terminal's tab control is built for us by the WinUI team: https://github.com/Microsoft/microsoft-ui-xaml/issues/304

We prototyped early Terminal implementations using @michael-hawker's tab control Windows Community Toolkit, and then worked with @stmoy & team to create the WinUI tab control that we use today.

Re. drawing in the non-client area:

This isn't as simple as one might imagine, especially when your app's UX is composed of XAML controls hosted in XAML Islands atop a Win32 host-app. We've worked closely with the WinUI, XAMLIslands and other partner teams to make Terminal's tabs work.

@oblitum Please don't ask for features in this thread - please open a new issue if one describing your ask doesn't already exist. If an existing issue does describe much of what you're looking for, then please add your thoughts to that existing ask. For example, #2001 or #288

@mdtauk NP :) Alas, with the changing sands of Windows UI design, and the flexibility demanded by apps that want more control over every aspect of how they're drawn, we often see quite a lot of 'drift' between different apps' user-experiences. This is good and bad: Good in that we can move things forward (thank goodness we're not all still using GDI-based apps 😉 ) but bad in that one often has to switch UX contexts/expectations when switching between apps.

Hopefully, as we move forward, and as the modern Windows UX stack matures, and design languages consolidate, we'll see enough consistency that we won't have to reset expectations between apps.

@mdtauk NP :) Alas, with the changing sands of Windows UI design, and the flexibility demanded by apps that want more control over every aspect of how they're drawn, we often see quite a lot of 'drift' between different apps' user-experiences. This is good and bad: Good in that we can move things forward (thank goodness we're not all still using GDI-based apps 😉 ) but bad in that one often has to switch UX contexts/expectations when switching between apps.

Hopefully, as we move forward, and as the modern Windows UX stack matures, and design languages consolidate, we'll see enough consistency that we won't have to reset expectations between apps.

I am sure when WinUI with Win32 lifecycle is here, you will be very excited to cut out all that DWM and HWND drawing code. Let's hope those apps also have the ability to recolour the window controls in XAML, that UWP can do.

Hopefully, as we move forward, and as the modern Windows UX stack matures, and design languages consolidate, we'll see enough consistency that we won't have to reset expectations between apps.

That consistency is needed big time.

I would suggest to make the Tab Interface two Layered stacked vertically, basically two rows. how it is implemented as of now is, the whole tab interface is on the header itself, i would suggest if header area(First Row) displays the path of the active tab and in 2nd row tabs are there displaying just the binary name would work better.

I don't know what the support is like across different shells, but could directory vs file highlighting eventually be possible?

directory vs file highlighting

For PowerShell, you'll want a module like DirColors (*shameless plug), which will add coreutils-style coloring to powershell file listings.

https://docs.microsoft.com/en-us/uwp/toolkits/winui/release-notes/winui-2.2

Why does the tabview design look so different than what's in terminal right now? the winui tab design is much closer to what's in edge chromium.

Because the TabView currently used in Windows Terminal is a custom implementation and it hasn’t yet been migrated to WinUI.

that's pretty misleading from the WinUI people then.

that's pretty misleading from the WinUI people then.

Not really, the one used in Windows Terminal is behind compared to the WinUI release. But Terminal was the first to use it, before it entered pre-release stage - so they were the testing ground for the control, and provided feedback.

There is also another issue. The WinUI TabView control is built for UWP and XAML, but right now, Windows Terminal is a mix of Native Win32 app and XAML Islands for using modern controls. There are certain limitations at present, with how the two technologies work together.

The hope is WinUI 3.0 and a 2020 release of something called WinUI Desktop - will blend these together, making it much more fluid and simple to build the app with.

Woah no that's a misunderstanding.

What we're using in the Terminal currently was a pre-release version of the TabView. We helped guide some of the implementation details. What was released in WinUI 2.2 was the polished version of the TabView.

We on the Terminal just haven't had the chance to pull the latest WinUI bits and update ourselves quite yet. Fundamentally they're the same control, we're just a few versions behind now :P

The UWP XAML + Win32 mixed stack we're using for our UI has _no impact_ on our ability to ingest the Tab View.

The UWP XAML + Win32 mixed stack we're using for our UI has _no impact_ on our ability to ingest the Tab View.

It does explain why the Integration into the TitleBar won't completely match the image shown on the WinUI listing for the TabView however

Wanted to create a standalone issue first, but I guess this better fits in here anyway:

Allow single tabs to be "locked"

As a random idea, there could be an additional padlock icon next to the close button, when hovering a (not locked) tab. If a tab is locked, the lock would always be visible and prevent accidentally closing the associated tab/process (either by hand or by shutting down the system). Think pinned/stored tabs in Chrome or Edge.

Scenario

This is basically based on actual things that happened, with several console windows rather than the new Terminal app, though.

• Mario runs several tabs of any shell grouped together, one for misc console commands, a second tab hosts a website in development, another one with SSH to the remote server, etc.
• Since there have been a few issues, he decides to open yet another shell to run some slow clean-up/service process (like git gc, sfc /scannow, ftp pushing files, or whatever).
• While its running, he returns to the other tabs with his regular work.
• At the end of the day, he closes the whole terminal/tab group out of convenience (and due to being used to this), forgetting about how he wanted to check the output of the long running task.
• The results are lost immediately (let's ignore log files or event entries, which isn't really standardized and it could be a temporary remote session like SSH).

What should be different

• After Mario opens the new tab/shell for the slow process, he uses a small padlock icon in the tab (that's only visible while hovering) to "lock" it.
• Once clicked, the close button for the tab is removed and instead replaced by said padlock icon.
• Later, when trying to close the Terminal app as a whole, regular tabs are removed, but the locked one stays open,
• In this state, the Terminal would also prevent a (non-forced) system shutdown.
• If the process associated with the locked tab dies, the tab is unlocked/removed automatically (i.e. current behavior).
• If the padlock is double-clicked, the tab is unlocked and restored to default behavior.

I also made an umbrella issue of hiccups I stumbled on: https://github.com/microsoft/terminal/issues/2209

Unfortunately, I don't have bandwidth these days to read/search all issues that are potentially duplicate or were already fixed. If someone on this thread by chance has energy to point non-duplicate/admissible ones, I can create separate issues.

I didn't think this warranted a new issue since it's fairly subjective... but I'd love to understand the rationale behind using acrylic when the window is focused, rather than the other way around.

It seems so counter to what you'd want; it makes the window you're working in less readable, and disables any sort of transparency at the time you'd want it i.e. when an inactive window is obscuring another window.

love to understand the rationale

We would too! This is a systemwide policy applied to the acrylic brush. Presumably, it was done so that a heap of applications wouldn't stack tens of transparent windows on top of eachother and kill system performance. It was supposed to be an affordance for active windows only.

Haha everyone's on the same page then -and thanks for the response. Hopefully the appropriate people will hear the rumblings at some point and make it happen (and fingers crossed standard transparency will become an option in Microsoft Terminal)!

@drk-mtr there is an uwp app called "Notepads" and somehow it manages to keep its acrylic transparency even if its not focused anymore.

https://github.com/JasonStein/Notepads

The prompt when using zsh/Oh My Zsh looks wrong in Windows Terminal, especially the arrows' colors and some tiny lines between characters. I'm using Powerlevel9k.

Windows Terminal (using the Solarized Dark color scheme)

Classic WSL (using default colors)

subsequently removed

Just for the record, and to head off any assumptions of malfeasance: neither I nor my team removed this comment. @mcgov moved his comment to a more appropriate issue, #1753.

Ah that's good to hear @DHowett-MSFT. I've removed that comment to avoid any unnecessary drama.

I'm having trouble with keywords for this, so apologies if there's an issue already. I'm also not 100% sure this is a terminal issue.

Often, but not always, after typing 3 characters, the text shifts one column to the left:

Here's what I've observed:

• It only seems to happen inside of a git repo (posh-git issue?)
• It happens with ligature-enabled fonts like Cascadia Code or Fira Code, but not Consolas
• It doesn't happen in the VS Code integrated terminal when using Cascadia Code; it seems like the integrated terminal doesn't support ligatures
• It happens with PowerShell Core and Windows PowerShell, but I was not able to produce it in Git Bash or an SSH session
• It doesn't matter if it's a git command or something else, like clear

The above makes me think it's a ligature-rendering thing, but I'm not certain.

I am using:

• Windows 10 build 18362.175
• Windows Terminal 0.5.2681.0 (Store version), but this also occurred previously
• posh-git 1.0.0-beta3

@rdnlsmith

That is caused by the ≡ character.

See also:

• #2066 (and #42)
• Microsoft/Cascadia-Code#117

@ExE-Boss Interesting, thanks!

@drk-mtr, @DHowett-MSFT, @lazylazyllama,

Thank you for your feedback on Acrylic. I am a Program Manager working with Fluent design team. You might have seen me talk about Fluent at //Build in the last couple of years including sharing the decisions on guidance change for where Acrylic was to be utilized.

Long story short, the guidance for Acrylic today outlines that it is to be used for transient UI surfaces as well as surfaces that are transitory in nature. Acrylic uses transparency and blur which is expensive in computing power usage. So it was decided from the technical POV that this UI is only to be used when the application is being focused where this effect be most effective. This is why Acrylic turns off when the focus goes to another app as well as when the device is operating in less than optimal conditions. This material was never intended to be used on the surface where it is ON at all times.

Acrylic was also meant to be more “attention grabbing” rather than used on surface that doesn’t have user’s attention. We use acrylic combined with shadow to add the elevated feeling on controls like MenuFlyout/ContextMenu for performing short tasks. Because of this, applications such as Calculator also uses this effect for short, calculating actions.

As to legibility, we spend quite a bit of time ensuring the text on top of Acrylic are legible by tweaking the values very carefully. That said, it being transparent, it will never be as good as pure black or pure white. We therefore do not recommend it being used on a main surface to be used for a long period of time.

Fluent design system also prides in providing familiarity to our users, even if they are not from Windows. Because of this, we discussed it with folks on Terminal who are driving design of it and made a collective decision for Terminal app to keep the acrylic surface as a default on the pane that most Linux customers will feel at home with. As I understand, Linux customers are used to a blurred background, however the main page does not turn it on by default because of the above mentioned reasons (still possible to turn it on as user choice).

I hope this explained a little bit about the background and reasoning behind the current design. That said we welcome your feedback on Acrylic. If you want to provide feedback on this or any WinUI topic, please submit a new issue on the main WinUI repo.

@chigy, @drk-mtr, @DHowett-MSFT, @lazylazyllama,

Acrylic uses transparency and blur which is expensive in computing power usage.

Are there any data about how slow multi-layer blur can be?
Can we only enable them on newer computer models?
Developers' computers are considered fast.

Developers' computers are considered fast.

Gaming computers, yeah, but developers' computers can be slower -- you just write code!

Just out of curiosity, how can the "Notepads" mentioned by @lazylazyllama keep its acrylic transparency given the systemwide policy? It's in the store so it shouldn't be using any "magic" API.

Fluent design system also prides in providing familiarity to our users, even if they are not from Windows. Because of this, we discussed it with folks on Terminal who are driving design of it and made a collective decision for Terminal app to keep the acrylic surface as a default on the pane that most Linux customers will feel at home with. As I understand, Linux customers are used to a blurred background, however the main page does not turn it on by default because of the above mentioned reasons (still possible to turn it on as user choice).

So that whole Terminal promo video is a lie then?

https://www.youtube.com/watch?v=8gw0rXPMMPE

People are expecting it to look like this out of the gate.

Just out of curiosity, how can the "Notepads" mentioned by @lazylazyllama keep its acrylic transparency given the systemwide policy? It's in the store so it shouldn't be using any "magic" API.

@ZhaoMJ, Notepads is likely using low-level Composition APIs, rather than AcrylicBrush to achieve the effect.

@drk-mtr, @DHowett-MSFT, @lazylazyllama,
Thank you for your feedback on Acrylic. I am a Program Manager working with Fluent design team. You might have seen me talk about Fluent at //Build in the last couple of years including sharing the decisions on guidance change for where Acrylic was to be utilized.
Long story short, the guidance for Acrylic today outlines that it is to be used for transient UI surfaces as well as surfaces that are transitory in nature. Acrylic uses transparency and blur which is expensive in computing power usage. So it was decided from the technical POV that this UI is only to be used when the application is being focused where this effect be most effective. This is why Acrylic turns off when the focus goes to another app as well as when the device is operating in less than optimal conditions. This material was never intended to be used on the surface where it is ON at all times.
Acrylic was also meant to be more “attention grabbing” rather than used on surface that doesn’t have user’s attention. We use acrylic combined with shadow to add the elevated feeling on controls like MenuFlyout/ContextMenu for performing short tasks. Because of this, applications such as Calculator also uses this effect for short, calculating actions.
As to legibility, we spend quite a bit of time ensuring the text on top of Acrylic are legible by tweaking the values very carefully. That said, it being transparent, it will never be as good as pure black or pure white. We therefore do not recommend it being used on a main surface to be used for a long period of time.
Fluent design system also prides in providing familiarity to our users, even if they are not from Windows. Because of this, we discussed it with folks on Terminal who are driving design of it and made a collective decision for Terminal app to keep the acrylic surface as a default on the pane that most Linux customers will feel at home with. As I understand, Linux customers are used to a blurred background, however the main page does not turn it on by default because of the above mentioned reasons (still possible to turn it on as user choice).
I hope this explained a little bit about the background and reasoning behind the current design. That said we welcome your feedback on Acrylic. If you want to provide feedback on this or any WinUI topic, please submit a new issue on the main WinUI repo.

@chigy @DHowett-MSFT Instead of "turning off" acrylic why not pause it. i.e. the last frame rendered before the window becomes inactive, is displayed while the window is inactive. Active windows are almost always above inactive ones and thus the acrylic effect would appear to be active even while the window is no longer active. The only issue I can see with this is a situation where a window is "always on top" which is quite tolerable.

@drk-mtr, @DHowett-MSFT, @lazylazyllama,

As to legibility, we spend quite a bit of time ensuring the text on top of Acrylic are legible by tweaking the values very carefully. That said, it being transparent, it will never be as good as pure black or pure white. We therefore do not recommend it being used on a main surface to be used for a long period of time.

@chigy

This could be resolved by outlining or applying a drop shadow / outer glow on the text. @miniksa demo'd a hacky version of this when the Terminal was unveiled at Build, so it doesn't seem far reaching to consider it might become an optional Terminal feature someday, especially in a world where the community could contribute it.

@chigy @DHowett-MSFT Instead of "turning off" acrylic why not pause it. i.e. the last frame rendered before the window becomes inactive, is displayed while the window is inactive. Active windows are almost always above inactive ones and thus the acrylic effect would appear to be active even while the window is no longer active. The only issue I can see with this is a situation where a window is "always on top" which is quite tolerable.

@3dWrecker that's not how AcrylicBrush works. The concept of pausing doesn't apply to AcrylicBrush, much like you can't pause a sheet of acrylic in the physical world.

Huge thanks for the comprehensive replies!

I'll be honest, I posted this on an existing thread since I didn't see it as a core concern (until other elements such as mouse support in WSL etc. are complete). I didn't account for the fact that a few people may be subscribed to the thread and that it might get a decent respose! Feel I should clarify my perspective - I've written these as "User Stories" that completely ignore any technical constraints, so I fully appreciate these may not be achievable.

And I realise some of the below are mutually contradictory if applied at the same time, I'm being a typical difficult user ;)

I would like to be able to see the text in a window behind the focused window

It sounds like acrylic is not really the correct vehicle for this. A normal transparency effect would therefore be perfect for this, and it sounds like it's easier to implement.

The ideal is that the background could have configurable transparency, but that rendered text could be opaque - no idea how achievable this is.

I love the acrylic effect, and I would like to be able to use it in a focused window

I cannot use acrylic when the window is focused, because even on the most minimal setting that the Terminal allows, text is not readable enough.

I would therefore like to be able to reduce the intensity of the acrylic effect that is applied while the window is focused. Just as an example, if we could use the acrylic effect with a transparent dark grey layer applied over the top of it, so that the effect is made more subtle, this might work well.

Alternatively, being able to make the blur more intense and/or reduce it to near zero would massively increase the flexibility in real-world use.

I want to use acrylic when the window is not focused

Appreciate this might not be achievable, just including here for completeness.

The ideal here is that different blur settings can be applied when compared to the focused window, and an optional alpha layer over the top to make it less intense.

Sorry to mention the fruit based OS here but for context, they use alpha layers on both focused and non-focused windows, and have different alpha layers even on the individual icons within those windows. So it's not easy, but it's certainly achievable.

@chigy @DHowett-MSFT Instead of "turning off" acrylic why not pause it. i.e. the last frame rendered before the window becomes inactive, is displayed while the window is inactive. Active windows are almost always above inactive ones and thus the acrylic effect would appear to be active even while the window is no longer active. The only issue I can see with this is a situation where a window is "always on top" which is quite tolerable.

@3dWrecker that's not how AcrylicBrush works. The concept of pausing doesn't apply to AcrylicBrush, much like you can't pause a sheet of acrylic in the physical world.

I think that's exactly the point - 3dWrecker is suggesting an alternative approach... to go with the analogy, you can "pause" an acrylic sheet in the physical world by taking a photo. And renedering that photo is less intensive than rendering a video of the acrylic, even if the sheet of acrylic remains static in both.

Of course I know nothing about the implementation detail, so if what you're suggesting is that it can't be implemented using the current model then fair enough :)

Of course I know nothing about the implementation detail, so if what you're suggesting is that it can't be implemented using the current model then fair enough :)

That ^ is exactly what I'm suggesting, @drk-mtr 😊. Changing AcrylicBrush implementation is a fine goal that won't be achieved in terminal. As @chigy suggested earlier, the main WinUI repo is the right place to discuss acrylic.

Of course I know nothing about the implementation detail, so if what you're suggesting is that it can't be implemented using the current model then fair enough :)

That ^ is exactly what I'm suggesting, @drk-mtr blush. Changing AcrylicBrush implementation is a fine goal that won't be achieved in terminal. As @chigy suggested earlier, the main WinUI repo is the right place to discuss acrylic.

I think an issue with the "pausing the acrylic" idea would be that in case of multiple windows stacked, if one (or more) of the windows stacked under the one with the paused acrylic effect is moved, it would still look like it's under the paused acrylic window, thus creating an... Odd inconsistency.

Unless I misunderstood what your idea was

@chigy

This could be resolved by outlining or applying a drop shadow / outer glow on the text. @miniksa demo'd a hacky version of this when the Terminal was unveiled at Build, so it doesn't seem far reaching to consider it might become an optional Terminal feature someday, especially in a world where the community could contribute it.

@beforan , thank you for suggestion, Please feel free to suggest it at our main WinUI repo.

That said, we recently looked at use of shadow and they don't quite work very well with smaller text where these types of UI typically uses.

I would like to be able to see the text in a window behind the focused window

It sounds like acrylic is not really the correct vehicle for this. A normal transparency effect would therefore be perfect for this, and it sounds like it's easier to implement.

@drk-mtr , we do not want many applications to be creating different version of the similar concept to give users inconsistent experiences. Thus we settled in using Acrylic here. Acrylic also helps with the legibility than a regular transparency.

The ideal is that the background could have configurable transparency, but that rendered text could be opaque - no idea how achievable this is.

Again, you will likely run into legibility issues here that you will need to make sure...

I love the acrylic effect, and I would like to be able to use it in a focused window

I cannot use acrylic when the window is focused, because even on the most minimal setting that the Terminal allows, text is not readable enough.

I would therefore like to be able to reduce the intensity of the acrylic effect that is applied while the window is focused. Just as an example, if we could use the acrylic effect with a transparent dark grey layer applied over the top of it, so that the effect is made more subtle, this might work well.

Alternatively, being able to make the blur more intense and/or reduce it to near zero would massively increase the flexibility in real-world use.

I thought you already had a capability? This is what I got from my contact "To make Acrylic more usable for users with different preferences, one can press and old CTRL + SHIFT and scroll-wheel with mouse or “zoom” with a trackpad to dynamically adjust the transparency level from 0% to ~50%." This is terminal specific feature but if this is interesting and has support of the community, we could consider systematizing it.

I want to use acrylic when the window is not focused

Appreciate this might not be achievable, just including here for completeness.

The ideal here is that different blur settings can be applied when compared to the focused window, and an optional alpha layer over the top to make it less intense.

Sorry to mention the fruit based OS here but for context, they use alpha layers on both focused and non-focused windows, and have different alpha layers even on the individual icons within those windows. So it's not easy, but it's certainly achievable.

I'd like to understand the user scenarios here. I encourage those who want this to suggest it at our main WinUI repo.

I didn't know about being able to ctrl+shift+scroll - thanks!

I fully agree with aiming for consistency of aesthetic, but I'd never prioritise this above the functional experience. I don't really have an opinion on opacity/acrylic in WinUI generally - I hope this doesn't sound rude but I'm a bit "take it or leave it". I'm really just thinking about the usability implications within the bounded context of the Terminal here.

Hopefully these observations with a focused console clarify:

• 0.999 opacity: I can clearly read console text. However, I cannot get any sense of windows layered under this one. The effect has no "wow" factor.
• 0.9 opacity: This provides a generally usable balance. I can read console text fairly clearly, although the background is brightened up a little too much. It's serving very little functional purpose, because windows behind this one are barely discernible.
• 0.5 opacity: The transparency is starting to become useful, I can get a feel for the windows behind this one... but foreground text is definitely starting to lose readability.
• 0.1 opacity: It looks brilliant, really nice effect. It's becoming a real struggle to read against certain background windows though... and there's little functional benefit since background text is still unreadable. So you think "wouldn't this be great on a non-focused window!", realise it can't be done, and ramp the opacity right back up. And from a purely aesthetic perspective, by this point the transition from acrylic to "nothing" when I move focus away from this window is horribly janky, since it "adds focus" to the non-focused window, and the sudden transition is very pronounced because the acrylic effect was on more strongly.

There's no good balance point for me. I'm worried someone's going to tell my about a fully configurable blur setting or something soon and I'll feel very silly...

As I say, this is probably a job for regular transparency - or maybe I'll have to switch it off and put up with a plainer console experience :)

I think the user should just use whatever they feel comfortable using. I don't think the terminal has to "force" a kind of background on the user. Hypothetically, there could be 3 "modes"

• Fully opaque background (i.e. "useAcrylic": false)
• Acrylic background (i.e. "useAcrylic": true). Should remain the default for the "wow" factor and just because it looks good.
• (Semi)Transparent background. This one does not exist right now, and would probably answer all of the complaints.

I don't think acrylic disappearing when the window goes out of focus is a huge deal: to be honest, I don't think the point of acrylic is to allow you to see what is under the windows anyway, it's in my opinion visual candy. So the people who dislike this acrylic effect disappearing would probably be happy with the semitransparent background, which would allow them to see everything they need.

However, for this to work, the window would need to keep its transparency at all times, even when it is not in focus.

Options wise, if a triple state system is adopted, something like backgroundMode could be added with either filled, transparent or acrylic as options instead of the simple boolean useAcrylic.

Just my two cents. I just hope that a transparent version is technically feasible, as I think it would be a major selling point for power users who are perfectly happy with their current transparent solution and would see the Terminal as a downgrade.

Huh, it looks like Powerline fonts' arrows are broken

EDIT: This is tracked by #633 and I am blind, although for some reason this worked just fine until now

When running console apps with mouse functions (for example FPC's menu bars, but in text mode), the mouse's clicks will select the character under it and won't get to the underlying app.

@leduyquang753 That is the final item in "Things we know:" at the top of this page - References #376, #545

https://twitter.com/LyalinDotCom/status/1186688002870792192 Visual Studio XAML PM

WinUI 3.0 is planning a Desktop app model as an option so that developers can use the power of UWP in full desktop mode similar to WPF. WinUI is is really exciting for this and a few other reasons :)

I assume this solves the issue of pulling in WinUI tabs on win32?

https://twitter.com/LyalinDotCom/status/1186688002870792192 Visual Studio XAML PM

WinUI 3.0 is planning a Desktop app model as an option so that developers can use the power of UWP in full desktop mode similar to WPF. WinUI is is really exciting for this and a few other reasons :)

I assume this solves the issue of pulling in WinUI tabs on win32?

I dare say the Windows Terminal project will be a testing ground for a lot of this WinUI Desktop approach

@chigy

@drk-mtr , we do not want many applications to be creating different version of the similar concept to give users inconsistent experiences. Thus we settled in using Acrylic here. Acrylic also helps with the legibility than a regular transparency.

At the end of the day, the acrylic looks pretty, but it is not _useful_ in any way.
Transparency - a feature supported by every other terminal I've ever used - is useful.

I understand it's not currently implemented, but it's honestly a bit silly to say that it's not a feature that should be supported for consistency, especially when the promotional video displayed a fully transparent glass-like window.

I wonder why marketing would make that choice? My guess is because they know __everyone wants a transparent terminal__.

I see a lot of "I don't want this because of my reasons" in this project (transparency and split panes comes to mind). So, don't enable it in your setup? Why would it be hard to have acrylic and transparency available and leave the choice to the user?

A good example of this is iterm2. It has transparency with a sliders for degree of blur and opaqueness. User choice. Modern terminals should have these features.

@jwhipp the exact reason why (and issue for tracking this) is right here I think https://github.com/microsoft/terminal/issues/1753#issuecomment-508070516

@jwhipp the exact reason why (and issue for tracking this) is right here I think #1753 (comment)

I didn't look at that comment as ruling out with finality. In fact, that issue is still open. Following the linked issue, it was closed as the user was requesting ultimately elliptical windows.

It seems that it was a fairly final decision since that issue is listed as "Things that people want, but we won't be able to fix" on the first message of this megathread. I'd assume that it's open because it's still a problem.

@rogersachan @mdtauk

I dare say the Windows Terminal project will be a testing ground for a lot of this WinUI Desktop approach

The Windows Terminal is a great example of an app that uses Xaml Islands to host a WinUI component (TabView). To that end, it already looks a bit like a WinUI Desktop app 😊 We hope to have more information to share about WinUI Desktop soon! In the meantime, please direct comments about WinUI Desktop to the main WinUI repo: https://github.com/Microsoft/microsoft-ui-xaml

@chigy

@drk-mtr , we do not want many applications to be creating different version of the similar concept to give users inconsistent experiences. Thus we settled in using Acrylic here. Acrylic also helps with the legibility than a regular transparency.

At the end of the day, the acrylic looks pretty, but it is not _useful_ in any way.
Transparency - a feature supported by every other terminal I've ever used - is useful.

I understand it's not currently implemented, but it's honestly a bit silly to say that it's not a feature that should be supported for consistency, especially when the promotional video displayed a fully transparent glass-like window.

I wonder why marketing would make that choice? My guess is because they know everyone wants a transparent terminal.

@iCodeSometime , Thank you for your feedback. The Terminal “Sizzle Video” was designed by the Terminal engineering team to share their vision of what they wanted the Terminal to be … once it was built … which it wasn’t at that time! The transparent background did, in fact, have a blur effect applied, though it was a little less-blurry & more-transparent than Acrylic currently supports.

The Terminal team added pure transparency support to Console some time ago, but have received copious feedback from users that pure transparency can result in the text of the foreground Console “collides” with the text of a Console/Terminal/Editor underneath:

Many users have asked for an adjustable blur texture to avoid this kind of collision, whilst still being able to get a sense of motion / content of windows under the currently open Terminal:

Terminal team also included a way for user to adjust to a point, @jwhipp commented. Did you know that one can press and hold CTRL + SHIFT and scroll-wheel with mouse or “zoom” with a trackpad to dynamically adjust the transparency level from 0% to ~50%?

All this said, Terminal is aware of all the feedback that users would like greater and independent control over the amount of blur and transparency than is currently provided via Acrylic. We (WinUI) are working together with Terminal, and soon with others including community members like yourself, on new semi-transparent background textures. Please come join the WinUI GitHub for future conversation about additional materials for Windows.

Please don't confuse us not immediately implementing every requested feature with a lack of desire to do so: We'd LOVE to implement many of the requested features, but we have to prioritize work according to our limited resources, schedules, and other demands.

Just because we can't implement something NOW does NOT mean we won't be able to get to it in the future, or that someone in the community can't implement it!

Case-in-point: We're going to be working with the WinUI team on improving the background blur feature used by Terminal. Follow along on this issue, and please share your perspectives, etc.: https://github.com/microsoft/microsoft-ui-xaml/issues/1493

@jwhipp Re:

Why would it be hard to have acrylic and transparency available and leave the choice to the user?

You can enable Acrylic via the useAcrylic setting, and adjust its level of blur via the acrylicOpacity setting if you wish.

@chigy, In my opinion, a much simpler workaround that doesn't negate the benefits of having transparency, would be choosing a more reasonable amount of transparency than was used in your screenshot.

For example, this is what the same screenshot looks like with opacity set to 80%

Everything in the terminal is legible, even though it is directly on top of the text from the other terminal. Everything behind the terminal is also legible (in contrast with your acrylic screenshot)

I understand this is pre-release software, and I've been impressed, you guys have done a great job quickly correcting other reported issues (e.g. #2771). I'm in no way expecting transparency to be added tomorrow, but hopefully this screenshot helps demonstrate why normal transparency is a requirement for me before I could use this as my default terminal, and why acrylic is not a good substitute - though I agree, it looks pretty cool.

You can enable Acrylic via the useAcrylic setting, and adjust its level of blur via the acrylicOpacity setting if you wish.

Yeah I misspoke, I couldn't really tell you how difficult it will be to implement full transparency, so my apologies for that comment. I was more commenting for the people that say "I don't want this so don't implement" when it should/would truly be a toggle on/off setting.

The request here is about blur/no blur and having full transparency. If I set the acrylicOpacity to 0.0 for example, I still have blur, it's just minimum shaded. We'd like to have an option of no blur with various degrees of shading.

Like I said, the best reference for this is iterm2 and how it handles blur with transparency.

The new release changed the color of the title bar in a dark-mode context to become brighter.

I liked the old color (on the left) better.

@escalonn Thanks for the feedback. Our original color design wasn't very accessible, and a lot of people weren't pleased that they couldn't differentiate their tabs.

Right now, we're locking to the overarching WinUI dark and light themes for broader system consistency.

@jwhipp No problemo - just wanted to make sure you were aware of some of the knobs and dials we're exposing. Which kinda amplifies your point: Where there's no clear right or wrong, and where end-user choice really matters, we often err towards exposing settings/options. However, we're aware that this doesn't scale, and will take a more opinionated stance from time to time, like, for example the color changes in the tab strip - deferring instead to the (awesome) WinUI team's work to build an accessible, consistent, handsome user experience through their suite of controls.

@iCodeSometime - one of the difficulties with building user experiences is that there are many needs and opinions.

Decreasing a windows' amount of transparency certainly makes things more legible, but not enough for many.

Some people prefer an amount of blur/frosting to obscure the specific contents of the windows underneath, while still being able to see, for example, when a build finishes or an app closes, etc. without having to continually flick back and forth. Especially when the uppermost/focussed window is maximized.

We also don't want to re-create GDI's brute-force transparency model we had to adopt in Console wherein the entire window is made transparent - borders, title bar, background and .., importantly ... text contents.

And we must make sure that the Terminal is accessible, flexible, configurable, and productive. Bear with us while we drive towards completing & stabilizing Terminal's v1.0 features, and then getting to work on v2.0.

I don't know why... But Notepads in Windows store have acrylic effect even it's unfocused.
It's source code is at https://github.com/JasonStein/Notepads.

Would it be possible to use this: https://docs.microsoft.com/en-us/uwp/api/windows.ui.composition.compositionbackdropbrush to make an acrylic title bar? I don't really know how this or XAML works but maybe it's possible to use it to create a SpriteVisual (?) with a CompositionBackdropBrush which covers the drag bar and then the rest of the title bar can have its background set to acrylic in the XAML?

I put the standard windows borders on the terminal.

Light mode, color in title bar disabled:

Light mode, color in title bar enabled:

Dark mode, color in title bar disabled:

Dark mode, color in title bar enabled:

What do you think? Should I make a PR or not?

More details:

• it also fixes the issue where the grab handles are too narrow at the left, right and bottom
• I also removed the big handle at the top to resize and instead now you resize by grabbing the handle at top of the drag bar

@greg904 dude, you keep doing my work for me! I'd love to look at a PR for this! Thanks

(We've been discussing this with the DWM team -- they want us to be better citizens, _we_ want to be better citizens, it'll fix a whole heap of teh checklist items in #1625!)

PR #3394

It's not really true standards borders though, I used some hacks.

I actually noticed one thing interesting - although Terminal loses its transparency when not focused, it keeps the transparency (surprisingly) in Tablet Mode, which looks pretty nice.

Im not sure if anyone else noticed this but.

@greg904 just FYI, Notepads is using a customized version of the TabView from the Windows Community Toolkit.

Is there a possibility of having sub folders in the menu? I would like to have the ability to organize items such as WSL distros, Powershell versions, programming environments together.

@str8edgedave You're looking for "Allow dropdown menu customization in profiles.json" #1571

+1 for "Can't reorder tabs". Please don't do it like Windows where you can't ever change the order of your virtual desktops.

There should be a way to remove the gap on top of the tabs IMO.

There should be a way to remove the gap on top of the tabs IMO.

They shouldn't be in the spec in first place, imo. That space is buggy in Tablet Mode.

Is there a way to create new tab in existing terminal window instead of opening new window when wt.exe is started?

Why don't make the tab bar colors like they are in edge?

In Edge there is a dark titlebar with a bit brighter tabs. So its the opposite of what the terminal currently looks like and I think the way edge does it looks way better.

This is because your brain naturally sees brighter things as being in the foreground

From the discussion above seems the focus is to just have a dark and light theme, but why can't the title bar color simply respect the user selected accent color?

I think accent color is good for titlebar but not for tabs background.

@xa0082249956 @greg904

Hey guys, I am the author of Notepads, this is how I make background acrylic effect "always on" for both title bar and window body of Notepads App: https://github.com/JasonStein/Notepads/blob/12940adc674a9ba6fa336e3aaa8652978e8a8c8e/src/Notepads/Services/ThemeSettingsService.cs#L253

I created the Acrylic brush myself using "AcrylicBackgroundSource.HostBackdrop" with help of UICompositionAnimations library to make my life easier (ref: https://github.com/Sergio0694/UICompositionAnimations).

It is basically creating the brush from scratch using composition APIs (AcrylicBackgroundSource.HostBackdrop + Noise texture).

* Updates **

My custom version of HostBackdropAcrylicBrush:
https://github.com/JasonStein/Notepads/blob/master/src/Notepads/Brushes/HostBackdropAcrylicBrush.cs

I have multiple monitors. When I have Windows Terminal open with acrylic enabled, my computer goes to sleep, and I wake it back up, the acrylic turns to a solid color. If I drag the window around within one monitor, the background stays the same. If I drag it to another monitor, the acrylic re-appears.

@EricLauber , could you re-post your issue with acrylic to WinUI repo?
https://github.com/microsoft/microsoft-ui-xaml/issues/new/choose

@chigy Yes I can. Sorry, I didn't realize it was separate. Thanks.

@EricLauber , thank you! Terminal uses the acrylic feature provided by the system, so it is better to bring this up to a group that delivers it.

Please disregard my earlier comment. I was misunderstanding the behavior - the acrylic feature goes away when the window does not have topmost focus. It wasn't the act of dragging between monitors that brought acrylic back, it was selecting the window itself.

See #4593 :) I don't have anything further at this time. It could be an option that's defaulted off, to have an outer border to improve multi-window separation...
Under Personalization, there's a feedback option, and that leads to a forum board, I searched for 'border thickness' and found several independent threads, but this one has comments... https://aka.ms/AA7fj9x

Please add alpha blend to the cursor, the text beneath it isn't visible at all.

Hello - I would love to see the acrylic effect applied when it's _not_ the active window. When I'm typing, I want to focus. When it's off to the side, I want it to look cool :) Or better yet, explicit options for both active and background, since people would also like to have it on permanently. Thanks - awesome app.

When using the window snap functionality, there is a small border around the edges, i.e. the window does not snap fully, showing part of the desktop or whatever is behind the terminal.

@DanDavies You should see https://github.com/microsoft/terminal/issues/5250#issuecomment-610691840

From @SFM61319 in #3337

Also, the profile menu and the buttons don't look much "fluent". Please add some AcrylicBrush and RevealBrush brushes to those for a more fluent effect.

This is the official documentation on when to use acrylic and when not to: https://docs.microsoft.com/en-us/windows/uwp/design/style/acrylic#transient-surfaces. From that page:

Many of our controls will use acrylic by default. MenuFlyouts, AutoSuggestBox, ComboBox and similar controls with light-dismiss popups will all use the transient acrylic when they are invoked.

Curious then that our MenuFlyout doesn't use that, we're not doing anything to customize it...

With #5485 merged, is acrylic on tabs bar doable now?

@wazybr I briefly tried swapping out the title bar brush for an acrylic one just to try it out. It didn't work but maybe there's a less naive way of doing it (@DHowett-MSFT's screenshot in #5485 seems to imply it's possible.)

Yep -- it _works_ now but there's still one place where we get the brush out of the title bar and convert it to a SolidColorBrush. This will, of course, cause it to explode.

There's also the TabViewBackground brush in app.xaml. :smile:

We wouldn't accept a contribution that just casually adds that today because there are too many groups of people who want all sorts of different things:

• tab color = terminal color
• titlebar color = terminal color
• tab color = acrylic
• titlebar color = acrylic
• titlebar color = tab color

This is why we're working on #3327, "themes".

I understand. Acrylic on the title bar will be a nice touch to the UI and add consistency in relation to other Windows apps like _Photos_ and _Movies & TV_.

@DHowett Can you change the OP to better reflect the possibility?

Sure, I edited it. Thanks.

Hey @zadjii-msft, first of all, I apologise for being late by a month.
Now, I already read the documentation for when to use acrylic and when not to, and I also know that those controls use Acrylic by default. This is confusing me because Windows Terminal's menu is NOT using acrylic by default. And if it was supposed to use Acrylic by default - which it is not using - then, that is more inconsistent than consistent (because it is not being what it was supposed to be and what the rest of its type are being - indicating unpolished UI and inconsistency).

Curious then that our MenuFlyout doesn't use that, we're not doing anything to customize it...

I don't know if it is just a bug hidden in the code or some error, but, I think you (the Microsoft team and/or whoever codes this) maybe should try to use the Style attribute to add AcrylicBrush manually (since it is failing to use it automatically) to make the UI more consistent (because other UWP apps use Acrylic for such menus - indicating UI consistency) maybe in future updates.

Also, your comment didn't really answer the second question(?) about the usage of RevealBrush (maybe you didn't notice it).
Reveal brush adds more consistency to a UWP app's UI (IMO) and is used by many apps (including the Settings app). It is even more effective for dark mode users (again, IMO) as it highlights the dark backgrounds with white "lights" (or gradients), unlike light mode, where reveal just adds a dark border gradient and does nothing to the white backgrounds. So, if Reveal brushes are used in the newTab and MenuFlyout buttons, the UI may look a bit more polished and consistent (again, IMO).

So please consider adding AcrylicBrush (for the MenuFlyout) and RevealBrush (for the buttons).

Thank you!

Edit: Also, if anyone wants to reply to me, please mention me using @ when replying to me (as GitHub lets me know when someone replies to me when mentioning me).
Also, this is really off-topic (but please don't mark this as off-topic for this one line): Are you the same u/zadjii on Reddit (cause if you are, I saw you on r/windows and felt familiar)?

Should the min/max/close buttons be smaller (like other UWP apps) and have space below them when the window is not maximized like in chrome/edge chromium? And the tiny area below them would be draggable.
Like this:

Should the min/max/close buttons be smaller (like other UWP apps) and have space below them when the window is not maximized like in chrome/edge chromium? And the tiny area below them would be draggable.
Like this:

FWIW, this is how Edgium works:

Should the min/max/close buttons be smaller (like other UWP apps) and have space below them when the window is not maximized like in chrome/edge chromium?

Edge is the only application I can see which does that and it's likely a side effect of having it's own cross platform UI toolkit instead of "native" controls.

So to answer your question, I'd say probably not.

Should the min/max/close buttons be smaller (like other UWP apps) and have space below them when the window is not maximized like in chrome/edge chromium? And the tiny area below them would be draggable.
Like this:

On Windows, the immediate left of the buttons is reserved as a draggable area. So having the same thing at the bottom is redundant.

Should the min/max/close buttons be smaller (like other UWP apps) and have space below them when the window is not maximized like in chrome/edge chromium?

Edge is the only application I can see which does that and it's likely a side effect of having it's own cross platform UI toolkit instead of "native" controls.

So to answer your question, I'd say probably not.

It's annoying in Edge too. They should be centered in Edge. I wish new Windows apps were consistent.

I still see a checkbox to making the title bar acrylic but none for actually having it respect the system coloring like every other application does.

_"Windows Terminal has it's own fixed titlebar color ignoring the system Active and Inactive titlebar colors given by the system"_

Can that feature at least be changed to "Titlebar customization options" so those of us who just want consistency can still have a way to do it?

I still see a checkbox to making the title bar acrylic but none for actually having it respect the system coloring like every other application does.

_"Windows Terminal has it's own fixed titlebar color ignoring the system Active and Inactive titlebar colors given by the system"_

Can that feature at least be changed to "Titlebar customization options" so those of us who just want consistency can still have a way to do it?

Most of the modern windows app don't follow the system color and have their own. So it is consistent.

I still see a checkbox to making the title bar acrylic but none for actually having it respect the system coloring like every other application does.

_"Windows Terminal has it's own fixed titlebar color ignoring the system Active and Inactive titlebar colors given by the system"_
Can that feature at least be changed to "Titlebar customization options" so those of us who just want consistency can still have a way to do it?

Most of the modern windows app don't follow the system color and have their own. So it is consistent.

So you are saying we should continue to have Consistent Inconsistency?

It's like saying you're gonna do something wrong just because everybody does.

So after some digging in this and other issue comments.

There's was already an issue for titlebar not respecting respecting system theming #1963 that was piled up on another issue #3327. With this "Mega Thread" issue listing being outdated/deprecated.

Given the age of both issues seems there's very low developer interests which makes implementation unlikely.

So I've personally decided to discard the tab functionality to get the visual consistency.

    "alwaysShowTabs": false,
    "showTabsInTitlebar": false,

Just leaving this info here in case it's relevant for someone else.

Hey so for the record, there's a pretty heavy amount of discussion about ways to configure the color of tabs and the tab row (title bar) over in #3327 and #5772. Options discussed in there include matching the titlebar to the system accent color, or tabs to the color of the control that's focused in the window.

Just because an issue's old doesn't mean it's abandoned. #3327 is one of my _favorite_ issues that I'm really looking forward to getting time to work on.

same thing that happens in XAML Controls Gallery: https://github.com/microsoft/Xaml-Controls-Gallery/issues/108 happens in Windows Terminal

Oh and right clicking on the caption buttons in the title bar doesn't open Sizer's menu, an app by Brianapps that works with the Office suite which appears to have a custom title bar.