starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Window border width does not respect system theme #2619

New Issue
Closed
opened 2026-01-30 22:59:52 +00:00 by claunia · 11 comments
claunia commented 2026-01-30 22:59:52 +00:00
Owner
Copy Link

Originally created by @c0d3h4x0r on GitHub (Jul 8, 2019).

Originally assigned to: @DHowett-MSFT on GitHub.

Environment

Windows build number: 10.0.18362.207
Windows Terminal version (if applicable): 0.2.1831.0

Steps to reproduce

  1. Install the third-party Aerolite.theme to get window borders back to being usable (i.e. not zero-width).
  2. Note that Command Prompt, Windows PowerShell, and Ubuntu for Windows 10 command shell windows all respect the nice new border width.
  3. Launch Windows Terminal.

Expected behavior

Windows Terminal should also respect the theme's window border width.

Actual behavior

Windows Terminal has a zero-width window border in defiance of the system theme, making it nearly impossible to resize.

Originally created by @c0d3h4x0r on GitHub (Jul 8, 2019). Originally assigned to: @DHowett-MSFT on GitHub. # Environment ```none Windows build number: 10.0.18362.207 Windows Terminal version (if applicable): 0.2.1831.0 ``` # Steps to reproduce 1. Install the [third-party Aerolite.theme ](https://www.deviantart.com/win7tbar/art/Aerolite-Theme-for-Windows-10-658196061) to get window borders back to being usable (i.e. not zero-width). 2. Note that Command Prompt, Windows PowerShell, and Ubuntu for Windows 10 command shell windows all respect the nice new border width. 3. Launch Windows Terminal. # Expected behavior Windows Terminal should also respect the theme's window border width. # Actual behavior Windows Terminal has a zero-width window border in defiance of the system theme, making it nearly impossible to resize.
claunia commented 2026-01-30 22:59:54 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 8, 2019):

Is there a way to change the width of the window borders without installing a third-party theme installer?

I'm going to guess that this is a subset of #1625, assuming that the border width is in fact a system theme property we can query

@zadjii-msft commented on GitHub (Jul 8, 2019): Is there a way to change the width of the window borders without installing a third-party theme installer? I'm going to guess that this is a subset of #1625, assuming that the border width is in fact a system theme property we can query
claunia commented 2026-01-30 22:59:54 +00:00
Author
Owner
Copy Link

@c0d3h4x0r commented on GitHub (Jul 8, 2019):

That’s the wrong question to ask. The right question is, if every other app seems able to honor the third-party theme, why won’t Windows Terminal?

@c0d3h4x0r commented on GitHub (Jul 8, 2019): That’s the wrong question to ask. The right question is, if every other app seems able to honor the third-party theme, why won’t Windows Terminal?
claunia commented 2026-01-30 22:59:54 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jul 8, 2019):

Unfortunately, it is the right question to ask. There's a lot of history here for us to unravel, the earliest part of which is "why is it so hard to draw in the titlebar" and the latest part of which is "now that we're drawing in the titlebar, why was it decided by the win32 kernel driver and desktop window compositor that we absolutely must handle all of this ourselves? it's like this system was never actually designed but instead organically grown."

We're a fairly simple UI with fairly simple requirements, but one of those requirements is "have a custom color in our title bar." Unfortunately, that means:

  • We need to draw the titlebar ourselves, in its entirety, which means:
  • We need to have the UI framework (here Xaml Islands) go edge-to-edge, which means:
  • we need to draw our own window borders
  • we need to draw our own caption buttons
  • we need to account for the theme part size of the window's elements
  • we lose access to DWM shadows
    • dwm shadows are a trick, the window border is actually 8px wide and the compositor eats 7 pixels off the edge to make a shadow
    • when we try to draw our own title bar, dwm gives up and says "you don't want X? I'll take away Y, Z, A, B and C as well. Enjoy."
    • there's some weird magic hit testing that we cannot replicate for the resize handles "off the edge of the window"
  • we need to cut a hole in the Xaml island to allow titlebar and drag input to come back through (yes, this is silly)
  • we are driving dependencies on our internal partners to make this less of a heckscape.

