How to add plugin with perspective and view to my own RCP app - eclipse

I have a very basic RCP application (e3.7.1) with only one (Hello World) plugin. For reasons of code control I want to develop all perspectives and views in separate plugins. I have now set up one plugin with a perspective and a view. How do I get them into my main RCP plugin, e.g., where do I configure which extensions/extension points? I want the perspective and view to appear in the Perspective Menu as well.

How did you create you RCP application, did you create a .product definition ? did you create a feature ?
Basically Eclipse is based around plugins (OSGI bundles) and you can create view and perspective in different plugins. As long as your plugin is part of you RCP .product definition either as a plain plugin or into a feature definition, you should be able to export your RCP application with all the desired plugins.
If you are just talking about how to run them from Eclipse, you need to edit the run configuration and add all the plugin you need to activate in the Eclipse Application run configuration. This configuration is the on you use to launch the RCP application.

The set of view and perspective shortcuts in those menus is specific to current perspective.
If the perspective on which you want to make those shortcuts available is your own, then you need to call IPageLayout methods addShowViewShortcut() and addPerspectiveShortcut() from your IPerspectiveFactory. If you want to make those shortcuts available on someone else's perspective then use org.eclipse.ui.perspectiveExtensions extension point.

Related

Reuse standard menus in Eclipse RCP4 application

I want to reuse standard menus from the Eclipse IDE in my RCP4 application (e.g. Windows->Preferences).
In Eclipse RCP3 applications you simply have to add a menuContribution to the plugin.xml to achieve this.
I tried the same for my RCP4 application but without success. Is there another way to add standard menus to a RCP4 application?
For a pure e4 application which is not using the 3.x compatibility layer you have to construct all the menus and dialogs yourself.
For preferences you can use the JFace org.eclipse.jface.preference.PreferenceDialog which is a simpler version of the normal preferences dialog, but you don't get the preference page extension point (or any existing pages) so you have to craft all that yourself.

Eclipse Perspective Development - Extend CDT Perspective?

Will keep the question simple, but its implications are much broader.
Goal
Create a 'My C/C++' perspective plugin.
this plugin is just the standard C/C++ plugin from CDT
plus some view sizing, extra help menus, and (1) custom plug-in
Need
Essentially just a way to share a customized C/C++ perspective
that includes a handful of my own plugins
but still harnesses all the power of CDT (editors, builders, parsers, views, etc).
Notes
This is a very helpful perspective-plugin tutorial:
Eclipse Plug-in Development – Create a Perspective
There must be a simple 'man/example/etc' out there. I've browsed all over the CDT plug-in manual to no avail:
CDT Plug-in Developer Guide
Perhaps it has to do with the org.eclipse.ui.perspectiveExtensions, but it is not clear to me how that would work.
org.eclipse.ui.perspectiveExtensions on its own just lets you add new views, menu items, tool bar items and new wizard items to an existing perspective (such as the C/C++ perspective).
If you want to create a new perspective you will have to declare it with org.eclipse.ui.perspectives and then use the perspective factory class and org.eclipse.ui.perspectiveExtensions to declare all the views, menu items and so on that you want in the perspective. This will mean finding out the ids of the C/C++ items you want to include - which probably means looking at the CDT plugin.xml files and their perspective factory source.
Update:
The C/C++ Perspective will be declared in one the CDT plugin plugin.xml files using the org.eclipse.ui.perspectives extension point. That declaration will give the name of the existing perspective factory class used. You may be able to extend this class (but if it is in an internal package this is not officially supported).

How to create Eclipse RCP application that behaves like a wizard?

I want create a installer by using Eclipse RCP. I need to give the user a wizard-like installer. This means user can do some options then click next. Or they can go back to previous page by click previous. Or they can cancel the installation by clicking cancel.
Here is my problem:
I don't know how to switch between views when clicking "next","previous". I need to create something like WizardPages and i can change between these pages?
I can't use JFace wizard because I'm required not to pop up any dialog.
I'm totally new to Eclipse RCP so please help!
thanks.
Maybe "StackLayout" is what you need.
Consider whether you actually want/need Eclipse RCP in this context. Eclipse RCP shines in complex applications with an extensive business domain and complex user interface.
An installer wizard, however, is very straightforward and static. I cannot imagine you requiring more than two or three user inputs. Your question is a bit like "I want to hear beautiful music. How do I program a robot to play the piano?"
It is much easier to limit yourself to using SWT and JFace. Use the JFace WizardDialog to make a nice installation wizard. You will find you will have never needed the Eclipse RCP framework.
See http://www.vogella.com/tutorials/EclipseWizards/article.html for a nice tutorial.
If you do think you need the features of the Eclipse RCP runtime framework, I suggest you follow the path below instead:
Create an RCP application (e.g. the sample 'Mail' application). A class will be created that is the main entry point in your application. This class will launch the Eclipse Workbench. Delete this code, and instead launch the WizardDialog.
A lot of things will not be available, such as menu's, views with drag-and-drop functionality, keybindings, etc. I cannot imagine you will need those things. However, you will benefit from the following Eclipse RCP features:
Eclipse launch framework. Ability to create a self-contained product including the JRE.
OSGi framework. Ability to easily add new plugins. Ability to use services, blueprint, etc.
JFace framework.
EMF (if you have a very complicated installation wizard)
All other eclipse plugins, although a lot of them may not work outside of the context of the Eclipse Workbench.
If you are convinced you need the full Eclipse Workbench, you can always do the following:
Define a 'base' perspective that is 'locked down'.
Use a Command to move from one perspective to the other. This will allow you to keep the previous wizard views open in other (hidden) perspectives.
Use Eclipse Contexts to hide all the standard Eclipse Workbench functionality, menu's, etc.
Since you are new to Eclipse RCP, I do not recommend learning the framework in the particular usecase of an Installation Wizard. You already need good knowledge of Eclipse RCP to be able to hack it this way, and it will not be a clean or nice implementation :-)

