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

[Megathread] Fullscreen & Focus Mode follow-up work #4871

New Issue
Open
opened 2026-01-30 23:58:43 +00:00 by claunia · 6 comments
claunia commented 2026-01-30 23:58:43 +00:00
Owner
Copy Link

Originally created by @zadjii-msft on GitHub (Nov 8, 2019).

Taken from https://github.com/microsoft/terminal/issues/531#issuecomment-531046569

I'd suggest that this is broken into 3 implementation steps:

  1. Support fullscreen mode, with always hidden tabs
  2. Add a setting to have tabs always visible in fullscreen mode
  3. Enable "revealing" tabs on mouse hover near the top

Step 3 has some implementation details that are missing, like: on tabs reveal, should the tabs:

  • cover the terminal content, obscuring the top rows, but leaving the rest of the window unchanged
  • cause the terminal to resize
  • shift the terminal content down, obscuring the bottom rows of the terminal, but not forcing a resize?

Now that #3408 is merged (closing #531), we need some place to track the follow-up tasks I had outlined before:

Focus mode and Fullscreen share a lot of commonalities, so I'm grouping them into one thread for easy of x-linking.

Fullscreen

  • Support fullscreen mode, with always hidden tabs
  • #11130 - Add a setting to have tabs always visible in fullscreen mode
    • "showTabsInFullscreen": true|"always"
  • #5677 - Enable "revealing" tabs on mouse hover near the top
    • "showTabsInFullscreen": "hover"
  • If a launch full screen option is there, when the full screened app launches, I think the TabView should be visible for a few seconds before sliding out of view. (from @mdtuak in https://github.com/microsoft/terminal/issues/288#issuecomment-551950312)
  • #4000 It would be nice to have a kind of popup with a tab name when you switch tabs with CTRL+TAB in fullscreen mode.
    • Let's add a setting for this as well, this sounds like a not so terrible idea.
    • This is the "advanced tab switcher"

Focus Mode

Originally created by @zadjii-msft on GitHub (Nov 8, 2019). Taken from https://github.com/microsoft/terminal/issues/531#issuecomment-531046569 > I'd suggest that this is broken into 3 implementation steps: > 1. Support fullscreen mode, with always hidden tabs > 2. Add a setting to have tabs _always_ visible in fullscreen mode > 3. Enable "revealing" tabs on mouse hover near the top > > Step 3 has some implementation details that are missing, like: on tabs reveal, should the tabs: > * cover the terminal content, obscuring the top rows, but leaving the rest of the window unchanged > * cause the terminal to resize > * shift the terminal content down, obscuring the bottom rows of the terminal, but not forcing a resize? Now that #3408 is merged (closing #531), we need some place to track the follow-up tasks I had outlined before: Focus mode and Fullscreen share a lot of commonalities, so I'm grouping them into one thread for easy of x-linking. ## Fullscreen * [x] Support fullscreen mode, with always hidden tabs * [ ] #11130 - Add a setting to have tabs _always_ visible in fullscreen mode - `"showTabsInFullscreen": true|"always"` * [ ] #5677 - Enable "revealing" tabs on mouse hover near the top - `"showTabsInFullscreen": "hover"` * [ ] If a launch full screen option is there, when the full screened app launches, I think the TabView should be visible for a few seconds before sliding out of view. (from @mdtuak in https://github.com/microsoft/terminal/issues/288#issuecomment-551950312) - this is dependent upon adding `fullscreen` to `launchMode`, tracked in #288 * [x] #4000 It would be nice to have a kind of popup with a tab name when you switch tabs with CTRL+TAB in fullscreen mode. - Let's add a setting for this as well, this sounds like a not so terrible idea. - This is the "advanced tab switcher" ## Focus Mode * [ ] #539 - Not _necessarily_ Focus Mode related, but certainly relevant * [x] #10730 * [ ] #7210 * [ ] #12959
claunia added the Product-TerminalArea-UserInterfaceIssue-Scenario labels 2026-01-30 23:58:43 +00:00
claunia commented 2026-01-30 23:58:44 +00:00
Author
Owner
Copy Link

@nathpete-msft commented on GitHub (Dec 6, 2019):

@zadjii-msft, as part of step 2, could that setting also have an option to only show tabs in fullscreen if there is currently more than one tab? Or would that setting just also take into account the existing alwaysShowTabs setting? The latter is how iTerm handles this, and I think feels pretty natural.

In that case, these settings might behave together like so:

State 2+ Tabs Always Show Tabs Show Tabs In Fullscreen Tabs Visible
Windowed Yes Yes N/A Yes
Windowed Yes No N/A Yes
Windowed No Yes N/A Yes
Windowed No No N/A No
Fullscreen Yes Yes Yes Yes
Fullscreen Yes Yes No No
Fullscreen Yes No Yes Yes
Fullscreen Yes No No No
Fullscreen No Yes Yes Yes
Fullscreen No Yes No No
Fullscreen No No Yes No
Fullscreen No No No No
@nathpete-msft commented on GitHub (Dec 6, 2019): @zadjii-msft, as part of step 2, could that setting also have an option to only show tabs in fullscreen if there is currently more than one tab? Or would that setting just also take into account the existing `alwaysShowTabs` setting? The latter is how iTerm handles this, and I think feels pretty natural. In that case, these settings might behave together like so: State | 2+ Tabs | Always Show Tabs | Show Tabs In Fullscreen | Tabs Visible -|-|-|-|- Windowed | Yes | Yes | N/A | Yes Windowed | Yes | No | N/A | Yes Windowed | No | Yes | N/A | Yes Windowed | No | No | N/A | No Fullscreen | Yes | Yes | Yes | Yes Fullscreen | Yes | Yes | No | No Fullscreen | Yes | No | Yes | Yes Fullscreen | Yes | No | No | No Fullscreen | No | Yes | Yes | Yes Fullscreen | No | Yes | No | No Fullscreen | No | No | Yes | No Fullscreen | No | No | No | No
claunia commented 2026-01-30 23:58:44 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 6, 2019):

