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

[PR #1948] Enable dragging with the entire titlebar #24732

New Issue
Open
opened 2026-01-31 09:05:02 +00:00 by claunia · 0 comments
claunia commented 2026-01-31 09:05:02 +00:00
Owner
Copy Link

Original Pull Request: https://github.com/microsoft/terminal/pull/1948

State: closed
Merged: Yes

Summary of the Pull Request

If a picture is worth 1000 words, then this is 15000 words/second like 18000 words (getting a gif below 10MB was harder than I thought)

dragging-window-004

References

This is a bunch of the work in #1625 and #1375.

PR Checklist

Detailed Description of the Pull Request / Additional comments

This is done with a major change to the NonClientIslandWindow, and the MinMaxControl. I've introduced a new XAML control, the TitlebarControl. The TitlebarControl consists of three parts - Content, Drag Area, and MinMaxControl. The MinMaxControl is now owned by the TitlebarControl, and it does pretty much nothing on it's own. All the hwnd handling has moved up to the TitlebarControl. The MinMaxControl now exists simply as a control with caption buttons.

Instead of the App owning the MinMaxControl, and the titlebar existing as part of the TerminalPage, the TitlebarControl is now owned by the NonClientIslandWindow. The NonClientIslandWindow will initialize it's own UI consisting of a titlebar row and a content row. It'll place a TitlebarControl instance in its titlebar row. It'll also ask the App for content to place in both the client area and the titlebar. When the app is resized, or the titlebar content is resized, the NonClientIslandWindow will update its drag area. The NonClientIslandWindow can also communicate directly with the TitlebarControl, without needing to go through the App to do so. In the future, This should make future windowing-related bugs easier to fix.

TODOs

  • There's definitely a bug with the bottom margin. A single pixel of your accent color will appear at the bottom of the window. With different MARGINs passed to DwmExtendframIntoClientArea, the amount changes. This regressed between 1905852 and 96c5da2. I want to track this down before we check this in.
    • I was able to fix this. We need to not paint the entirety of the root window. As long as it's not all painted, then the border won't be drawn. Click "details" to see my ramblings as I debugged this.
  • Definitely also regressed after 60a444c 7b8cf10 b9cc819 0219781 02e8389 (wait there's only f4e02d8 between those two??)
  • Oh no, it's broken in master. Must've regressed in f4e02d8, thank god I have that branch locally still.
  • It's fine in 9040940, which was the last commit in that PR before merging into master. I'll bisect from there to f4e02d8, we'll see where this regressed
    • 122f0de: ✔ (Just the TerminalPage changes)
    • 122f0de + 5fd4191: ✔ (TerminalPage + Most of the NC painting but not the whole titlebar thing)
    • Okay, so 9040940, where I paint the entire titlebar, is what broke it. That's definitely the commit that breaks it.
    • 9040940 + 122f0de: ❌ (Fix the NC painting, paint the entire titlebar + TerminalPage)
    • 9040940 + 60a444c: ❌ Well this was surprising
  • This is actually related to how GDI blends with the nonclient area. @Dhowett-msft was seeing this previously when trying to paint our caption buttons himself. You won't see this bug in light mode, but in dark mode, where the color is #000000, the window frame bleeds through entirely. For example, I have a bright cyan accent color. If I change the backgroundColor to #ff00000, then the single pixel at the bottom will appear almost white:
    image
  • This should probably wait for @cinnamon-msft's #1934, so that the UI is more complete. Merging will be painful.
  • I'm self-blocking this till #1164 gets in. Merging will be a pain.
**Original Pull Request:** https://github.com/microsoft/terminal/pull/1948 **State:** closed **Merged:** Yes --- <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request If a picture is worth 1000 words, then this is ~~15000 words/second~~ like 18000 words (getting a gif below 10MB was harder than I thought) ![dragging-window-004](https://user-images.githubusercontent.com/18356694/61157912-0c152f80-a4bd-11e9-9ad3-2d85f4c6de3a.gif) <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References This is a bunch of the work in #1625 and #1375. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #564 <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments This is done with a major change to the `NonClientIslandWindow`, and the `MinMaxControl`. I've introduced a new XAML control, the `TitlebarControl`. The `TitlebarControl` consists of three parts - Content, Drag Area, and `MinMaxControl`. The `MinMaxControl` is now owned by the `TitlebarControl`, and it does pretty much nothing on it's own. All the hwnd handling has moved up to the `TitlebarControl`. The `MinMaxControl` now exists simply as a control with caption buttons. Instead of the ``App`` owning the `MinMaxControl`, and the titlebar existing as part of the TerminalPage, the `TitlebarControl` is now owned by the `NonClientIslandWindow`. The `NonClientIslandWindow` will initialize it's own UI consisting of a titlebar row and a content row. It'll place a `TitlebarControl` instance in its titlebar row. It'll also ask the `App` for content to place in both the client area and the titlebar. When the app is resized, or the titlebar content is resized, the `NonClientIslandWindow` will update its drag area. The `NonClientIslandWindow` can also communicate directly with the `TitlebarControl`, without needing to go through the `App` to do so. In the future, This should make future windowing-related bugs easier to fix. ### TODOs * [x] There's definitely a bug with the bottom margin. A single pixel of your accent color will appear at the bottom of the window. With different `MARGIN`s passed to `DwmExtendframIntoClientArea`, the amount changes. This regressed between 1905852 and 96c5da2. I want to track this down before we check this in. - I was able to fix this. We need to _not_ paint the _entirety_ of the root window. As long as it's not _all_ painted, then the border won't be drawn. Click "details" to see my ramblings as I debugged this. <details> - Definitely also regressed after ~~60a444c~~ ~~7b8cf10~~ ~~b9cc819~~ ~~0219781~~ 02e8389 (wait there's only f4e02d8 between those two??) - Oh no, it's broken in master. Must've regressed in f4e02d8, thank god I have that branch locally still. - It's fine in 9040940, which was the last commit in that PR before merging into master. I'll bisect from there to f4e02d8, we'll see where this regressed - 122f0de: ✔ (Just the TerminalPage changes) - 122f0de + 5fd4191: ✔ (TerminalPage + Most of the NC painting but not the whole titlebar thing) - Okay, so 9040940, where I paint the _entire_ titlebar, is what broke it. That's _definitely_ the commit that breaks it. - 9040940 + 122f0de: ❌ (Fix the NC painting, paint the entire titlebar + TerminalPage) - 9040940 + 60a444c: ❌ Well this was surprising - This is actually related to how GDI blends with the nonclient area. @Dhowett-msft was seeing this previously when trying to paint our caption buttons himself. You won't see this bug in light mode, but in dark mode, where the color is `#000000`, the window frame bleeds through entirely. For example, I have a bright cyan accent color. If I change the `backgroundColor` to `#ff00000`, then the single pixel at the bottom will appear almost white: ![image](https://user-images.githubusercontent.com/18356694/61217120-a7342200-a6d4-11e9-9321-c482baf70f8e.png) </details> * [x] This should probably wait for @cinnamon-msft's #1934, so that the UI is more complete. Merging will be painful. * [x] I'm self-blocking this till #1164 gets in. Merging will be a pain.
claunia added the pull-request label 2026-01-31 09:05:02 +00:00
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 pull-request
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#24732
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?