Community
Participate
Working Groups
For our lab with workspaces containing few hundreds projects we want per default enable working sets mode in package explorer. Unfortunately default value is "projects as root" so all our developers need manually change settings every time they create a workspace. We tried to automate it but faced the issue that we can't customize package explorer initial appearance because it uses dialog_settings.xml to read and persist the state, and NOT the preference store. So I cannot provide default settings to it neither using "preferenceCustomization" extension for products nor "-pluginCustomization" for command line arguments, nor Oomph (see discussion at https://www.eclipse.org/forums/index.php/t/1083926/). This is not nice, but I have a patch :-)
New Gerrit change created: https://git.eclipse.org/r/90192
(In reply to Eclipse Genie from comment #1) > New Gerrit change created: https://git.eclipse.org/r/90192 To test, eclipse need to be started with the program argument pointing to the file below: -pluginCustomization path/to/plugin_customization.ini ################## # plugin_customization.ini ################## org.eclipse.jdt.ui/org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart.rootMode=2 org.eclipse.jdt.ui/org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart.layout=2 org.eclipse.jdt.ui/org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart.group_libraries=true org.eclipse.jdt.ui/org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart.linkWithEditor=true ################## As a visible result, package explorer will show "other projects" node and "link with editor" will be enabled.
Noopur, do you have time for a review?
Quote from Dani's reply on Gerrit: > I agree that we currently lack the feature to provide defaults for new workspaces, > but that applies to every dialog setting. > Instead of making a point fix we need to find a way that dialog settings can be initialized. > One way could be to allow adding them to the pluginCustomization.ini with a new format, > e.g. by using a @ prefix for dialog settings: > @org.eclipse.jdt.ui/org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart.rootMode=1 > Or we introduce a new file, e.g. pluginSettingsCustomization.ini. > Or we allow to provide a pluginsSettings folder that holds the info (similar to what is in .plugins). > Or... > On a quick look org.eclipse.ui.plugin.AbstractUIPlugin.loadDialogSettings() might be > a good location to read the initial state, but I didn't investigate deeply. I will check now possible options.
(In reply to Andrey Loskutov from comment #4) > Quote from Dani's reply on Gerrit: I've checked now possible options, see comments below. The main issue with dialog settings (org.eclipse.jface.dialogs.DialogSettings) is that they are using xml format, and that this has always plugin specific structure, so one can't translate to/from this format without knowledge of the specific plugin preferences structure. > > One way could be to allow adding them to the pluginCustomization.ini with a new format, > > e.g. by using a @ prefix for dialog settings: > > @org.eclipse.jdt.ui/org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart.rootMode=1 The contra arguments: - new format specification - extra code to translate this format into xml format of dialog settings - this must be done in every plugin (!) - extra effort for users to convert existing dialog_settings.xml into new format > > Or we introduce a new file, e.g. pluginSettingsCustomization.ini. In the form of an *.ini file same issues as with the point above. In the form of an *.xml file: The contra arguments: - similar to the DefaultPreferences.initializeCustomizations() it should support command line and product customization, this is a lot more effort as it could be. - one file to merge other xml files could be error prone, especially if they all start with same "Workbench" root element, so easy to break. - assuming there are more then one file merged, it requires to read all the data every time dialog settings for a single plugin are requested. The pro arguments: - one file is easier to supply for deployment. > > Or we allow to provide a pluginsSettings folder that holds the info (similar to what is in .plugins). This is more appealing, because then one could just copy/paste some of the .plugins/*/dialog_settings.xml files to the "customization" area. > > Or... > > On a quick look org.eclipse.ui.plugin.AbstractUIPlugin.loadDialogSettings() might be > > a good location to read the initial state, but I didn't investigate deeply. Yes, this will probably be the place for the patch. > I will check now possible options. With the options discussed above I believe I will work in this direction: 1) Define a new *preference* key for org.eclipse.ui.workbench to define the root folder path with *initial* dialog_settings.xml files for bundles. To customize a bundle "ABC" dialog settings, this folder should contain ABC/dialog_settings.xml file in the well known format. By default the preference is not set. 2) The preference above can be specified via existing product customization. 3) If the bundle requests AbstractUIPlugin.loadDialogSettings(), the default dialog settings file for the bundle does not exist yet and the preference is specified, bundle will get a DialogSettings instance loaded from the path based on specified preference. 4) Once the dialog settings for a bundle ABC *saved* by Eclipse to the default location (.metadata/.plugins/ABC/dialog_settings.xml), the custom values are not read and not applied anymore.
New Gerrit change created: https://git.eclipse.org/r/111434
New Gerrit change created: https://git.eclipse.org/r/111433
Gerrit change https://git.eclipse.org/r/111433 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=6f5262df218dd3d0e01f8908d28394fbcd1ecd97
This is a great proposal! Thanks Andrey! Lack of customization of dialog settings is probably one reason why so many "hidden gems" are not shown in downstream RCP (including EPP). Your proposal is a good way to enable those without changing Platform's code. I've got a question about the taken approach (a folder containing the dialog settings): how is it likely to work with .project build compared to pluginCustomization.ini? With your proposal, can it be as easy to include dialog settings than it is to include preferences in a custom product?
(In reply to Mickael Istria from comment #9) > I've got a question about the taken approach (a folder containing the dialog > settings): how is it likely to work with .project build compared to > pluginCustomization.ini? With your proposal, can it be as easy to include > dialog settings than it is to include preferences in a custom product? I don't get the point about .project build. What is it? The problem I'm trying to solve is that customization via pluginCustomization.ini does not affect DialogSettings yet, and the support for those can be added by providing two things: 1) plugin_customization.ini with an entry: org.eclipse.ui/default_dialog_settings_rootUrl=http://my.server/project/templates/dialog_settings_root or org.eclipse.ui/default_dialog_settings_rootUrl=/etc/mycompany/project/templates/dialog_settings_root or org.eclipse.ui/default_dialog_settings_rootUrl=platform:/mycompany.bundle/dialog_settings_root 2) dialog_settings_root in the location specified above with similar structure: dialog_settings_root/ -- mycompany.bundle/dialog_settings.xml -- org.eclipse.jdt.ui/dialog_settings.xml -- whatever_else/dialog_settings.xml What is not *yet* implemented is the support of bundle / installation relative urls, like platform:/mycompany.bundle/dialog_settings_root, and I have no tests yet. So for the product, the product owner provider would need to provide a bundle contained dedicated directory with all the customized dialog settings and specify this location in the plugin_customization.ini.
(In reply to Andrey Loskutov from comment #10) > I don't get the point about .project build. What is it? Sorry, I meant *.product build. > the support for those can be added by providing two things: > [...] > org.eclipse.ui/default_dialog_settings_rootUrl=platform:/mycompany.bundle/ > dialog_settings_root > [...] > What is not *yet* implemented is the support of bundle / installation > relative urls, like platform:/mycompany.bundle/dialog_settings_root, and I > have no tests yet. > So for the product, the product owner provider would need to provide a > bundle contained dedicated directory with all the customized dialog settings > and specify this location in the plugin_customization.ini. Ok, that sounds to cover my concerns perfectly. Thanks!
Gerrit change https://git.eclipse.org/r/111434 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=6856ddf4c185c360636e6d617d75fdfa096ef291
New Gerrit change created: https://git.eclipse.org/r/111867
New Gerrit change created: https://git.eclipse.org/r/111875
Created attachment 271553 [details] preference customization help update (In reply to Eclipse Genie from comment #14) > New Gerrit change created: https://git.eclipse.org/r/111875 Updated help for product customization, see attachment how it looks like now.
Gerrit change https://git.eclipse.org/r/111867 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=77f8c40185e2ea10516b610c7651b7ce0a1571cd
Gerrit change https://git.eclipse.org/r/111875 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=e6286ac999434f6814781387043133c0e587f45b
Should be done now.