I spent almost my entire sunday trying to answer all of the questions that arise from this list. It's not due to ignorance that we're asking the questions that we are.

@DHowett-MSFT commented on GitHub (Jul 8, 2019): Unfortunately, it _is_ the right question to ask. There's a lot of history here for us to unravel, the earliest part of which is "why is it so hard to draw in the titlebar" and the latest part of which is "now that we're drawing in the titlebar, why was it decided by the win32 kernel driver and desktop window compositor that we absolutely must handle all of this ourselves? it's like this system was never actually designed but instead organically grown." We're a fairly simple UI with fairly simple requirements, but one of those requirements is "have a custom color in our title bar." Unfortunately, that means: * We need to draw the titlebar ourselves, in its entirety, which means: * We need to have the UI framework (here Xaml Islands) go edge-to-edge, which means: * we need to draw our own window borders * we need to draw our own caption buttons * we need to account for the theme part size of the window's elements * we lose access to DWM shadows * dwm shadows are a trick, the window border is actually _8px wide_ and the compositor eats 7 pixels off the edge to make a shadow * when we try to draw our own title bar, dwm gives up and says "you don't want X? I'll take away Y, Z, A, B and C as well. Enjoy." * there's some weird magic hit testing that we cannot replicate for the resize handles "off the edge of the window" * we need to cut a hole in the Xaml island to allow titlebar and drag input to come back through (yes, this is silly) * we are driving dependencies on our internal partners to make this less of a heckscape. I spent almost my entire sunday trying to answer all of the questions that arise from this list. It's not due to ignorance that we're asking the questions that we are.
claunia commented 2026-01-30 22:59:54 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jul 8, 2019):

Incidentally, the work merged in #929 does bring back theme-sized drag handles, they just look like a black hole opened up and consumed the contents of your display. ;)

Under all of the theming slapped down by the desktop compositor is actually just the Windows Vista Aero Basic theme with all of its rounded corners and weird thick window borders.

image

@DHowett-MSFT commented on GitHub (Jul 8, 2019): Incidentally, the work merged in #929 _does_ bring back theme-sized drag handles, they just look like a black hole opened up and consumed the contents of your display. ;) Under all of the theming slapped down by the desktop compositor is actually just the Windows Vista Aero Basic theme with all of its rounded corners and weird thick window borders. ![image](https://user-images.githubusercontent.com/14316954/60835212-69d11100-a177-11e9-9a7f-25a076b8ee4e.png)
claunia commented 2026-01-30 22:59:55 +00:00
Author
Owner
Copy Link

@c0d3h4x0r commented on GitHub (Jul 8, 2019):

We're a fairly simple UI with fairly simple requirements, but one of those requirements is "have a custom color in our title bar."

And from that "requirement" stems the plethora of other problems. Instead, revisit that requirement -- why is it a requirement? Why does this app think it needs to be "more special" than other Windows applications and thus inconsistent with them (and likely less compatible with other system-wide UI changes that may come in future major Windows revisions)? Can the problem that "requirement" is trying to solve be better solved instead via some other design choice that avoids all the myriad technical issues created by the current approach?

@c0d3h4x0r commented on GitHub (Jul 8, 2019): > We're a fairly simple UI with fairly simple requirements, but one of those requirements is "have a custom color in our title bar." And from that "requirement" stems the plethora of other problems. Instead, revisit that requirement -- why is it a requirement? Why does this app think it needs to be "more special" than other Windows applications and thus inconsistent with them (and likely less compatible with other system-wide UI changes that may come in future major Windows revisions)? Can the problem that "requirement" is trying to solve be better solved instead via some other design choice that avoids all the myriad technical issues created by the current approach?
claunia commented 2026-01-30 22:59:55 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jul 20, 2019):

