Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Megathread] Panes Titlebar Follow-ups #4998

Open
6 tasks
zadjii-msft opened this issue Mar 18, 2020 · 0 comments
Open
6 tasks

[Megathread] Panes Titlebar Follow-ups #4998

zadjii-msft opened this issue Mar 18, 2020 · 0 comments
Labels
Area-User Interface Issues pertaining to the user interface of the Console or Terminal Issue-Scenario Product-Terminal The new Windows Terminal.
Milestone
Megathreads

Comments

@zadjii-msft
Copy link
Member

zadjii-msft commented Mar 18, 2020 •
edited
Loading

[Panes megathread #1000] [Original PR: #7371] [Original Issue: #4717]

Tasks

Open Discussion

Currently, setting the tab's background color with the color picker does not update the pane titlebar color.

I think that's fine. Currently, the order of precedence is [tab runtime color, control title color, theme color (unimplemented), default color]. So I could imagine this going two ways:

  • convert the "tab runtime color" to be a "pane runtime color". Then, using the color picker on the tab would set the active pane's runtime color. This comes with the detrimental side effect that you'd have to re-color each pane in a tab manually.
  • add an additional "pane runtime color", and have the tab's color be composed from [tab runtime color, pane color (which is itself [pane runtime color, control title color, theme pane title color]), theme color, default]. This would allow panes to have their color changed at runtime with a color picker, and also have the tab have a manual color override.

I'm of course just hypothesizing here in the comments - I don't think any of this is something that needs to get done in this PR. We can always loop back on the issue in a follow-up.

  • Should the titlebar for a pane not appear until there are multiple panes? Kinda seems like there are three states: paneTitlebarVisibility: [never, multiplePanes, always]
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Mar 18, 2020
@DHowett-MSFT DHowett-MSFT removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Mar 18, 2020
@miniksa miniksa added ⛺ Reserved For future use and removed Needs-Tag-Fix Doesn't match tag requirements labels Jul 6, 2020
@zadjii-msft zadjii-msft changed the title [Reserved for future use] [Megathread] Panes Titlebar Follow-ups Aug 25, 2020
@zadjii-msft zadjii-msft added Area-User Interface Issues pertaining to the user interface of the Console or Terminal Issue-Scenario Product-Terminal The new Windows Terminal. and removed ⛺ Reserved For future use labels Aug 25, 2020
@zadjii-msft zadjii-msft added this to the Terminal Backlog milestone Aug 25, 2020
@zadjii-msft zadjii-msft mentioned this issue Aug 25, 2020
Open
59 tasks
@zadjii-msft zadjii-msft mentioned this issue Nov 23, 2020
Closed
This was referenced Feb 8, 2021
Closed
Closed
@zadjii-msft zadjii-msft mentioned this issue Mar 3, 2021
Merged
3 tasks
@zadjii-msft zadjii-msft mentioned this issue Oct 25, 2021
Closed
zadjii-msft added a commit that referenced this issue Oct 25, 2021
@zadjii-msft
Make sure the infobar is inserted before the tab content, not on top of
753ad54 
  Fixes #11606

  This is weird, but the infobars would appear totally on top of the
  TerminalPage when `showTabsInTitlebar:false`. This would result in the infobar
  obscuring the tabs.

  Now, the infobars are strictly inserted after the tabs, before the content. So
  when they appear, they will reduce the amount of space usable for the control.
  That is a little annoying, but preferable to the tabs totally not existing.

  Relevant conversation notes from #10798:

  > > If the info bar is not local to the tab, then its location between the tab
  > > bar (when the title bar is hidden) and the terminal panes feels
  > > misleading. Should it instead be above the tab bar or below the terminal
  > > panes?
  >
  > You're... not wrong here. It's maybe not the best place for it, but _on top_
  > of the tabs would look insane, and probably wouldn't even work easily, given
  > the way we reparent the tab row into the titlebar.
  >
  > In the pane itself would make more sense, but that runs abreast of all sorts
  > of things like #9024, #4998, which might make more sense.

  I'm just gonna go with this now, because it's _better_ than before, while we
  work out what's _best_.
@zadjii-msft zadjii-msft mentioned this issue Oct 25, 2021
Merged
ghost pushed a commit that referenced this issue Oct 26, 2021
@zadjii-msft
Make sure the infobar is inserted before the tab content, not on top …
a916a5d 
…of (#11609)

Fixes #11606

This is weird, but the infobars would appear totally on top of the
TerminalPage when `showTabsInTitlebar:false`. This would result in the infobar
obscuring the tabs.

Now, the infobars are strictly inserted after the tabs, before the content. So
when they appear, they will reduce the amount of space usable for the control.
That is a little annoying, but preferable to the tabs totally not existing.

Relevant conversation notes from #10798:

> > If the info bar is not local to the tab, then its location between the tab
> > bar (when the title bar is hidden) and the terminal panes feels
> > misleading. Should it instead be above the tab bar or below the terminal
> > panes?
>
> You're... not wrong here. It's maybe not the best place for it, but _on top_
> of the tabs would look insane, and probably wouldn't even work easily, given
> the way we reparent the tab row into the titlebar.
>
> In the pane itself would make more sense, but that runs abreast of all sorts
> of things like #9024, #4998, which might make more sense.

I'm just gonna go with this now, because it's _better_ than before, while we
work out what's _best_.

![gh-11606-fix](https://user-images.githubusercontent.com/18356694/138729178-b96b7003-0dd2-4521-8fff-0fd2a5989f22.gif)
DHowett pushed a commit that referenced this issue Dec 13, 2021
@zadjii-msft @DHowett
Make sure the infobar is inserted before the tab content, not on top …
f2222ec 
…of (#11609)

Fixes #11606

This is weird, but the infobars would appear totally on top of the
TerminalPage when `showTabsInTitlebar:false`. This would result in the infobar
obscuring the tabs.

Now, the infobars are strictly inserted after the tabs, before the content. So
when they appear, they will reduce the amount of space usable for the control.
That is a little annoying, but preferable to the tabs totally not existing.

Relevant conversation notes from #10798:

> > If the info bar is not local to the tab, then its location between the tab
> > bar (when the title bar is hidden) and the terminal panes feels
> > misleading. Should it instead be above the tab bar or below the terminal
> > panes?
>
> You're... not wrong here. It's maybe not the best place for it, but _on top_
> of the tabs would look insane, and probably wouldn't even work easily, given
> the way we reparent the tab row into the titlebar.
>
> In the pane itself would make more sense, but that runs abreast of all sorts
> of things like #9024, #4998, which might make more sense.

I'm just gonna go with this now, because it's _better_ than before, while we
work out what's _best_.

![gh-11606-fix](https://user-images.githubusercontent.com/18356694/138729178-b96b7003-0dd2-4521-8fff-0fd2a5989f22.gif)

(cherry picked from commit a916a5d)
DHowett pushed a commit that referenced this issue Dec 13, 2021
@zadjii-msft @DHowett
Make sure the infobar is inserted before the tab content, not on top …
5198c8e 
…of (#11609)

Fixes #11606

This is weird, but the infobars would appear totally on top of the
TerminalPage when `showTabsInTitlebar:false`. This would result in the infobar
obscuring the tabs.

Now, the infobars are strictly inserted after the tabs, before the content. So
when they appear, they will reduce the amount of space usable for the control.
That is a little annoying, but preferable to the tabs totally not existing.

Relevant conversation notes from #10798:

> > If the info bar is not local to the tab, then its location between the tab
> > bar (when the title bar is hidden) and the terminal panes feels
> > misleading. Should it instead be above the tab bar or below the terminal
> > panes?
>
> You're... not wrong here. It's maybe not the best place for it, but _on top_
> of the tabs would look insane, and probably wouldn't even work easily, given
> the way we reparent the tab row into the titlebar.
>
> In the pane itself would make more sense, but that runs abreast of all sorts
> of things like #9024, #4998, which might make more sense.

I'm just gonna go with this now, because it's _better_ than before, while we
work out what's _best_.

![gh-11606-fix](https://user-images.githubusercontent.com/18356694/138729178-b96b7003-0dd2-4521-8fff-0fd2a5989f22.gif)

(cherry picked from commit a916a5d)
carlos-zamora pushed a commit that referenced this issue Dec 13, 2022
@zadjii-msft
DRAFT Spec for Broadcast Input (#9365)
3a122bf 
### ⇒ [doc link](https://github.com/microsoft/terminal/blob/dev/migrie/s/2634-broadcast-input/doc/specs/drafts/%232634%20-%20Broadcast%20Input/%232634%20-%20Broadcast%20Input.md) ⇐

## Summary of the Pull Request

This is supposed to be a quick and dirty spec to socialize the various different options for Broadcast Input mode with the team. Hopefully we can come up with a big-picture design for the feature, so we can unblock #9222. 

### Abstract

> With a viable prototype in #9222, it's important that we have a well-defined
> plan for how we want this feature to be exposed before merging that PR. This
> spec is intended to be a lighter-than-usual spec to build consensus on the
> design of how the actions should be expressed.

...

> _**Fortunately**_: All these proposals actually use the same set of actions. So
> it doesn't _really_ matter which we pick right now. We can unblock #9222 as
> the implementation of the `"tab"` scope, and address other scopes in the future.
> We should still decide long-term which of these we'd like, but the actions seem
> universal.


## PR Checklist
* [x] Specs: #2634
* [x] References: #9222, #4998
* [x] I work here

## Detailed Description of the Pull Request / Additional comments
_\*<sup>\*</sup><sub>\*</sub> read the spec  <sub>\*</sub><sup>\*</sup>\*_
@zadjii-msft zadjii-msft mentioned this issue Jan 17, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Area-User Interface Issues pertaining to the user interface of the Console or Terminal Issue-Scenario Product-Terminal The new Windows Terminal.
Projects
None yet
Milestone
Megathreads
Development

No branches or pull requests
3 participants
@DHowett-MSFT @miniksa @zadjii-msft