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

Make panes use XAML star sizing #4953

Merged
1 commit merged into from
Mar 17, 2020
Merged

Make panes use XAML star sizing #4953

1 commit merged into from
Mar 17, 2020

Conversation

carlos-zamora
Copy link
Member

Summary of the Pull Request

Dustin and Mike had a discussion on star sizing. Mcpiroman connected the dots. I just swooped in and implemented it.

References

#3996 (comment)
#3744 (comment)

PR Checklist

Detailed Description of the Pull Request / Additional comments

Star sizing allows us to keep things proportional. Since a 1::1 proportion is the same as a 100::100 proportion, I just went in and added star sizing. In the words of a some dude with a big metal fist, everything is perfectly balanced now.

image

Validation Steps Performed

Verified for vertical, horizontal, and uneven splits.

@carlos-zamora carlos-zamora added the Area-User Interface Issues pertaining to the user interface of the Console or Terminal label Mar 17, 2020
Copy link
Contributor

@DHowett-MSFT DHowett-MSFT left a comment

Choose a reason for hiding this comment

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

Wow, this actually works?

We could take it a step farther and just use the ratio value directly instead of calculating the sizes just to throw them away and let XAML solve the equations again.

Copy link
Member

@zadjii-msft zadjii-msft left a comment

Choose a reason for hiding this comment

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

Wow okay sure lets do this...

But yea Dustin's question is a really good one. I'd be curious if using the percentages directly works. Experiment with that. Regardless of the outcome, I'll be happy with this :)

@carlos-zamora
Copy link
Member Author

After looking at it for a while, I think it's not worth it. We calculate the minimum size of each pane (and snap it to the text buffer grid) using pixels. We could probably rewrite all of that to just create a ratio. But that's risky and not really worth it.

Also, I could be wrong about this, but I'd imagine it's not a huge perf impact anyways.

@DHowett-MSFT
Copy link
Contributor

I was less worried about perf and more worried about how when we start up the terminal our size is 0x0 and when we try to do math on that we hyperexplode 😄

@DHowett-MSFT
Copy link
Contributor

(This is why new-tab and split-pane "defer" their execution, in part)

@carlos-zamora
Copy link
Member Author

Ewwww. So you're worried about 0* being passed over to xaml?

Copy link
Member

@zadjii-msft zadjii-msft left a comment

Choose a reason for hiding this comment

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

You're right about the pane snapping being a bit of a complication on all this - I'm fine with this justification. :shipit:

@carlos-zamora carlos-zamora added the AutoMerge Marked for automatic merge by the bot when requirements are met label Mar 17, 2020
@ghost
Copy link

ghost commented Mar 17, 2020

Hello @carlos-zamora!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit 1d8c5ba into master Mar 17, 2020
@ghost ghost deleted the dev/cazamor/pane-star-sizing branch March 17, 2020 17:44
@DHowett-MSFT
Copy link
Contributor

I'm not worried about 0 being passed to xaml, I'm more worried about us saying "our size was 0, and we have a 4-pixel pane separator, so your size is -4 and YOUR size is -4, good luck"

then xaml explodes us
for good reason

@mcpiroman
Copy link
Contributor

mcpiroman commented Mar 17, 2020

Oh, well I only wrote that this seems like a perfect solution. But then I realized that it is not and I was about to comment it, and then I ended up seeing that this got merged and I that I apparently forgot about it ;). So because of the snapping and 0-size issues it may actually be easier to adjust the size manually. Especially with #4068, there will be an event in a parent pane that one of the children got closed, so we could just set the remaining one the size of ourself here and be done.

DHowett-MSFT pushed a commit that referenced this pull request Mar 19, 2020
## Summary of the Pull Request
Dustin and Mike had a discussion on star sizing. Mcpiroman connected the dots. I just swooped in and implemented it.

## References
#3996 (comment)
#3744 (comment)

## PR Checklist
* [X] Closes #3744

