Feature/part resize: Add key bindings to resize focused view#22861
Feature/part resize: Add key bindings to resize focused view#22861bpasero merged 46 commits intomicrosoft:masterfrom
Conversation
Bringing fork up to date
update fork
update fork
|
@cleidigh, It will cover your contributions to all Microsoft-managed open source projects. |
|
@cleidigh, thanks for signing the contribution license agreement. We will now validate the agreement and then the pull request. |
|
my apologies and get hub ignorance |
|
okay I think I have this correct now |
| } | ||
| } | ||
|
|
||
| export class ContractViewAction extends Action { |
There was a problem hiding this comment.
It seems to me that a lot of the code in ContractViewAction looks the same with ExpandViewAction except for the increment value which could be abstracted to a BaseResizeViewAction and an argument INCREMENT_DIRECTION (probably 1 or -1) could be passed down.
There was a problem hiding this comment.
@misoguy
Agree, I've looked at your code a lot as well as comments. I was anxious
to get some initial feedback before doing more re- factoring.
I also think moving the resize actions into actions.ts like your code
is the newer approach. When I started I modeled my code after the toggleSidebarVisibility.ts
not sure why these several toggle functions are in separate files, anybody?
Hope you give it a try, seems like we have some common interests...
|
@bpasero |
|
@bpasero note : I made the choice to favor the focused part and increase the editor size, shrinking both |
| setGroupOrientation(orientation: GroupOrientation): void; | ||
| getGroupOrientation(): GroupOrientation; | ||
|
|
||
| requestActiveGroupSizeChange(groupSizeChange: number): boolean; |
There was a problem hiding this comment.
Can we maybe call this similar to the other one resizePart in partService, e.g. resizeGroup and you pass in the position of the group to resize?
There was a problem hiding this comment.
done
was never wedded to the name ;-)
| case Parts.SIDEBAR_PART: | ||
| case Parts.PANEL_PART: | ||
| case Parts.EDITOR_PART: | ||
| this.workbenchLayout.setPartSizeChange(part, sizeChange); |
There was a problem hiding this comment.
setPartSizeChange => resizePart ?
| return true; | ||
| } | ||
|
|
||
| protected boundSiloSize(siloPosition: Position, sizeChangePx: number): number { |
| return newSiloSize; | ||
| } | ||
|
|
||
| protected distributeRemainingSilosSize(remPosition1: Position, remPosition2: Position, availableSize: number): void { |
|
F2 helps a lot ! |
|
@cleidigh excellent job 👍 |
|
@bpasero fyi - working on this project is very good for me. since I'm not able to work a regular job I'm very interested in becoming regular contributor. I'm not fast but I do have a decent amount of time In the meantime I'm more than happy to help out with issues/bugs either for the March deadline This participation and focused goals are a great thing for me... cheers Christopher |
|
@cleidigh yes, I added a debug configuration that allows to debug both main and renderer process from within VS Code (provided you installed the Chrome Debug Adapter extension). Thanks for willing to help out more, going after the help wanted bugs is a good start. Often it helps to first quickly ask if it is OK to start working on a particular issue, just to confirm that we have cycles to review a potential contribution in that area and it makes sense via PR. As for priorities, we typically just go by number of votes on an issue to decide if something is important or not :) |
{ |
|
Weird, it really works for me out of the box. Are you using our insiders build or stable? |
|
@bpasero |
|
@cleidigh are you on windows? |
|
sorry made the trek downstairs and was out of pocket Unfortunately I can only directly contribute and test Windows VSC Unrelated question - what version of typescript should be used for compiling OSS |
|
@cleidigh Great job! I have been following this PR but didn't really get the time to review it deeply till now :( It looks great 👍 |
|
@misoguy I think your navigation and the view size keyboard features will be a fine pair coming up together right now I'm looking at what next to attack, how about you? |
See issue #22645
Part Resize Feature Notes:
Proposed feature to address issue #22645:
Keyboard bindings to expand or contract the main axis of the focused view
Two key bindings expand view, contract view
key bindings based on part focus (potential reduction of key collisions)
expansion or contraction follow main axis of part and orientation
eg sidebar has focus, expand moves border right if on left
or left if sidebar on right
eg panel has focus expand moves border up...
editor focus: expand moves right border right (h. layout)
top up (v. layout) or opposite if single editor
approach still works if a new part eg secondary sidebar
is added in the future
Possible (mnemonic) key bindings: (probably none assigned by default)
[expand part]: ctrl+alt+shift+ >
[contract part]: ctrl+alt+shift+ <
[expand part]: ctrl+alt+shift+ x
[contract part]: ctrl+alt+shift+ c
[expand part]: ctrl+alt+shift+ )
[contract part]: ctrl+alt+shift+ (
[restore default part size]: ctrl+alt+shift+ d
[restore default part size]: ctrl+alt+shift+ r
Potential Future Issues:
A part with no "primary axis" (expanding contract ambiguous)
Main file work:
Main file, follows toggleSideBarVisibility.ts design approach
.\src\vs\workbench\browser\actions\resizePart.ts
Workbench Support Functions
.\src\vs\workbench\electron-browser\workbench.ts
Layout Support Functions
.\src\vs\workbench\browser\layout.ts
The prototype implementation sports resize
of the sidebar, the panel and one editor.
After looking more into the code base as well
as the navigation contribution by @misoguy
I think some files need to be moved around.
my first implementation was based on toggleSideBarVisibility
but I think the more recent code add
the commands to actions.ts
The next step is to flush out support for the editors
where more than one is visible. and re- factor
per suggestion input.
Thanks for considering...