Add support for resizing panes with mouse #16895
Conversation
…rminal-panes-2023
…/fhl/scratchpad-pane
Random thought: Need a visual cue so user is confident that dragging will initiate a resize. |
|
I'm still interested in the QoL/discoverability improvements above - are you going to look into those before this merges? |
... 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 * #16170 * #16171 * #16172 <-- you are here * #16895 Refs #997 Closes #8452
microsoft-github-policy-service
bot
added
Issue-Task
There was a problem hiding this comment.
Frankly, I'm not sure whether this is the best way to go about it, in particular the bubbling of events to figure out which divider gets dragged seems somewhat... off? I feel like iterating through the tree should accomplish the same thing but be much faster, easier to debug and less complex. However, I'm not sure whether I'm in the position to suggest this as I'm somewhat afraid the Pane class may be "lacking" too much in order to support this. Still, it may be worth considering.
Would it though? With bubbling, we start at the leaf that is at least adjacent to the border being resized, and only have to iterate O(log(n)) times upwards till at worst, the root, to find the pane that owns the border. Going top down, we'd have to check basically every pane till we found two on opposite sides of the click (right?) |
|
I believe if we go top-down we can similarly decide whether descending in a sub-tree is necessary by checking if the pointer position falls into the current node's rect. However, I estimate that a single WinRT object instantiation is roughly equivalent to iterating something in the order of dozens of |
…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
|
Sorry we didn't land this for 1.21 - I was looking over Leonard's concerns and I'm wondering if there's a nice middle ground we can strike! |
|
Just sticking this in here because I'm sure I'll lose it in this notebook after the next couple weeks: I had tried to mock out what Leonard's approach would be. I was pretty sure there wasn't a middle approach between the two, but doing it top-down would be entirely different. I'll probably come back to try this after Build |
Summary of the Pull Request
Adds support for resizing panes by dragging with the mouse.
ManipulationDeltais the WinUI event we're using to determine if a pane border was dragged.ManipulationDeltais kinda a wacky event in WinUI, but so is the entirePanestructure we've built. The important things to know about this PR are:Border.ManipulationDeltaevents directly on leaf panes.ManipulationRequestedevent to bubble the request from the leaf pane that was clicked on, to the ancestor pane that actually owns the border on the side of the pane.ManipulationDeltaevent handler on the border itself - the event covers all drags in the entire bounding rect of the border. So we've got to use additional logic to make sure that drags originated on a border, not just on content within the border.Closes #992
other PRs
splitPane,newTab#16914