-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Refactor preference tree layouting #13819
base: master
Are you sure you want to change the base?
Conversation
If I understand this correctly, the additional NLS is only happening for section titles, not the leaf configuration properties themselves? |
I also seems really smelly that the preferences tree knows about preferences for all kinds of Theia extensions (like scm) which may not even be present in a Theia-based product. Are we doing this to simulate the same appearance as VS Code? |
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.
Works as advertised, just some comments on the code.
]; | ||
|
||
@injectable() | ||
export class PreferenceLayoutProvider { |
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 class has not state. Couldn't it be a namespace?
import { nls } from '@theia/core'; | ||
import { injectable } from '@theia/core/shared/inversify'; | ||
|
||
export interface PreferenceLayout { |
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.
Why does PreferenceLayout
not just extend PreferenceLayoutItem
? Or since the children
are optional, isn't the object shape the same anyway?
@@ -94,24 +56,29 @@ export class PreferenceTreeGenerator { | |||
const groups = new Map<string, Preference.CompositeTreeNode>(); | |||
const root = this.createRootNode(); | |||
|
|||
for (const id of this.topLevelCategories.keys()) { | |||
this.getOrCreatePreferencesGroup(id, id, root, groups); | |||
const commonlyUsedLayout = this.layoutProvider.getCommonlyUsedLayout(); |
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.
Why not just make the "commonly used layout" part of the global layout?
@@ -196,6 +196,7 @@ export class TheiaPluginScanner extends AbstractPluginScanner { | |||
for (const c of configurations) { | |||
const config = this.readConfiguration(c, rawPlugin.packagePath); | |||
if (config) { | |||
Object.values(config.properties).forEach(property => property.title = config.title); |
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.
If title
is a well known property, shouldn't it be present in some interface?
export const COMMONLY_USED_LAYOUT = { | ||
id: COMMONLY_USED_SECTION_PREFIX, | ||
label: nls.localizeByDefault('Commonly Used'), | ||
settings: [ |
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.
"Commonly used" is a constant 🤣
What it does
Closes #13802
Supersedes #12929
Adds a new
PreferenceLayoutProvider
service that allows us to translate preference tree items. Also reuses some code from #12929 to correctly display plugin configuration groups in the settings widget.How to test
TypeScript
and notTypescript
andJavascript
.Review checklist
Reminder for reviewers