-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Indicate which pane is focused with the Accent color on the pan… #3060
Conversation
(I don't intend to get this in before I leave on vacation) |
I bet there's a way to bind this that doesn't require us to propagate bitfields of border sizes down, down, down. |
On your screenshots, under the window there is thin strip of what appears to be accent color. Is this right? Secondly, this could be (optionally) done tmux-style, with highlight on separators rather than borders. This would save half a space of a now-quite-thick border. While borders can be shrinked right now, it would make the highlight less visible as it only covers half of the border. |
…com/Microsoft/Terminal into dev/migrie/f/994-pane-focus-borders
This reverts commit 3fc14da.
I tried adding the pane seperators to the Pane::_GetMinWidth calculation. That works for prevent the crash, but the resizing is wonky now. If you add a Vertical split, then a second, then resize the middle pane really small, you'll see that the _last_ resize doesn't work properly. The text seems to overhand into the border. Additionally, there's really weird behavior resizing panes to be small. They don't always seem to be resizable to the smallest size.
This reverts commit 2fd8323.
Again, no idea what I really did that worked, but it does
This makes so much more sense now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still a bit confused about the bitfield for borders. Why do we need to keep track of [who has a left, top, bottom, right] when we could just say [the leafmost focused pane has all four, and any other panes have zero of them]? Would our UI look strange or wrong that way?
@DHowett-MSFT and I resolved the discussion offline - there was some confusion on how I implemented this. Panes only have borders on the sides that are adjacent to other panes. Case in point: |
@@ -446,10 +475,13 @@ void Pane::UpdateFocus() | |||
_control.FocusState() != FocusState::Unfocused; | |||
|
|||
_lastFocused = controlFocused; | |||
|
|||
_border.BorderBrush(_lastFocused ? s_focusedBorderBrush : nullptr); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
qq: should this be when the pane is focused, or should it be tied to the control hosted inside the pane? Each UIElement/Control has a focus event that we could subscribe to, and the pane could handle updating its status when the control gains/loses focus
or will that be bad when we finally decouple active and focused?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO:
"when the pane is focused" == "active"
"when the control is focused" == "focused"
So I think the border should be there when the pane is active. We don't want the border to disappear when another UI element appears (e.g. the command palette). Also consider a pane where there are many (non-terminal) controls, any of which could be focused.
Ideally, all this will get resolved when we loop back on the active vs focused issue #1205
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes more sense for this to be on the pane than the control. Two scenarios come to mind:
- if we support having something other than a TermControl, we can still apply the border
- if we wanted to allow multiple panes to be "selected" for some reason, it still works
@@ -554,15 +593,18 @@ void Pane::_CloseChild(const bool closeFirst) | |||
// re-attach the TermControl to our Grid. | |||
_firstChild->_root.Children().Clear(); | |||
_secondChild->_root.Children().Clear(); | |||
_firstChild->_border.Child(nullptr); | |||
_secondChild->_border.Child(nullptr); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should a pane just always have a border, and it's set to invisible when it doesn't need it? Instead of getting the border removed by its parent pane... it seems like we shouldn't be reaching into our childrens' visual trees..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a bad idea IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay so looking into that one, that's not as bad. This case here is us removing the controls from the child's UI tree, because we're taking ownership of it. This is happening because one child closed, and we need to absorb the remaining child's state into ourselves.
When we first split, we do remove our own border, in order to add the two children directly to our root grid. Hypothetically, we could leave that border around always, but we'd need to add another grid to the tree always (since a Border can only ever have one child)
@@ -446,10 +475,13 @@ void Pane::UpdateFocus() | |||
_control.FocusState() != FocusState::Unfocused; | |||
|
|||
_lastFocused = controlFocused; | |||
|
|||
_border.BorderBrush(_lastFocused ? s_focusedBorderBrush : nullptr); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes more sense for this to be on the pane than the control. Two scenarios come to mind:
- if we support having something other than a TermControl, we can still apply the border
- if we wanted to allow multiple panes to be "selected" for some reason, it still works
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks fine to me, but I'm not going to merge it because there are a few Dustin comments outstanding.
(I spoke with Dustin - he's fine with this, his comments were answered) |
🎉 Handy links: |
Summary of the Pull Request
Adds a small border with the accent color to indicate a pane is focused
PR Checklist
Detailed Description of the Pull Request / Additional comments
I've removed the simple Grid we were using as the pane separator, and replaced it with a Border that might appear on any side of a pane.
When we add a split, we'll create each child with one of the
Border
flags set (each child with one of a pair of flags). E.g. creating a horizontal split creates one child with theTop
border, and another with theBottom
.Then, if one of those panes is split, it will pass it's border flag to is new children, with the additional flag set. So adding another Vertical split to the above scenario would create a set of panes with either (
Top|Left
,Top|Right
) or (Bottom|Left
,Bottom|Right
) borders set, depending on which pane was split.Validation Steps Performed
Some playing with it, but honestly it needs more for me to be totally confident.