Add titlebars to panes

[HunterMitchell]

Summary of the Pull Request

This pull request adds titlebars to panes. Below are a few features / changes:

• The pane's title can be changed by double-click or by a context menu when right clicking on the titlebar.
• The tab's title reflects the active pane's title, not the control's title.
• The pane titlebar's background color can be changed using the "tabColor" setting only right now.
• If no "tabColor" is chosen, the default is ChromeDisabledHigh.
• The pane's foreground color is dynamically changed depending on the brightness of its background.

References

This pull request should close #7290 and provides #7075 with a solution.

PR Checklist

• Closes Panes should have editable titles #7290
• CLA signed. If not, go over here and sign the CLA
• Tests added/passed
• Documentation updated. If checked, please file a pull request on our docs repo and link it here: #xxx
• Schema updated.
• I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: Panes should have editable titles #7290

Detailed Description of the Pull Request / Additional comments

Current Issues with this PR

• A crash occurs when closing a pane child and then attempting to edit the pane title. I am looking for some guidance here, as I could not figure out the root cause of the issue. Inside the _CloseChild method, if I don't release _firstChild or _secondChild, it works (however creating a memory leak).
• Currently, setting the tab's background color with the color picker does not update the pane titlebar color.
• Code Quality – I am sure there are better ways of doing some of the things in this PR (new to the codebase and C++ isn't my primary language). I would be more than happy to make edits based on feedback received.

Future Thoughts:

• Add support for changing the pane titlebar background/foreground colors, font/font-size, etc. directly. This was discussed here: Panes should have editable titles #7290 (comment)
• Add support for changing the pane titlebar background/foreground colors to indicate if a pane is active. My thoughts on that start here: Panes should have editable titles #7290 (comment)

Validation Steps Performed

1. Set showPaneTitlebar to true if not already.
2. Double-Click the title or use the context-menu by right-clicking the titlebar to edit the title.
3. Confirm by pressing enter or clicking away from textbox. Press escape to cancel the edit.

[github-actions]

New misspellings found, please review:

• Definiation

To accept these changes, run the following commands

perl -e '
my @expect_files=qw('".github/actions/spell-check/expect/af1ff90dc512c83c902762b02f284c1c61603b4a.txt
.github/actions/spell-check/expect/alphabet.txt
.github/actions/spell-check/expect/expect.txt
.github/actions/spell-check/expect/web.txt"');
@ARGV=@expect_files;
my @stale=qw('"Autogenerated Inplace notypeopt Textbox "');
my $re=join "|", @stale;
my $suffix=".".time();
my $previous="";
sub maybe_unlink { unlink($_[0]) if $_[0]; }
while (<>) {
  if ($ARGV ne $old_argv) { maybe_unlink($previous); $previous="$ARGV$suffix"; rename($ARGV, $previous); open(ARGV_OUT, ">$ARGV"); select(ARGV_OUT); $old_argv = $ARGV; }
  next if /^($re)(?:$| .*)/; print;
}; maybe_unlink($previous);'
perl -e '
my $new_expect_file=".github/actions/spell-check/expect/82b6fce5782662b7bbc35802ead5811682566c0a.txt";
open FILE, q{<}, $new_expect_file; chomp(my @words = <FILE>); close FILE;
my @add=qw('"autogenerated Definiation inplace textbox "');
my %items; @items{@words} = @words x (1); @items{@add} = @add x (1);
@words = sort {lc($a) cmp lc($b)} keys %items;
open FILE, q{>}, $new_expect_file; for my $word (@words) { print FILE "$word\n" if $word =~ /\w/; };
close FILE;'
git add .github/actions/spell-check/expect || echo '... you want to ensure .github/actions/spell-check/expect/82b6fce5782662b7bbc35802ead5811682566c0a.txt is added to your repository...'

✏️ Contributor please read this

By default the command suggestion will generate a file named based on your commit. That's generally ok as long as you add the file to your commit. Someone can reorganize it later.

⚠️ The command is written for posix shells. You can copy the contents of each perl command excluding the outer ' marks and dropping any '"/"' quotation mark pairs into a file and then run perl file.pl from the root of the repository to run the code. Alternatively, you can manually insert the items...

If the listed items are:

• ... misspelled, then please correct them instead of using the command.
• ... names, please add them to .github/actions/spell-check/dictionary/names.txt.
• ... APIs, you can add them to a file in .github/actions/spell-check/dictionary/.
• ... just things you're using, please add them to an appropriate file in .github/actions/spell-check/expect/.
• ... tokens you only need in one place and shouldn't generally be used, you can add an item in an appropriate file in .github/actions/spell-check/patterns/.

See the README.md in each directory for more information.

🔬 You can test your commits without appending to a PR by creating a new branch with that extra change and pushing it to your fork. The :check-spelling action will run in response to your push -- it doesn't require an open pull request. By using such a branch, you can limit the number of typos your peers see you make. 😉

⚠️ Reviewers

At present, the action that triggered this message will not show its ❌ in this PR unless the branch is within this repository.
Thus, you should make sure that this comment has been addressed before encouraging the merge bot to merge this PR.

[zadjii-msft]

Alright I definitely owe you a longer review, but here's something to start with just from initial glance.

[zadjii-msft]

Both the lambda's in this function need to capture a weak ref to this with std::weak_ptr<Pane> weakThis{ shared_from_this() };

[HunterMitchell]

Attempting to get a weak reference to this results in a runtime crash. The function containing this code is called only in the Pane's constructor.

[zadjii-msft]

Oh well that's annoying. We might need to do add a TODO to follow-up after #3999 to make those take weakrefs. I'm not sure how we could fix those at the moment. Maybe more coffee will help...

[HunterMitchell]

Sounds good, let me know what else I can do to help! Also, please note the issue regarding a crash after a child pane is closed still exists even though I marked that comment as being resolved. ☕

[zadjii-msft]

For those curious for a preview:

Note that my ubuntu profile has acrylic pretty agressively enabled. What is important:

• the pane's title color reflects the control "tab color" (or title color).
• The tab reflects the focused pane's "title color" and "title text". So selecting the "foo" pane changes the tab text to "foo", and the tab color to purple, while selecting the "cmd" pane changes the tab color to the default black, and the tab text to "cmd".
• this looks awesome with focus mode:
  
• Maybe the default pane titlebar color should be the same as the focused tab item background? That might lead to more consistency with the UX when a pane has a title color

---

re:

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.

[HunterMitchell]

So, here's a quick update. I fixed some of the comments above, however, the issue regarding a crash after a child pane is closed still exists and I have not been able to find a fix in my free time. This maybe held up by #3999?

[HunterMitchell]

Just wanted to get this back into the spotlight in case it got lost in the pile of other feature requests / issues. I know you showed some interested in this feature @DHowett, so would you mind also taking a look at some of the code here and maybe provide some insight. I didn't want to bother @zadjii-msft since he is out. Let me know what you think!

[DHowett]

I love this, and I think it's the right thing for us to do.

I've got a couple minor concerns that might amount to a lot of work, unfortunately. We're not really in a good place to keep adding UI to Pane. It's my goal to eventually get us to a .xaml file that we can move all the control code into leaving Pane.cpp to host the logic. That'll require us to do a bit of work to make Pane a XAML control itself, which I'm certain is the correct thing to do.

I think a titlebar needs to be a part of that. I'm undecided as to whether this should be blocked by that work.

Thanks so much for writing this up. It's really promising, and I love how it looks!

[HunterMitchell]

As much as I want this feature done as quickly as possible, I would rather us do the harder work up front so additions to the Pane titlebar and Pane itself are easier. In this case I agree that this PR should be blocked until there is a better solution like you provided. I would be up for helping rework some of it, but I have been busy recently.

[DHowett]

In this case I agree that this PR should be blocked until there is a better solution like you provided. I would be up for helping rework some of it, but I have been busy recently.

I'll close this for now, but not as a rejection. This is a sound idea that we'll revisit when we can support it best 😄

Thanks so much for doing the lifting here.