Is it possible to override the layout of a built-in perspective in my Eclipse-RCP product?
In particular, I wish to add a custom view and change the layout of the Debug perspective. I know how to do it with a custom perspective (IPerspectiveFactory.createInitialLayout()). I'd want that my custom layout to be permanent -survive the "Reset perspective" command.
Create a class that implements IPerspectiveFactory.
Add a perspectives extension to your plugin.xml. Here's one of mine.
<extension point="org.eclipse.ui.perspectives">
<perspective
class="gov.bop.cobolsupport.perspectives.CobolPerspectiveFactory"
icon="icons/ispf_editor.gif"
id="gov.bop.cobolsupport.CobolPerspective"
name="Cobol"/>
</extension>
Your users can change your perspective, and save their changes if they wish. That's built into Eclipse.
However, when you extend your perspective, the Reset Perspective command resets the perspective to how you defined it in your Perspectivefactory class.
Extending a perspective is possible by using the extension point org.eclipse.ui.perspectiveExtensions.
Plug-ins can add their own action sets, views, and various shortcuts
to existing perspectives by contributing to the
org.eclipse.ui.perspectiveExtensions extension point.
To extend the default debug perspective paste the following code in your plugin.xml:
<extension
point="org.eclipse.ui.perspectiveExtensions">
<perspectiveExtension
targetID="org.eclipse.debug.ui.DebugPerspective">
<view
ratio="0.5"
relative="org.eclipse.ui.views.TaskList"
relationship="right"
id="com.jens.customdebug.views.SampleView">
</view>
</perspectiveExtension>
</extension>
You have to define a relative view (in my case the task view named org.eclipse.ui.views.TaskList) and the id of your own view (in my case com.jens.customdebug.views.SampleView)
Source:
To get further information how to use this extension point, take a look here.
For the configuration markup of this extension point you may also take a look at this page.
Related
My question is almost same as this.
The only difference is that I want the custom menu on top, like File -> New -> CustomMenu. CustomMenu should be the first in the New option.
I saw the answer to the linked question. It says
To add to the list of new wizards shown in the main part of the New menu you must use the org.eclipse.ui.perspectiveExtensions extension point to define a newWizardShortcut for your new wizard.
Well, I tried this but I could only get my Wizard in "Other", not in the list visible directly.
Can anyone tell me how to get the custom menu on the top?
The relative part of my plugin.xml is as follows:
<extension
point="org.eclipse.ui.newWizards">
<wizard
class="plugin.com.MyWizard"
id="plugin.com.MyWizard"
name="Inception">
</wizard>
<category
id="plugin.com.myCategory"
name="myCategory"
parentCategory="org.eclipse.pde.PDE">
</category>
</extension>
<extension
point="org.eclipse.ui.perspectiveExtensions">
<perspectiveExtension
targetID="org.eclipse.pde.ui.PDEPerspective">
<newWizardShortcut
id="plugin.com.MyWizard">
</newWizardShortcut>
</perspectiveExtension>
</extension>
"plugin.com" is my plugin project name here. I may not be following the naming conventions but that is not the concern here.
Also, is category needed?
I have a eclipse plug-in, to be more precise I have an action which is triggered via the context menu of any folder. I do also have a Preferences page where I have a checkbox. I want to only display the action if that checkbox is enabled.
My plugin.xml:
<action
class="com.something.MyClass"
enablesFor="1"
id="com.something.MyClass"
label="Label
menubarPath="path/group.smth">
<enablement>
<objectClass
name="org.eclipse.core.resources.IFolder">
</objectClass>
</enablement>
</action>
So. Is there any possibility to display the action based on a specific preference?
Thanks in advance.
I don't think you can do that using (deprecated) actions as the enablement expression is rather limited.
You can also use the org.eclipse.ui.menus extension point to contribute to context menus. In this case you can use the test element to invoke a 'property tester' defined using the org.eclipse.core.expressions.propertyTesters extension point. I don't think there are any predefined property testers for preferences but testers are not difficult to write.
I've implemented a custom toolbar in my RCP application. I'm also using the org.eclipse.ui.menus extension to contribute commands to the custom toolbar.
<extension
point="org.eclipse.ui.menus">
<menuContribution
locationURI="toolbar:com.my.custom.toolbar.identifier.toolbar">
<command
commandId="com.my.command.id"
icon="icons/my_icon.png"
style="toggle"
tooltip="My Toggle Tooltip">
</command>
</menuContribution>
</extension>
I've written the code that finds these IConfigurationElements and turns them into CommandContributionItems which I use to add them to my custom toolbar.
I have some toolbar items that are of type toggle, and I need these to update their UI using the IElementUpdater interface that the command's handler implements.
I also contribute this command to a standard Eclipse menu... like "toolbar:org.eclipse.ui.main.toolbar" and its toggle state is updated via the IElementUpdater when appropriate.
I'm probably missing something in my custom toolbar that hooks it up to the IElementUpdater, but I have no idea where to start looking to make this work.
I've used the IElementUpdater, but not for cases to update the toggle state, as this should be done by the connection to the respective Command. There exist, however, some problems in Eclipse 4 which I have already started to point out in a blog article.
What Eclipse variant are you using? 3.x or 4.x? There exists a bug in 4.x concerning the synchronization of contributions and their command states.
I'm developing tow eclipse plugin, I have the next problem:
I have two perspective that manages the same files. I would like to make an association between file extension - editor - perspective.
I mean if I open the file extension .XXX in perspective 1 it uses the editor A, but if I open the same file extension .XXX in perspective 2, it uses the editor B.
is it possible? Since now, I used the launcher but now I need more differentiation.
Thanks.
(Sorry, this is one of those "don't do that!" non-answers. :))
As mentioned in the comments, I'd recommend against opening a different editor depending on the current perspective. I think that goes against the expectations of the user, and has some unintuitive consequences, e.g. when I create my own perspectives.
I'd recommend going the path of Eclipse' XML/Plug-in manifest editors, for example. Tabs at the bottom allow the user to choose between the different views, independent of any perspective choice or configuration.
While I agree that this seems a little strange to have the default editor be different for the same file based on the open perspective, here is how you could do it.
Create two new Content Type extensions
Register your first editor as default editor for 1st new Content Type
Register your 2nd editor as the default editor for the 2nd new Content Type
For each content type, you have a 'content type describer'. In these describer classes, have it check the active workbench page for the current perspective ID and if it matches the expected value, then VALID, if perspective id doesn't match, return INVALID.
For both editors you need to associate those editors with a content-type instead of a file-extension or filename
Now only one content type will match at a time depending on which perspective is open. Make sure that one of the content types is the 'default' so that it will always match if the user has some other perspective open.
Update #1 added some examples
There are some online tutorials for this. But here is some example code to make it easier to see what work is required. Here is how you declare your content types (you would need two of them)
<plugin>
<extension
point="org.eclipse.core.contenttype.contentTypes">
<content-type
base-type="org.eclipse.core.runtime.xml"
describer="com.liferay.ide.core.FirstContentTypeDescriber"
id="com.liferay.ide.core.contentType1"
name="First Content Type"
priority="normal">
</content-type>
</extension>
</plugin>
Then in the Describer class you would do your matching logic. Then in the editor extension point you reference a content type instead of a file-name or extension like this:
<extension
point="org.eclipse.ui.editors">
<editor
class="com.liferay.ide.ui.FirstEditor"
default="false"
id="com.liferay.ide.ui.editor1"
name="My First Editor">
<contentTypeBinding
contentTypeId="com.liferay.ide.core.firstContentType">
</contentTypeBinding>
</editor>
</extension>
I would recommend to rethink your approach, and take some cues from WindowBuilder: have one editor associated with the file type which opens a tabbed editor; if a second plugin is added, have it create a separate tab on the same editor.
Other option may be programmatically change file type association with Java code shown in
Eclipse RCP: programmatically associate file type with Editor?
Then there is only a question how to execute that code on perspective change event.
The Eclipse RCP command framework is intended to replace the action framework as the mechanism for allowing plugins to contribute UI commands to the workbench. As well as defining new commands, plugins may provide handlers for default RCP commands such as "org.eclipse.ui.file.save" (full list of default commands here: http://svn2.assembla.com/svn/eclipsecommands/trunk/EclipseCommands/contents/article.html).
Using default commands brings the advantages of standard key bindings and icons, and in some cases the ability to use the built-in Eclipse actions.
For example the default editor save command can be added to the File menu with the following snippet in plugin.xml:
<extension point="org.eclipse.ui.menus">
<menuContribution locationURI="menu:file">
<command commandId="org.eclipse.ui.file.save"
style="push">
</command>
</menuContribution>
</extension>
A handler can then be defined for this command by adding a handler definition in the handlers extension point in plugin.xml. If, however, the editors being contributed implement IEditorPart, it should be possible to simply use the built-in Eclipse save action (which takes care of tracking the active editor and dirty property updates) instead of defining a new handler.
What further steps are necessary to use the built-in save action?
It is necessary to call ActionBarAdvisor.register() to make the save action available. For example:
public class MyActionBarAdvisor extends ActionBarAdvisor {
public MyActionBarAdvisor(IActionBarConfigurer configurer) {
super(configurer);
}
protected void makeActions(final IWorkbenchWindow window) {
register(ActionFactory.SAVE.create(window));
}
}
Given the addition to plugin.xml in the question, the built-in save handler will now be invoked for any active editor.