Community
Participate
Working Groups
CDT does not appear to provide an extension point by which I can subclass the project property panes. Ideally I would like "org.eclipse.cdt.managedbuilder.core.ManagedBuildInfo" to provide a "panelClass=" field. We wanted to provide extra functionality for these panels in CDT3.0 and submit these enhancements for future versions of CDT CDT uses the class field in org.eclipse.ui.propertyPages and should provide this functionality on
(In reply to comment #0) > CDT does not appear to provide an extension point by which I can subclass the > project property panes. > > Ideally I would like "org.eclipse.cdt.managedbuilder.core.ManagedBuildInfo" to > provide a "panelClass=" field. > > We wanted to provide extra functionality for these panels in CDT3.0 and submit > these enhancements for future versions of CDT > > CDT uses the class field in org.eclipse.ui.propertyPages and should provide this > functionality on Sound cool. Any folks from the MBS can follow on this. Redirect to cdt-build MBS folks
A friend pointed me at the following document: http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/cdt-home/developer/ featurespec/3.0/MBS_3_0_Proposal.html?cvsroot=Tools_Project which says "Additional Property Page Enhancements: (2) The tool integrator can override the standard property page display and provide a custom page" This sounds like just the thing! In my view an ability to subclass, with appropriate protected (or public) functions, would be better than the various e.g. class-to-sort-dependencies function points that are springing up. Thanks
I think that we could enhance the managed builder ui by allowing tool-integrators to specify their own custom tabs that could be added to tabs currently displayed in build property page. We could allow tool integrators to specify one or more “propertyTab” elements as children of the toolChain element. The propertyTab could have the following attributes: class – the name of the class that implements the org.eclipse.cdt.ui.dialogs.ICOptionPage interface resourceType – contains either “PROJECT” or ”FILE” representing that the tab is to be displayed for the project property page or for the resource property page respectively. Default is “PROJECT” contentTypes – comma-separated list of the content type ids for which the tab is to be displayed. If not specified, tab is displayed for all project resources. Ignored if the resourceType is “PROJECT” nameFilter – regular expression representing the file name filter If not specified, tab is displayed for all project resources. Ignored if the resourceType is “PROJECT” or if the "contentTypes" is specified What do others think? Neil, will this solve your needs? Thanks, Mikhail
..one small correction to the above is that the "class" attribute should contain the name of the class that implements the org.eclipse.cdt.managedbuilder.ui.IBuildOptionPage interface, that would be defined as follows: public interface IBuildOptionPage extends ICOptionPage{ /** * Sets the "dirty" state */ public void setDirty(boolean b); /** * Returns the "dirty" state */ public boolean isDirty(); /** * answers whether the page contains default values */ public boolean containsDefaults(); /** * tells the tab to update its values. * Called e.g. when the selected configuration is changed */ public void updateValues(); } The tab implementer will need to implement this interface in order to handle the configuration selection.
Hi Mikhail, As I understand it you're suggesting the ability to add new tabs alongside "Tool Settings", "Build Settings", etc.? This sounds like a fine idea, but doesn't really solve my problem. I was looking for the ability to subclass the "Tool Settings" tab (I'll try to explain why...) Our product spec asks for certain things: + Dynamically disabled options (fixed for CDT3.0.1) + "Browse" button for string options (currently only for stringList) + Editable equivalent command line Some of this is being implemented in future versions of CDT and we're happy to help with this effort. Unfortunately our spec also requires compatibility with CDT3.0 Our hope was to make the changes in a sub-class, then push these back up into the parent for future CDT releases. Obviously 3.0 has now released and it's too late for us, but this situation might come up again Thanks, Neil
As an FYI, CDT 3.0 added support to specify browsing on string options as well.
Hmmm... I'm not going to accept this just yet as I'm not sure if the way this is proposed is the way to go. I need to think about it more. Can this be gotten around with capabilities?
