Community
Participate
Working Groups
PropertyAndPreferencePage provides a very neat way of letting the user configure project specific settings and giving him the chance to quickly navigate to the corresponding workspace preference. Many non-JDT plug-ins could benefit from this GUI concept. In my own plug-ins, I tend to either write my own version of PropertyAndPreferencePage or cut'n'paste the original version (which is problematic with respect to IP). Therefore, I suggest making PropertyAndPreferencePage available to the public plug-in world by moving it over to JFace.
This would be someting that has to be offered by platform, as this is not Java specific. PropertyAndPreferencePage is typically used to configure project specific settings: The same page can be used as global preference page and as property page on projects. The page adds UI (link on top) to navigate from project specific settings to the workspace settings and vice versa. As an example see all the Java Code Style preference pages. Offering this class in platform would not only simplify the life of clients with project specific options, but also standardize the look of project specific settings pages.
+1
I have to deal with this both in my private plugins and within our product, so it would be nice to have it finally public API.
Martin do you think this class is API ready as is or does it need to be worked on still?
It has some JDT references but can be easily replaced with JDT-neutral code.
This seems look a good chance to stop a lot of code copying
How about marking this bug as "bugday"?
The preference page uses JDT's ProjectSelectionDialog. Is there something similar to this at the Platform level? I don't think so. ContainerSelectionDialog isn't quite the same since it shows a tree representation and lets the user select IFolders. I guess the idea here is to slowly chip away at JDT's code and then perform the move instead of just changing and moving in one fell swoop, correct?
You could use a ElementListSelectionDialog that also has a filter field. Would be useful for big workspaces.
Yes the idea is to make an abstract superclass that the JDT specific code could subclass and put the superclass in the platform
I forgot about this bug when working with PDE's hellish preference pages (bug 168069). I'll see what I can do about the ProjectSelectionDialog (which btw, is used already in 3 places so far... JDT, Debug and PDE API Tools). Should I file a new bug to make ProjectSelectionDialog API also?
Yes, most likely we would like to extend/reuse this project selection dialog. We would then like to customize it: - reduce the scope of projects shown: only some of projects (like "java only" or "custom nature" only) has to be shown for selection - change also the text/checkboxes shown etc. So to do all this things it would be nice to have this dialog as non-internal (API).
Yes please do Chris as we would not want disagreement on one to block another.
I opened bug 239904 against JDT/UI to make ProjectSelectionDialog API.
This should be a good candidate for 3.5 iMHO... can remove some duplicate code out there in the ecosystem (and within the SDK... PDE UI / PDE API Tools)
Chris Please do not set milestones for us as we have not committed anybody to working on this (which is why it is marked help wanted). If you want to work on it we would be happy to review any patches.
... or (Chris) if you want to take ownership of the bug, it's ok to say set the milestone to 3.5 if you are committing to fix it by then.
Sorry, once bug 239904 is done, I will consider looking at this one for 3.5 to complete. I'm used to the PDE workflow where we target bugs for milestones which we hope to complete things by (ie., 3.5) and than a specific milestone (ie., 3.5M2) when we are done with it.
(In reply to comment #12) > Yes, most likely we would like to extend/reuse this project selection dialog. Andrei and others CC'd on this bug, please move all such API requests about the specific ProjectSelectionDialog over to bug 239904 so that the Platform/UI team can capture it over there.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
As there is little progress on this bug I would like to point people that find this bug to the excellent but old (2003) article by Berthold Daum http://www.eclipse.org/articles/Article-Mutatis-mutandis/overlay-pages.html for Eclipse 2.x The code can be used directly in Eclipse 3.x easily with only one API tools warning and the preferences API now hiold more emethods, so retrieval of property of preference can be done with: package com.bdaum.overlayPages; import org.eclipse.core.resources.IProject; import org.eclipse.core.resources.IResource; import org.eclipse.core.runtime.CoreException; import org.eclipse.core.runtime.QualifiedName; import org.eclipse.jface.preference.IPreferenceStore; import com.fold1.eulumdat.tools.EulumdatToolsActivator; import com.fold1.eulumdat.tools.log.Logger; import com.fold1.eulumdat.tools.preferences.ValidatorPreferencePage; public class OverlayUtils { public static String getOverlayedPreferenceValue(IPreferenceStore store, IResource resource, String pageId, String key) { IProject project = resource.getProject(); String value = null; if (useProjectSettings(project, pageId)) { value = getProperty(resource, pageId, key); } if (value != null) return value; return store.getString(key); } private static boolean useProjectSettings(IResource resource, String pageId) { String use = getProperty(resource, pageId, FieldEditorOverlayPage.USEPROJECTSETTINGS); return "true".equals(use); } public static final IPreferenceStore getStoreToUse(IResource p) { IPreferenceStore workspaceStore = EulumdatToolsActivator.getDefault() .getPreferenceStore(); IPreferenceStore store = workspaceStore; String pageID = ValidatorPreferencePage.ID; if (null != p && OverlayUtils.useProjectSettings(p, pageID)) { store = new PropertyStore(p.getProject(), workspaceStore, pageID); } return store; } private static String getProperty(IResource resource, String pageId, String key) { try { return resource .getPersistentProperty(new QualifiedName(pageId, key)); } catch (CoreException e) { Logger.logError(e); } return null; } }
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
This problem has not gone away and a solution exists but is only hard to find. The use case is widespread as every development tool using projects wants to use general prefs and a per project override and be able to implement that easily.
