Repository navigation
Window border width does not respect system theme #1859
Description
Environment
Windows build number: 10.0.18362.207
Windows Terminal version (if applicable): 0.2.1831.0
Steps to reproduce
- Install the third-party Aerolite.theme to get window borders back to being usable (i.e. not zero-width).
- Note that Command Prompt, Windows PowerShell, and Ubuntu for Windows 10 command shell windows all respect the nice new border width.
- 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.
Activity
zadjii-msft commentedon 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
c0d3h4x0r commentedon 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?
DHowett-MSFT commentedon 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:
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 commentedon 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.
c0d3h4x0r commentedon Jul 8, 2019
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?
DHowett-MSFT commentedon 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.
c0d3h4x0r commentedon Jul 20, 2019
That sounds like a wise approach to me. 👍
0xE1 commentedon 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.
ExE-Boss commentedon Aug 15, 2019
Keith F. Kelly (@c0d3h4x0r)
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).
zadjii-msft commentedon Oct 25, 2019
(We think that this is going to be closely related to a bucket of things, #3136 #1859 #3064 #1307)
Use standard 1px window borders on NC Island Window (#3394)