## Detailed Description of the Pull Request / Additional comments
Star sizing allows us to keep things proportional. Since a 1::1 proportion is the same as a 100::100 proportion, I just went in and added star sizing. In the words of a some dude with a big metal fist, everything is perfectly balanced now.

![image](https://user-images.githubusercontent.com/11050425/76813679-f7103f00-67b5-11ea-9b5c-d2cc73673aba.png)

## Validation Steps Performed
Verified for vertical, horizontal, and uneven splits.

(cherry picked from commit 1d8c5ba)
@ghost
Copy link

ghost commented Mar 20, 2020

🎉Windows Terminal Preview v0.10.781.0 has been released which incorporates this pull request.:tada:

Handy links:

DHowett-MSFT pushed a commit that referenced this pull request Mar 26, 2020
This PR has evolved to encapsulate two related fixes that I can't really
untie anymore.

#2455 - Duplicating a tab that doesn't exist anymore

This was the bug I was originally fixing in #4429. 

When the user tries to `duplicateTab` with a profile that doesn't exist
anymore (like might happen after a settings reload), don't crash.

As I was going about adding tests for this, got blocked by the fact that
the Terminal couldn't open _any_ panes while the `TerminalPage` was size
0x0. This had two theoretical solutions: 

* Fake the `TerminalPage` into thinking it had a real size in the test -
  probably possible, though I'm unsure how it would work in practice.
* Change `Pane`s to not require an `ActualWidth`, `ActualHeight` on
  initialization. 

Fortuately, the second option was something else that was already on my
backlog of bugs. 

#4618 - `wt` command-line can't consistently parse more than one arg

Presently, the Terminal just arbitrarily dispatches a bunch of handlers
to try and handle all the commands provided on the commandline. That's
lead to a bunch of reports that not all the commands will always get
executed, nor will they all get executed in the same order. 

This PR also changes the `TerminalPage` to be able to dispatch all the
commands sequentially, all at once in the startup. No longer will there
be a hot second where the commands seem to execute themselves in from of
the user - they'll all happen behind the scenes on startup. 

This involved a couple other changes areound the `TerminalPage`
* I had to make sure that panes could be opened at a 0x0 size. Now they
  use a star sizing based off the percentage of the parent they're
  supposed to consume, so that when the parent _does_ get laid out,
  they'll take the appropriate size of that parent.
* I had to do some math ahead of time to try and calculate what a
  `SplitState::Automatic` would be evaluated as, despite the fact that
  we don't actually know how big the pane will be. 
* I had to ensure that `focus-tab` commands appropriately mark a single
  tab as focused while we're in startup, without roundtripping to the
  Dispatcher thread and back

## References

#4429 - the original PR for #2455
#5047 - a follow-up task from discussion in #4429
#4953 - a PR for making panes use star sizing, which was immensly
        helpful for this PR.

## Detailed Description of the Pull Request / Additional comments

`CascadiaSettings::BuildSettings` can throw if the GUID doesn't exist.
This wraps those calls up with a try/catch.

It also adds a couple tests - a few `SettingsTests` for try/catching
this state. It also adds a XAML-y test in `TabTests` that creates a
`TerminalPage` and then performs som UI-like actions on it. This test
required a minor change to how we generate the new tab dropdown - in the
tests, `Application::Current()` is _not_ a `TerminalApp::App`, so it
doesn't have a `Logic()` to query. So wrap that in a try/catch as well.

While working on these tests, I found that we'd crash pretty agressively
for mysterious reasons if the TestHostApp became focused while the test
was running. This was due to a call in
`TSFInputControl::NotifyFocusEnter` that would callback to
`TSFInputControl::_layoutRequested`, which would crash on setting the
`MaxSize` of the canvas to a negative value. This PR includes a hotfix
for that bug as well. 

## Validation Steps Performed

* Manual testing with a _lot_ of commands in a commandline
* run the tests
* Team tested in selfhost

Closes #2455
Closes #4618
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-User Interface Issues pertaining to the user interface of the Console or Terminal AutoMerge Marked for automatic merge by the bot when requirements are met
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Sometimes panes won't expand and take up blanks
4 participants