-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Open editors widget in navigator #9284
Open editors widget in navigator #9284
Conversation
84f046f
to
71be806
Compare
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.
Looking very nice. I have a few comments on the code
packages/navigator/src/browser/open-editors-widget/navigator-open-editors-decorator-service.ts
Outdated
Show resolved
Hide resolved
packages/navigator/src/browser/open-editors-widget/navigator-open-editors-decorator-service.ts
Outdated
Show resolved
Hide resolved
packages/navigator/src/browser/open-editors-widget/navigator-open-editors-file-decorator.ts
Outdated
Show resolved
Hide resolved
packages/navigator/src/browser/open-editors-widget/navigator-open-editors-tree-model.ts
Outdated
Show resolved
Hide resolved
packages/navigator/src/browser/open-editors-widget/navigator-open-editors-tree-model.ts
Outdated
Show resolved
Hide resolved
packages/navigator/src/browser/open-editors-widget/navigator-open-editors-widget.tsx
Show resolved
Hide resolved
packages/navigator/src/browser/open-editors-widget/navigator-open-editors-widget.tsx
Outdated
Show resolved
Hide resolved
packages/navigator/src/browser/open-editors-widget/navigator-open-editors-file-decorator.ts
Outdated
Show resolved
Hide resolved
71be806
to
c543684
Compare
c543684
to
e4cc5d3
Compare
5826303
to
c8ca0ba
Compare
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 did a high level pass of the pull-request, the main concern was the new coupling introduced by the changes.
I found an issue with the current styling, for different icon-themes (such as the seti) we encounter some problems:
open-editors-ui.mp4
c8ca0ba
to
e7828b9
Compare
I've updated the styling to satisfy changing the file icon themes. There is a bit of odd behavior when switching to Seti in particular as the indentation is not consistent with other themes (you can see this on the navigator tree as well), but does not cause any overlap with the decorator. Let me know if this is sufficient. Thanks! |
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 seems to be working well for me, and the dependencies on the editor
and editor-preview
packages have been removed. One small hiccup is the size of widget - it doesn't seem to be adhering to the weight ratio specified - and the handling of multiple instances of the same editor widget.
e7828b9
to
093b36e
Compare
Thanks for taking another look @colin-grant-work. I've addressed your feedback, and also left a comment in the code regarding the quoted issue above. |
093b36e
to
d83370a
Compare
@colin-grant-work I've pushed an update to this PR that adds grouping functionality to the OpenEditors widget based on my best attempt at reconciling VSCode's OpenEditorsWidget behavior with Theia's ability to dock widgets anywhere. I've also added the corresponding toolbar icons to the grouping nodes that allow for "Close Group" and "Save all in group", and added listeners so that the tree is reordered when tabs are rearranged. Please give this a try and let me know if you have any suggestions |
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.
Looking pretty good. The behavior is pretty much spot on, just some minor comments about small display items and some stuff in the code.
packages/navigator/src/browser/open-editors-widget/navigator-open-editors-widget.tsx
Outdated
Show resolved
Hide resolved
packages/navigator/src/browser/open-editors-widget/navigator-open-editors-decorator-service.ts
Show resolved
Hide resolved
packages/editor-preview/src/browser/editor-preview-tree-decorator.ts
Outdated
Show resolved
Hide resolved
packages/editor-preview/src/browser/editor-preview-tree-decorator.ts
Outdated
Show resolved
Hide resolved
packages/navigator/src/browser/open-editors-widget/navigator-open-editors-tree-model.ts
Outdated
Show resolved
Hide resolved
packages/navigator/src/browser/open-editors-widget/navigator-open-editors-tree-model.ts
Outdated
Show resolved
Hide resolved
packages/navigator/src/browser/open-editors-widget/navigator-open-editors-tree-model.ts
Outdated
Show resolved
Hide resolved
packages/navigator/src/browser/open-editors-widget/navigator-open-editors-tree-model.ts
Outdated
Show resolved
Hide resolved
packages/editor-preview/src/browser/editor-preview-tree-decorator.ts
Outdated
Show resolved
Hide resolved
packages/editor-preview/src/browser/editor-preview-tree-decorator.ts
Outdated
Show resolved
Hide resolved
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 working well to me, and the code looks reasonable. My greatest desideratum would be to follow VSCode in resizing the tree to only ever take up the amount of space it needs, but that can be tackled in a follow up PR.
Hey @vince-fugnitto, I've made some considerable updates to this MR, would you be able to give it a test whenever you have free time?
Regarding @colin-grant-work's comment above about the automatic resizing of a ViewContainer part, do you (@vince-fugnitto) have any suggestions on how to do that with Phosphor's built in methods? I couldn't seem to find a convenient way to do this. Thanks! |
@kenneth-marut-work do you mind rebasing, and I'd be happy to take a look 👍 As for the size of the view, it doesn't need to be part of this pull-request, I believe all tree-view parts suffer from the same bug where the size is not controllable. |
223eb65
to
07d1412
Compare
packages/editor-preview/package.json
Outdated
"@theia/editor": "1.15.0", | ||
"@theia/navigator": "1.15.0", | ||
"@theia/workspace": "1.15.0" |
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.
@kenneth-marut-work @colin-grant-work is the new coupling necessary?
@theia/editor
only uses core
, why does editor-preview
need the coupling?
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.
The two of us discussed this since the tree decorator (which is responsible for italicizing the filename when in preview mode, and also adding workspace/tail decorations) was decided to be moved from the navigator -> editor preview package. This allows the decorator to have access to the editor-preview's built-in checks for preview state, and emitters for on-preview-pinned.
It has the sideeffect of needing to depend on the navigator package (to access the decorator service) as well as the workspace service. The SCM and markers package have a similar dependency set up.
packages/navigator/src/browser/open-editors-widget/navigator-open-editors-commands.ts
Outdated
Show resolved
Hide resolved
font-size: var(--theia-ui-font-size0); | ||
} | ||
|
||
.open-editors-node-row .open-editors-prefix-icon-container { |
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 believe we should prefix the new stylings with theia-open-editors-widget
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.
👌
const widgets = openEditorsWidget.getEditorWidgetsByGroup(id); | ||
widgets?.forEach(widget => widget.close()); | ||
}, | ||
isVisible: () => false |
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.
To confirm, the following is set to false to hide it from the command palette
?
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.
So these two commands I've decided to hide from the command palette since they are essentially toolbar icon commands. Their implementation is slightly different from the way VSCode would implement them as they accept either an ApplicationShell.Area
or TabBar<Widget>
command as their argument.
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 thought a simpler way would be to not give it a label
so it does not show up in the command palette?
Although, I'm fine with you explicitly setting it to false
as well.
|
||
export namespace OpenEditorsCommands { | ||
export const CLOSE_ALL_TABS_FROM_TOOLBAR: Command = { | ||
id: 'navigator.close.all.editors', |
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.
For the new commands in the file, should we align their ids
with that of vscode so the plugin-system can directly reference them without the mapping?
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.
See note above, I've kept these commands separate from the plugin commands since their implementation is slightly different in both arguments and behavior. I've added added an additional command with VSCode's ID to the plugin-vscode-commands-contribution
for workbench.files.saveAllInGroup
which uses a very similar implementation as the existing workbench.action.closeEditorsInGroup
and ensured that the two now have labels
so that they can be accessed from the command palette. It's a bit tricky to figure out exactly where some of these things should live, but this was my best attempt at separating responsibilities. I've also added an appropriate utility in the application shell for saving editors which I am using in the execute
of the toolbar commands.
Let me know if you have suggestions, thanks!
62ad33a
to
98a21a7
Compare
@@ -105,7 +113,8 @@ export namespace FileNavigatorCommands { | |||
label: 'Focus on Files Explorer' | |||
}; | |||
export const COPY_RELATIVE_FILE_PATH: Command = { | |||
id: 'navigator.copyRelativeFilePath' | |||
id: 'navigator.copyRelativeFilePath', | |||
label: 'Copy Relative Path' |
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 we align?
label: 'Copy Relative Path' | |
label: 'Copy Relative Path of Active File' |
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.
In VSCode, when I right click on files and look for this command I see "Copy Relative Path". I do see two labels for this command in the VSCode repo, but I'm not sure I understand how VSCode represents their commands to make the call:
isVisible: widget => this.withOpenEditorsWidget(widget, () => !!this.editorWidgets.length) | ||
}); | ||
registry.registerCommand(OpenEditorsCommands.SAVE_ALL_TABS_FROM_TOOLBAR, { | ||
execute: widget => this.withOpenEditorsWidget(widget, () => this.commandService.executeCommand(CommonCommands.SAVE_ALL.id)), |
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.
No need for the CommandService
injection:
execute: widget => this.withOpenEditorsWidget(widget, () => this.commandService.executeCommand(CommonCommands.SAVE_ALL.id)), | |
execute: widget => this.withOpenEditorsWidget(widget, () => registry.executeCommand(CommonCommands.SAVE_ALL.id)), |
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.
Good to know, I've fixed this 👍
const widgets = openEditorsWidget.getEditorWidgetsByGroup(id); | ||
widgets?.forEach(widget => widget.close()); | ||
}, | ||
isVisible: () => false |
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 thought a simpler way would be to not give it a label
so it does not show up in the command palette?
Although, I'm fine with you explicitly setting it to false
as well.
@@ -412,7 +463,7 @@ export class FileNavigatorContribution extends AbstractViewContribution<FileNavi | |||
}); | |||
registry.registerMenuAction(NavigatorContextMenu.CLIPBOARD, { | |||
commandId: FileNavigatorCommands.COPY_RELATIVE_FILE_PATH.id, | |||
label: 'Copy Relative Path', | |||
label: FileNavigatorCommands.COPY_RELATIVE_FILE_PATH.label, |
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 believe it can be omitted if the label
is the same as the command
definition.
The same is true for other occurences.
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.
Also good to know, I've removed the labels from the menu items
export const OpenEditorsTreeDecorator = Symbol('OpenEditorsTreeDecorator'); | ||
|
||
@injectable() | ||
export class OpenEditorsTreeDecoratorService extends AbstractTreeDecoratorService { |
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 a bit confused as to this file.
- why does it live in
navigator
,navigator
should not know aboutproblems
. - I believe we want a
open-editor
decorator service whichproblems
contributes to, like the following inproblems/
.
bind(NavigatorTreeDecorator).toService(ProblemDecorator);
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've moved the suffix decorations that add the workspace * path/to/file
to the problem decorator and added a conditional check if the decorated node belongs to the OpenEditorsWidget. This way the suffix decorations are only applied to open-editor nodes and not the navigator nodes. Moving that logic allows this file to be much less complex :)
Thanks for the suggestions and help with this issue!
The only downside is that I cannot find a way to aggregate the italicization provided by the editor-preview-tree-decorator
into the suffix decoration, which causes a preview widget node to not have italicization on its suffix. I don't think this is really a problem and the cleaner code outweighs the minor UI flaw. This could also be addressed in a separate PR
98a21a7
to
48593f3
Compare
@vince-fugnitto thanks for the helpful suggestions. I believe I have addressed your comments except for the minor issue with the Moving the suffix-decorations into the problem-decorator seemed to work quite well and greatly simplified the strange logic I was doing in the open-editors-decorator service to retroactively apply coloring, so now that file is much more straightforward. |
@vince-fugnitto thanks for pointing out the path display issue. I've fixed this and also added a case for when a file is opened outside a workspace (in that case we display the full path). This works for the case of no-workspace-open case as well: Single root with nested files and file outside workspace |
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.
The changes work well for me, and the code is also clean 👍
I attempted to review multiple use-cases:
- confirmed it works in a single-root workspace
- confirmed it works in a multi-root workspace
- confirmed the relative paths are displayed for nested files
- confirmed the root name and relative paths are displayed for files in a multi-root workspace
- confirmed the problem decorations work for the open editors
- confirmed that scm decorations work for the open editors
- confirmed that dirty decorations work for the open editors
- confirmed that the close-all and save-all toolbar items work
- confirmed that the context-menu works for open editors
- confirmed that switching editors in the view works
- confirmed that it properly represents editor groups in the layout
The changes are already substantial, if there are improvements we can make them in subsequent pull-requests 👍
Thanks @vince-fugnitto, I'll go ahead and squash and otherwise will merge tomorrow if there are no objections |
Signed-off-by: Kenneth Marut <[email protected]>
9e56780
to
a0472f6
Compare
What it does
Fixes: #8936
Adds 'Opened Editors' panel into the Navigator's layout, hidden by default
Includes the following functionality:
Known Issues/Areas for Improvement:
layoutModified
listener behaves differently from the main/bottom dock panelHow to test
Set Up:
Widget Tracking:
Decorations:
Actions:
Review checklist
Reminder for reviewers