Eclipse e4 and plug-in development

Is it possible to create Eclipse plug-ins (e.g view parts) using Eclipse e4 incubator?
Or is e4 only useful for 'window-based' applications?
I already checked How can I create a view using the E4 programming model to be a plug-in for Eclipse 4.2 or above?, but this did not give me an useful answer.
Add:
I want to create an Eclipse plug-in and not a standalone rcp application.
I'm not sure what exactly you want to achieve.
Option 1:
You want to write a plug-in for an e4 RCP application:
You can do this (e.g., contribute ViewParts to an e4 application model) via a model fragment.
Basically, instead of extending the org.eclipse.ui.views extension point in Eclipse 3.x you create an application model fragment file in your plug-in and reference this in an extension to the extension point org.eclipse.e4.workbench.model.
In the model fragment, you define the parts, commands, etc. you want to contribute.
See for example these tutorials for more details:
http://eclipsesource.com/blogs/2012/06/26/eclipse-4-e4-tutorial-part-3-extending-the-application-model/
http://www.vogella.com/articles/Eclipse4Modularity/article.html
Option 2:
You want to write a plug-in e4 style for Eclipse itself.
As far as I know this is not possible straightforward, because currently, the Eclipse IDE cannot be enhanced with fragments (at least that is what https://bugs.eclipse.org/bugs/show_bug.cgi?id=376486 indicates ...)
But when that works, see Option 1.
Until then, you'd have to use the classic extension points. You can still write your view using the POJO/Injection approach of e4, but you need to use the 3.x to e4 bridge. You can get some hints from
http://eclipsesource.com/blogs/2012/06/18/migrating-from-eclipse-3-x-to-eclipse-4-e4/ .
In particular, see the paragraph starting "The third option is to use the 3.x e4 bridge from the e4 tools project"

Integrating community plugins into a ready Eclipse RCP app?

I already have a standalone Eclipse RCP application. The next task is to integrate the plugins which are widely used in the Eclipse community like CDT or say PyDev to provide the editing and debugging facilities in respective programming languages inside the already developed RCP app. Just wondering how do i go about accomplishing this task. Should i start with playing around the extension points of the plugins and adding it to the MANIFEST.MF ?
What are the various ways of achieving this ? Which one to pick over the other?
The most important thing you should consider (besides the technical) is a conceptional.
Plugins like CDT are making a lot of assumptations about their environment they are integrated into. That means your RCP should have a very similar user-interface and behavior like the normal Eclipse SDK so that the integration of other "IDE-ish" plugins is not a break of the interface principles of your RCP.
If your RCP is not based on a common navigator, projects, files (in general the Workspace) and several editors the integration of Plugins like CDT will be a nightmare for your users and will feel like another application within your RCP.
Make also sure that ui-contributions from third-party-plugins are visible (e.g. if the third-party-plugin is contributing a preference page, make sure that your RCP has the menu-item to open the preference-window)
First you have to load the new features/plugins in your existing RCP application. For this you have to adapt your product definition and load the new feature.xml files. or you enhance your own feature.xml and place the new plugins into.
Afterwards you have to decide, whether the new functions/view/perspectives are contributions to an already existing RCP extension point and whether you use this extension point in your RCP product.
If you want to use the new functions in another way (because the default is not enough) you have to point to specific views/actions in the new plugins and call them by your self. Fot his you have to adapt the MANIFEST.MF of your own plugin and point to the new plugins. If you do it, you can not switch off the added features, because you do have a jard link to these plugins.
Your RCP product already depends on the RCP feature (org.eclipse.rcp) or a subset of its plug-ins. This means, it already includes the plug-ins defining the basic extension points.
To include functionality (extensions) from additional features, just add these features to your product configuration dependencies. For example, you would have to add the feature org.eclipse.cdt for CDT and org.python.pydev.feature for PyDev.
The hard part begins when you need to include only some of the features' plug-ins.
You'll have to isolate the plug-in(s) providing the functionality you require.
For UI contributions, you can use the plug-in selection spy by selecting the required UI part and clicking alt+shift+F1.
For non-UI contributions, information for contributed extensions can be found in the plugin.xml files in the plug-in sources.
These plug-ins, along with their dependencies can be added to a custom feature, which can be included in your product.
Although dated, the article Building a CDT-based editor might also be of help.