I am wondering if there are definitions for when to develop different plugins for eclipse. For instance, I am wanting to create something that can either be a wizard in eclipse or a property in eclipse. Both the property and wizard would be associated with a project. Is there a common practice for when to do one over the other? Or is this just by preference?
There are no hard rules for which approach to choose, but here are a few things to consider:
User experience: Think about how the user would want to make the change, what would be easiest/most intuitive for them.
Applying the change: With a wizard you'd be collecting data up front, possibly over multiple pages, and only applying the change on clicking Finish. With properties the changes will generally be to single fields and applied immediately.
Undo: Do you want the change to be undo-able? If so a property sheet may be a better fit. Changes through a wizard could still go on the undo stack, but it would be more unusual.
Complexity: If there are multiple fields to change or the user needs guidance in making the change a wizard might be more appropriate.
When the change is made: If it's data that you want to configure on a new project, but also want to change later, it might be better to include it both in the New Project wizard and a property sheet.
Related
I am looking for a way to to force Eclipse to refresh/rebuild its own main menu or even the whole view on runtime programmatically.
The reason why i need it this way is, because i have a plugin that iterates through a project and depending on the configuration of the selected project it loads a project specific plugin at runtime with:
FrameworkUtil.getBundle(this.getClass()).getBundleContext().installBundle(String).start()
Now the loaded plugin contributes to the org.eclipse.ui.main.menu extension point and even though the plugin is installed I don't see the new menu entry.
FYI: I am using Eclipse 3.x and E4 Tools
Now my questions are:
Is there acutally a way to refresh/rebuild parts of the Eclipse ui or maybe even the whole ui?
If not, can someone think of another approach? I thought of having a plugin which contributes only the menu and add the menu items programmatically.
But i couldn't believe that there is no way to refresh the view so i am asking this question.
I checked whether MMenu had a refresh method itself so i could get the object and just call the refresh method.
But in the end i didn't find a way to do this.
P.S. I am pretty new to Plugin Development and RCP so please don't blame me if the solution was obvious but i didn't realize it
Refresh/Rebuild UI
Short answer: no
In many places Eclipse extension points are loaded and information is stored in static fields (often in a Singleton). The plugin.xml data is not reloaded during the lifetime of the application, and certainly these bundles do not listen bundle events that would allow them to detect such changes.
Therefore, even if there were some method to call refresh on the whole UI, at least some (most?) of the code handling extension points would not see the effects of the new plugin.xmls.
Another Approach
To answer what you are trying to do, the "normal" thing to do would be to have each menu contribution's visibility be dependent on some expression, e.g. if the current selection adapts to MySpecialProject you could have it visible.
When you do it the normal way, and you leave everything to be lazily loaded, the java code for all those project type plug-ins will not be loaded until the commands are actually invoked for the first time.
To go the next step, you would probably have a main ui plug-in that defined a bunch of commands (e.g. build project, flash leds, format file, etc), but have no command handlers associated in that main plug-in. In each project type plug-in, have command handlers that are enabled when only the correct project type is active.
Assuming you have already worked through a basic tutorial on commands in Eclipse, there is a good advanced one on vogella.com that covers many useful features for being properly dynamic.
I have an e4 RCP which needs all the screen real estate. I have developed a second RCP that is in effect a relatively simple single-function plug-in, with currently only one part. I want the user to be able to launch the second from the first, then terminate it, all on demand.
As I understand it, I have 3 options:
Launch a new workbench for the second, written as a plug-in. I assume this uses more resources and also has the problem that I need to track and distinguish events which will go to both.
Write the second as a model fragment plug-in that extends the first. This has the advantage that I can keep on adding to the second plug-in by declaration in the model editor. However, I believe this requires attaching to an existing container in the main model. I could add a new container to the main model and write code to flip containers in and out but it is all done in the model editor currently, and more importantly the functions carried out by the second plug-in are quite different from those of the first (main) RCP, so I fear the user will find the UI change confusing.
Use EModelService and write code to create a new TrimmedWindow and then child PartStack, and Part, and all the Handlers. I have not yet found enough documentation to fully understand the implications, advantages and disadvantages of this - aside from the obvious ones that the former declarations now have to be programmed and coupling is tighter.
It looks to me like Eclipse itself uses approach 1 for two of its menu items:
Help Contents
Eclipse Marketplace
From the UI perspective, the kind of UI separation of functions that I want to achieve is very much like these two items. Hence I am leaning to option 1.
Any corrections or alternatives?
You could possibly use a PerspectiveStack with two perspectives containing the windows for your two apps. The second app can be in model fragment.
You can then just use EPartService.switchPerspective to switch between them.
One of my favorite new features of Eclipse Mars is dynamic working sets. It allows developers to set up rules that will automatically categorize projects into working sets.
Does anyone know of a way to textually edit this preference? I'd like to make bulk changes to my rules, but that is simply not possible in a GUI. Thanks!
These settings are stored in ${workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.oomph.workingsets.prefs.
It's an XML-file.
I would like to disable a read more plugin ( cutof content) in all pages except my main menu pages in joomla
How do I do this
Thanks in advance
I'm not aware of any method that allows for the actual disabling of a plugin for certain pages. Plugins are either on or off, site-wide. This can be seen from the Extensions | Plugin Manager, as well as the SQL database: jos_plugins. With that said, what would be the purpose in disabling a plugin for certain pages? Most plugins, especially those like a "readmore" are typically setup to be activated by a simple code sequence, such as {readmore}path/file.htm{/readmore} and consequently, you can turn the plugin "off" by simply choosing to not use it. Most plugins of that nature provide very little more than essentially "coded access to a CSS class". If you could be more specific on why you need to actually disable the plugin for certain pages, perhaps we'd be better equipped to answer properly.
Depending on the plugin, you could feasibly remove the event trigger that would set the plugin to run, thought it would not be advisable since it would stop that trigger for all plugins and could cause unintended effects.
I am not sure what you mean by "Read more" plugin. You can turn the read more text on and off as a setting in the menu item parameters or in the article itself. Have you tied that?
In a custom Eclipse's product We are asking ourselves:
Should we create one single UI plugin for all the user interface matters or should we broke these matters in several plugins (for example, ui.views - ui.preferences - ui.properties etc ...)
It seems Eclipse's "official" products such as CDT, JDT ... only have one UI plugin and some third party plugins I am using have several ui plugins (Papyrus for example)
I know this is rather a subjective question but I would be interested to learn about the way you manage your UI stuff.
Manu
I'd create separate bundles (or plugins) for each independently usable component. So if I have e.g. a view that can be used without some other things, I'd put it in a bundle of its own. I find that this makes it easier to configure the feature, replace certain parts, provide custom combinations of components, handle dependencies, and such.
If your plugin does one thing (e.g. add a menu item to order pizza) it makes little sense to split it up, you're just introducing complexity. The modularity of your product is the key factor in deciding how to split the functions into plugins. Consider the functionality you're trying to deliver and whether there are any optional components or pieces that may be useful in isolation.
Take m2eclipse as an example, it has multiple UI plugins, but that is because they are functionally separate. The XML editor is certainly a useful UI addition, but users of the core function (dependency management) don't necessarily need it so it makes sense to bundle it separately and make it optional.
Ignoring anything specific to Eclipse, I would say from a product support perspective it makes much more sense to have a single plug-in. This has the following benefits:
Every customer has the same environment, so if someone contacts you with a problem you know what they have.
You have to test a single configuration. If you split your code into 3 plug-ins that's 7 different configurations you have to test.
In future you won't have to worry about which plug-in new functionality should be added to.