@nathpete-msft That seems pretty reasonable to me. If that's how iTerm2 does it, then that's a pretty good precedent.

@zadjii-msft commented on GitHub (Dec 6, 2019): @nathpete-msft That seems pretty reasonable to me. If that's how iTerm2 does it, then that's a pretty good precedent.
claunia commented 2026-01-30 23:58:44 +00:00
Author
Owner
Copy Link

@dominik-ba commented on GitHub (Mar 25, 2020):

I would love to have step 2 implemented. Especially if you have windows terminal in a second desktop you can simply switch to a fullscreen terminal with win + cmd + left/right. I know this works alreday but not knowing which tabs are open and which one I am using is a bit of a hassle.
That would be awesome! :)
Any plans on when this will get implemented?

PS: Now that I check on some more issues in this repo I'm confused since quite some people created (duplicate) issues about the padding of the tabs in fullscreen mode but I checked again and did not find a way or documentation how to enable this. Is this PR old or are those people not acutually talking about fullscreen?

@dominik-ba commented on GitHub (Mar 25, 2020): I would love to have step 2 implemented. Especially if you have windows terminal in a second desktop you can simply switch to a fullscreen terminal with `win + cmd + left/right`. I know this works alreday but not knowing which tabs are open and which one I am using is a bit of a hassle. That would be awesome! :) Any plans on when this will get implemented? PS: Now that I check on some more issues in this repo I'm confused since quite some people created (duplicate) issues about the padding of the tabs in fullscreen mode but I checked again and did not find a way or documentation how to enable this. Is this PR old or are those people not acutually talking about fullscreen?
claunia commented 2026-01-30 23:58:44 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 25, 2020):

@dominik-ba This work is not currently on any particular milestone. I can guarantee that it's not making the cut for 1.0, since we're currently in a feature-freeze as we prepare to release 1.0.

I think some of the other issues you're referring too mainly mean "maximized" when they're saying "fullscreen"

@zadjii-msft commented on GitHub (Mar 25, 2020): @dominik-ba This work is not currently on any particular milestone. I can guarantee that it's not making the cut for 1.0, since we're currently in a feature-freeze as we prepare to release 1.0. I think some of the other issues you're referring too mainly mean "maximized" when they're saying "fullscreen"
claunia commented 2026-01-30 23:58:44 +00:00
Author
Owner
Copy Link

@dominik-ba commented on GitHub (Jul 26, 2020):

Wouldn't it be relatively easy to enable th new toggle focus feature also on fullscreen?
This would check step 2 :)

@dominik-ba commented on GitHub (Jul 26, 2020): Wouldn't it be _relatively_ easy to enable th new toggle focus feature also on fullscreen? This would check step 2 :)
claunia commented 2026-01-30 23:58:45 +00:00
Author
Owner
Copy Link

@GeekJosh commented on GitHub (Nov 10, 2024):

Just for visibility, I have opened a PR to address #11130 (no tabs in fullscreen): https://github.com/microsoft/terminal/pull/18171

I really like the idea of #5677 (show tabs on hover), so once a decision is made on my current PR (adding the simpler true/false setting), I'm happy to take a look at implementing that next. As TabView doesn't currently support a "reveal on hover" setting, my initial thought would be to use to a Flyout to achieve that effect, though I will admit I don't have a huge amount of experience with WinUI so if that is a bad idea I'm open to looking in to alternative implementations if anyone has any suggestions?

@GeekJosh commented on GitHub (Nov 10, 2024): Just for visibility, I have opened a PR to address #11130 (no tabs in fullscreen): https://github.com/microsoft/terminal/pull/18171 I really like the idea of #5677 (show tabs on hover), so once a decision is made on my current PR (adding the simpler `true`/`false` setting), I'm happy to take a look at implementing that next. As `TabView` doesn't currently support a "reveal on hover" setting, my initial thought would be to use to a `Flyout` to achieve that effect, though I will admit I don't have a huge amount of experience with WinUI so if that is a bad idea I'm open to looking in to alternative implementations if anyone has any suggestions?
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-Scenario Product-Terminal
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#4871
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?