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.

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

Refactor the SettingsTab to be a pane #16172

Merged
merged 94 commits into from
Apr 3, 2024
Merged

Conversation

zadjii-msft
Copy link
Member

@zadjii-msft zadjii-msft commented Oct 13, 2023

... technically. We still won't let it actually be a pane, but now it acts like one. It's hosted in a SettingsPaneContent. There's no more SettingsTab. It totally can be in a pane (but don't?)

Validation Steps Performed

  • Still opens the settings
  • Only opens a single settings tab, or re-activates the existing one
  • Session restores!
  • Updates the title of the tab appropriately
  • I previously did use the scratchpad action to open the settings in a pane, and that worked.

Related PRs

Refs #997
Closes #8452

github-merge-queue bot pushed a commit that referenced this pull request Mar 26, 2024
## Summary of the Pull Request

Builds upon #16170. This PR simply adds a singly type of non-terminal
pane - a "scratchpad pane". This is literally just a single text box, in
a pane. It's on the `{ "command": "experimental.openScratchpad" }`
action.

## References and Relevant Issues

See: #997

## Detailed Description of the Pull Request / Additional comments

I also put it behind velocity so it won't even go into preview while
this bakes.

This is really just here to demonstrate that this works, and is viable.
The next PR is much more interesting.

## Validation Steps Performed
Screenshot below. 


## other PRs
* #16170
* #16171 <-- you are here 
* #16172
Base automatically changed from dev/migrie/fhl/scratchpad-pane to main March 26, 2024 18:34
@zadjii-msft
Copy link
Member Author

but yes, you know what? I'll do that this week and stack it on here

This is in dev/migrie/f/sui-panes...dev/migrie/b/remove-terminaltab

That's ready to go here, but there's also still another two PRs stacked on top of here. Let's merge those in too, before the noisy rename & move

@microsoft-github-policy-service microsoft-github-policy-service bot added Issue-Task It's a feature request, but it doesn't really need a major design. Area-CodeHealth Issues related to code cleanliness, linting, rules, warnings, errors, static analysis, etc. Area-User Interface Issues pertaining to the user interface of the Console or Terminal Product-Terminal The new Windows Terminal. labels Mar 27, 2024
// Do nothing. We'll later be updated manually by
// UpdateTerminalSettings, which we need for profile and
// focused/unfocused settings.
assert(false); // If you hit this, you done goofed.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: i'd prefer a more specific and actionable message than "you done goofed"

@@ -383,7 +390,7 @@ namespace winrt::TerminalApp::implementation
return RS_(L"MultiplePanes");
}
const auto activeContent = GetActiveContent();
return activeContent ? activeContent.Title() : L"";
return activeContent ? activeContent.Title() : winrt::hstring{ L"" };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit

Suggested change
return activeContent ? activeContent.Title() : winrt::hstring{ L"" };
return activeContent ? activeContent.Title() : winrt::hstring{};

These are equivalent, but now that you have to specify the type explicitly we may as well switch to the nullary constructor

// HORRIBLE
//
// Workaround till we know how we actually want to handle state
// restoring other kinda of panes. If this is a settings tab, just
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// restoring other kinda of panes. If this is a settings tab, just
// restoring other kinds of panes. If this is a settings tab, just


namespace TerminalApp
{
[default_interface] runtimeclass TerminalPaneContent : IPaneContent, ISnappable
{
Microsoft.Terminal.Control.TermControl GetTermControl();

void UpdateSettings(const Microsoft.Terminal.Settings.Model.TerminalSettingsCreateResult settings,
const Microsoft.Terminal.Settings.Model.Profile profile);
void UpdateTerminalSettings(TerminalSettingsCache cache);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From an "offline" (lol) discussion:
It may make sense here to construct TerminalPaneContent with a shared reference to the TerminalSettingsCache and then let UpdateSettings() create the cached objects lazily. That way we avoid the extra API function and try_as tests.

We can do this in a follow-up PR.

@zadjii-msft zadjii-msft added this pull request to the merge queue Apr 3, 2024
Merged via the queue into main with commit 67ae9f6 Apr 3, 2024
20 checks passed
@zadjii-msft zadjii-msft deleted the dev/migrie/f/sui-panes branch April 3, 2024 16:02
github-merge-queue bot pushed a commit that referenced this pull request Apr 5, 2024
As @lhecker noted in the #16172 review, `UpdateTerminalSettings` is
wacky. We can just pass the cache in at the start, then reset it and
reuse it in `UpdateSettings`. One fewer `try_as`!
github-merge-queue bot pushed a commit that referenced this pull request Apr 5, 2024
…splitPane`, `newTab` (#16914)

This changes `NewTabArgs`, `SplitPaneArgs`, and `NewWindowArgs` to
accept a `INewContentArgs`, rather than just a `NewTerminalArgs`. This
allows a couple things:
* Users can open arbitrary types of panes with the existing `splitPane`,
`newWindow` actions, just by passing `"type": "scartchpad"` (for
example). This is a lot more flexible than re-defining different
`"openScratchpad"`, `"openTasksPane"`, etc, etc actions for every kind
of pane.
* This allows us to use the existing machinery of session restore to
also restore non-terminal panes.

The `type` property was added to `newTab`, `splitPane`, `newWindow`.
When omitted, we still just treat the json as a blob of NewTerminalArgs.

There's not actually any other kinds of `INewContentArgs` in this PR
(other than the placeholder `GenericContentArgs`). In
[`dev/migrie/fhl/md-pane`](dev/migrie/f/tasks-pane...dev/migrie/fhl/md-pane),
I have a type of pane that would LOVE to add some args here. So that's
forward-thinking.

There's really just two stealth types of pane for now: `settings`, and
`scratchpad`. Those I DON'T have as constants or anything in this PR.
They probably should be? Though, I suspect around the time of the tasks
& MD panes, I'll come up with whatever structure I actually want them to
take.

### future considerations here

* In the future, this should allow extensions to say "I know how to host
`foo` content", for 3p content.
* The `wt` CLI args were not yet updated to also accept `--type` yet.
There's no reason we couldn't easily do that.
* I considered adding `ICanHasCommandline` to allow arbitrary content to
generate a `wt` commandline-serializable string. Punted on that for now.


## other PRs
* #16170
  * #16171 
    * #16172 
      * #16895 
      * #16914 <-- you are here 

Closes #17014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-CodeHealth Issues related to code cleanliness, linting, rules, warnings, errors, static analysis, etc. Area-User Interface Issues pertaining to the user interface of the Console or Terminal Issue-Task It's a feature request, but it doesn't really need a major design. Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Polish TabBase
4 participants