This might be better with recent dev builds. We're giving DWM a lot more control over the window frame than we were prior.

@DHowett-MSFT commented on GitHub (Jul 20, 2019): This might be better with recent dev builds. We're giving DWM a lot more control over the window frame than we were prior.
claunia commented 2026-01-30 22:59:55 +00:00
Author
Owner
Copy Link

@c0d3h4x0r commented on GitHub (Jul 20, 2019):

That sounds like a wise approach to me. 👍

@c0d3h4x0r commented on GitHub (Jul 20, 2019): That sounds like a wise approach to me. 👍
claunia commented 2026-01-30 22:59:56 +00:00
Author
Owner
Copy Link

@0xE1 commented on GitHub (Jul 27, 2019):

Border width issue becomes worse the higher resolution is used, at 4K (even with 200% dpi scaling) you still have 2 pixel area to place mouse over to catch the resizer.

@0xE1 commented on GitHub (Jul 27, 2019): Border width issue becomes worse the higher resolution is used, at 4K (even with 200% dpi scaling) you still have 2 pixel area to place mouse over to catch the resizer.
claunia commented 2026-01-30 22:59:56 +00:00
Author
Owner
Copy Link

@ExE-Boss commented on GitHub (Aug 15, 2019):

@c0d3h4x0r

We're a fairly simple UI with fairly simple requirements, but one of those requirements is "have a custom color in our title bar."

And from that "requirement" stems the plethora of other problems. Instead, revisit that requirement -- why is it a requirement? Why does this app think it needs to be "more special" than other Windows applications and thus inconsistent with them (and likely less compatible with other system-wide UI changes that may come in future major Windows revisions)? Can the problem that "requirement" is trying to solve be better solved instead via some other design choice that avoids all the myriad technical issues created by the current approach?

Probably because the Windows Console is a hot mess of legacy spaghetti code (it used to be a whole lot worse before 2014) and the Windows Terminal has to interface with it, so it needs to be a Win32 executable, as UWP apps are sandboxed, and therefore don’t have access to system internals (e.g. the Windows Console).

@ExE-Boss commented on GitHub (Aug 15, 2019): @c0d3h4x0r > > We're a fairly simple UI with fairly simple requirements, but one of those requirements is "have a custom color in our title bar." > > And from that "requirement" stems the plethora of other problems. Instead, revisit that requirement -- why is it a requirement? Why does this app think it needs to be "more special" than other Windows applications and thus inconsistent with them (and likely less compatible with other system-wide UI changes that may come in future major Windows revisions)? Can the problem that "requirement" is trying to solve be better solved instead via some other design choice that avoids all the myriad technical issues created by the current approach? Probably because the **Windows Console** is a hot mess of legacy spaghetti code ([it used to be a whole lot worse before 2014](https://devblogs.microsoft.com/commandline/windows-command-line-the-evolution-of-the-windows-command-line/#the-windows-console-reboot-and-overhaul)) and the **Windows Terminal** has to interface with it, so it needs to be a **Win32** executable, as **UWP** apps are sandboxed, and therefore don’t have access to system internals (e.g. the **Windows Console**).
claunia commented 2026-01-30 22:59:56 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 25, 2019):

(We think that this is going to be closely related to a bucket of things, #3136 #1859 #3064 #1307)

@zadjii-msft commented on GitHub (Oct 25, 2019): (We think that this is going to be closely related to a bucket of things, #3136 #1859 #3064 #1307)
claunia commented 2026-01-30 22:59:57 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Nov 26, 2019):

:tada:This issue was addressed in #3394, which has now been successfully released as Windows Terminal Preview v0.7.3291.0.🎉

Handy links:

@ghost commented on GitHub (Nov 26, 2019): :tada:This issue was addressed in #3394, which has now been successfully released as `Windows Terminal Preview v0.7.3291.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v0.7.3291.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-UserInterface Issue-Task Needs-Tag-Fix Product-Terminal Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#2619
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?