Yes, you can add things because the interface is only implemented in that plug-in.
The rules are simple not the surface. Older plug-ins that extend the CDT must be able to work with the newer CDT. it’s all driven by Java. The PDE API Baseline tooling helps us check for those things.
Doug.
Good!
However what happens in such cases? I am allowed to add to the API right away because the API is only internally used? Or I still need to proceed with the isSystem stuff. Sorry but I am new to
the playing rules.
Guy
Actually, I notice the ITool interface is marked @noimplement @noextend. That should allow you to add methods to the interface.
Huh? This is just example of interface name. You should use this isSystem() stuff.
IMyInterface2 is when you need to extend IMyInterface but you cannot add methods there because it will break API
On Thu, Mar 5, 2015 at 9:30 AM, Guy Bonneau <guy.bonneau@xxxxxxxxxxxx> wrote:
Good to know. I’ll have a look at the interface
IMyInterface2 to understand how I can use it. Thank for the hint.
Guy
That's is sounds reasonable, you have to check the code of cause to see what it is actually doing.
And btw you don't have to break api to add something, there is standard IMyInterface2 hack for such things
On Wed, Mar 4, 2015 at 6:38 PM, Guy Bonneau <guy.bonneau@xxxxxxxxxxxx> wrote:
Unfortunately yes. Visual Studio does that. And yes it is possible to display the tool but it is really ugly and if you do it is confusing
for a unknowledgeable user. Then until an API change is available I would suggest I might use the current ITool attribute
isSystem to prevent any UI display. The documentation says that if a tool has
isSystem attribute set to true then it shall not be displayable. However I tried to set this attribute to true and the Tool is nonetheless displayed. Thus this seems a bug according to the documentation. Would it be acceptable to disable the display
of a tool if it isSystem attribute is set to true ?
Guy
Does Visual Studio exhibit the same behaviour? Do you really need to hide the tool?
I ask because API changes are not allowed at this point. Maybe for the June 2016 release, but not
this year.
I would add a new boolean attribute : “isDisplayable” to the Tool Element of the Managed Build Definitions. Then add the new
methods isToolDisplayable and setToolDisplayable to the ITool interface and have them implemented into the Tool class.
Guy
On Tue, Mar 3, 2015 at 6:47 PM, Guy Bonneau <guy.bonneau@xxxxxxxxxxxx> wrote:
I need to add the capability to hide a tool of the toolchain from being displayable in the CDT setting UI. This feature is required because
the resource tool of the Visual Studio C++ must be hidden when the manifest file is created/processed internally by the toolchain. Right now the Maestrosoft Visual Studio is using an hack by looking at the name of the tool. If the tool start with __NoDisp__
then the tool is not displayable. However the clean way to do it would be to add an attribute of displayability to the schema of the tool. But I guess this would break the API.
Could you please elaborate on the API breakage you anticipate.
Is this acceptable or may be there is another option to do it.
What would you suggest me?
Guy
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|