Home » Eclipse Projects » Rich Client Platform (RCP) » Suppressing menus, menu entries and toolbuttons
| Suppressing menus, menu entries and toolbuttons [message #459014] |
Mon, 27 November 2006 09:49  |
Eclipse User |
|
|
|
Platform: Eclipse 3.2.0/3.2.1
Java 2 SDK 1.5.0
I'm trying to figure out the simplest and cleanest way to suppress
irrelevant menus, menu entries and toolbuttons, for an RCP
application. "Cut the clutter", so to speak.
I've looked into both product level config/code (preferred) and
runtime configuring.
The most promising candidate is defining a new perspective, but it
looks like a perspective is mostly considered with views and their
layout, and that it can add new menus, and/or menu entries. It can't
suppress/replace existing ones, unless I'm mistaken (which I actually
hope I am).
I've googled a bit and found this old bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=29179
which refer to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=36967
which is said to be fixed with the introduction of the 3.0 platform.
This indicates that the functionality is in there somewhere...?
I've also googled this:
http://wiki.eclipse.org/index.php/Product_Customization#Supp ressing_An_Action
But I'm not comfortable with the solution propsed there (basically
rebuilding loaded plugin.xml files on the fly, before using them, if I
understood it correctly...).
Does anyone have any pointers or solutions, or pointers to solutions?
Thanx!
- Steinar
|
|
| |
| Re: Suppressing menus, menu entries and toolbuttons [message #459042 is a reply to message #459016] |
Mon, 27 November 2006 15:18  |
| Eclipse User |
|
|
|
>>>>> Paul Webster <pwebster@ca.ibm.com>:
> http://wiki.eclipse.org/index.php/Product_Customization#Supp ressing_An_Action
> refers to work that's being investigate for 3.3.
Ah, Ok. I thought bug 154099 referred to from the top of that page,
and the "Generalized OSGi Transformations" was the future stuff, and
the XSLT transformations of plugin.xml were current workarounds.
> In 3.1.x/3.2.x you can mask out *most* menu/toolbar items using
> activities/capabilities.
> Check out your Help>Help Contents>Platform Plug-in Developer
> Guide>Programmer's Guide>Advanced workbench concepts for information
> on filtering large user interfaces, which covers Capabilities and
> Activities.
Thanx! Looks like there is some filtering possibilites here, but the
only capabilities I can disable are "Development" and "Team" (in
Window->Preferences... and then General->Capabilities).
The docs I have to study some more. Can I create activities that
suppress system commands? Or are activities meant for grouping new
commands, so that they can be disabled or enabled like "Development"
and "Team", above?
> There is also some information in the Actions, Commands, and
> Activities section of
> http://wiki.eclipse.org/index.php/The_Official_Eclipse_FAQs
Hm... action sets seems like a promising concept. Can they be
overriden/replaced, I wonder...? Yes, they are the ones that can be
customized on a runtime/workspace basis. There the menus can be
slimmed down quite a bit. But not very useful for creating product
configurations, I'm afraid.
Thanx for the info!
- Steinar
|
|
| | |
| Is File->Open File... retargetable? (Was: Suppressing menus, menu entries and toolbuttons) [message #459119 is a reply to message #459044] |
Tue, 28 November 2006 03:58 |
| Eclipse User |
|
|
|
>>>>> Steinar Bang <sb@dod.no>:
> Here's something that looks promising, "Retargetable actions":
> http://help.eclipse.org/help32/topic/org.eclipse.platform.do c.isv/guide/wrkAdv_retarget.htm
Is, or is not, the "Open File..." action retargetable?
Some earlier responses on the eclipse newsgroups indicates that it is, eg.
http://dev.eclipse.org/newslists/news.eclipse.platform/msg44 590.html
http://dev.eclipse.org/newslists/news.eclipse.platform.rcp/m sg08439.html
However, it isn't listed under neither the file menu entries, nor the
global actions, in IWorkbenchActionConstants:
http://help.eclipse.org/help32/topic/org.eclipse.platform.do c.isv/reference/api/org/eclipse/ui/IWorkbenchActionConstants .html
(the wrkAdv_retarget URL says only the global actions are
retargetable).
No "Open File" entries are listed under "File Menu" either. The
newsgroup messages above are from about one year ago, and I guess that
would be the time of eclipse 3.1. But the eclipse 3.1 documentation
looks about the same as the 3.2 documentation for this.
Does anyone know?
Thanx!
- Steinar
|
|
|
| Re: Suppressing menus, menu entries and toolbuttons [message #459124 is a reply to message #459047] |
Tue, 28 November 2006 08:06 |
| Eclipse User |
|
|
|
Not sure this is what you're looking for, but I've found this code in KNIME
for modifying the resource navigator's context menu:
/**
* Fills the context menu with the actions contained in this group and its
* subgroups. Additionally the close project item is removed as not intended
* for the kinme projects. Note: Projects which are closed in the default
* navigator are not shown in the knime navigator any more.
*
* @param menu the context menu
*/
@Override
public void fillContextMenu(final IMenuManager menu) {
// fill the menu
super.fillContextMenu(menu);
// remove the close project item
menu.remove(CloseResourceAction.ID);
// remove some more items (this is more sophisticated, as these
// items do not have an id
for (IContributionItem item : menu.getItems()) {
if (item instanceof ActionContributionItem) {
ActionContributionItem aItem = (ActionContributionItem)item;
// remove the gointo item
if (aItem.getAction() instanceof GoIntoAction) {
menu.remove(aItem);
} else if (aItem.getAction() instanceof OpenInNewWindowAction) {
menu.remove(aItem);
}
}
}
// TODO: this is hardcoded the copy item. should be retreived more
// dynamically
String id = menu.getItems()[2].getId();
// add an open action which is not listed as the project is normally
// not openable.
menu.insertBefore(id, new Separator());
menu.insertBefore(id, new OpenKnimeProjectAction(this));
menu.insertBefore(id, new Separator());
}
"Andreas Goetz" <cpuidle@gmx.de> wrote in message
news:ekfjoc$1ed$1@utils.eclipse.org...
> Steinar,
>
> could you post your final solution? Same issue for me- would like to get
> rid of working sets...
>
> Thanks,
> Andi
>
> "Steinar Bang" <sb@dod.no> wrote in message
> news:87ac2cfwpo.fsf@bang.priv.no...
>> Here's something that looks promising, "Retargetable actions":
>> http://help.eclipse.org/help32/topic/org.eclipse.platform.do c.isv/guide/wrkAdv_retarget.htm
>>
>
>
|
|
|
| Re: Suppressing menus, menu entries and toolbuttons [message #459126 is a reply to message #459124] |
Tue, 28 November 2006 08:24 |
| Eclipse User |
|
|
|
>>>>> "Andreas Goetz" <cpuidle@gmx.de>:
> Not sure this is what you're looking for, but I've found this code
> in KNIME for modifying the resource navigator's context menu:
[snip!]
Thanx for the information, but it's not quite what I'm looking for.
Adding new new toolbuttons, and menus and menu entries, are pretty
well covered by the documentation.
It's slimming down the menus provided by the framework that gives me
problems.
Ie. what do I do when our usability people ask me what a command is
for, and I reply "er... it's something eclipse put in. It has no
meaning here, but I don't know how to get rid of it", and then they
tell me that that isn't really a good answer. :-)
Another problem I have, is replacing the "Open File..." action with a
brand new action. Currently we have both the "Open File..." action
which doesn't do what we'd like it to, and an "Open XML File..."
action which does (it parses the XML into a DOM, sniffs the DOM and
decides the editor on the basis of what it finds).
So what I'm looking at are the possibilities of either losing the
standard "Open File..." action and naming the "Open Xml File.." to be
"Open File...", or changing "Open File..." using retargeting to use
the mechanism currently used by the "Open Xml File..." action.
|
|
| | | | | |
| Retargeting the "Open File..." action (Was: Suppressing menus, menu entries and toolbutton [message #459703 is a reply to message #459187] |
Wed, 06 December 2006 08:39 |
| Eclipse User |
|
|
|
>>>>> Steinar Bang <sb@dod.no>:
> But I could do stuff like replace the action underlying "Open
> File..." with my own. That is; I could _if_ "Open File..." was a
> retargetable action which it doesn't look like it is...:-)
To repeat my platform:
Platform: Eclipse 3.2.0/3.2.1
Java 2 SDK 1.5.0
To summarize my problem here:
- I need to handle several different XML formats, all of which have
the extension .xml, with different editors for each format
- we currently have a factory which we use on input XML files to try to
determine their actual format, and create an object implementing
IEditorInput based on that
- when we get the editor input, we use it to find the id of the
editorpart class in question (we've extended the IEditorInput
interface to have an getEditorId() method)
- we call IWorkbenchPage#openEditor() with the editor input and the
appropriate editor id
To do this we've created a new editor action, which is added to the
file menu with the text "Open XML File...".
I would like that action to end up behind "Open File..." instead.
But that doesn't seem straightforward.
There is a registry from file name extension to IEditorPart, but that
won't work here. I would have needed a registry for a factory that
could return a tuple of IEditorInput and editor id, and this factory
would have needed to be used by the system "Open File..." action.
If the "Open File..." action had been retargetable, I could have
replaced it with the action currently going under the entry "Open XML
File..." (our RCP app will only ever have to open XML files, but as I
said, XML files with several formats/vocabularies/schemas).
One way that will work, is to create our own ActionBarAdviser and
populate the menus and toolbars using code. That will work, but
possibly isn't The Eclipse Way(TM)...?
Is there some possible approach I'm missing here?
Thanx!
- Steinar
|
|
| | | |
| Re: Retargeting the "Open File..." action [message #459758 is a reply to message #459752] |
Thu, 07 December 2006 07:04 |
| Eclipse User |
|
|
|
>>>>> Steinar Bang <sb@dod.no>:
[snip! Determining editor on the basis of content type]
> This seems like the place to start reading:
> http://help.eclipse.org/help32/topic/org.eclipse.platform.do c.isv/reference/extension-points/org_eclipse_core_runtime_co ntentTypes.html
Let's see... what I need to do, is:
- Write an implementation of the ITextContentDescriber interface
http://help.eclipse.org/help32/nftopic/org.eclipse.platform. doc.isv/reference/api/org/eclipse/core/runtime/content/IText ContentDescriber.html
- Register the class that implements ITextContentDescriber in with one
content type <extension> in plugin.xml, for each separate XML
format (described in the quoted URL above)
- Implement the ITextContentDescriber#describe() method, to look at
the contents of the file, and determine if it is one of the
supported file formats, and if it is, fill out an
IContentDescription for the format
- The IContentDescription#getContentType() method will return an
IContentType that can be used to get the correct editor
- I will need to refer to the content type ID in the editor
extensions:
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse. platform.doc.isv/reference/extension-points/org_eclipse_ui_e ditors.html
The only part that's missing is where, how, and if, IEditorInput
figures into this, when using the regular "Open File..." action...?
Thanx!
- Steinar
|
|
| | | | | | | | |
| Re: OpenExternalFileAction returns JavaFileEditorInput [message #459918 is a reply to message #459901] |
Fri, 08 December 2006 12:59 |
| Eclipse User |
|
|
|
>>>>> Paul Webster <pwebster@ca.ibm.com>:
> That's the way this works. IFileEditorInput represents a workspace
> file and is a 1st class citizen. JavaFileEditorInput represents an
> external file ... it's there so you can open external files into
> eclipse, but it's not a 1st class citizen, since it's not in the
> workspace. We'll never get resource deltas for it, for example.
But it would be rilly-rilly-nice if they could end up in the most
recently used files list in a persistent manner.
You wouldn't happen to have a workaround for that, by any chance...? :-)
Right now I'm trying to write a persistable IPathEditorInput (I've
based open, doSave, and doSaveAs around IPathEditorInput, which is one
of the interfaces implemented by JavaFileEditorInput, and probably the
easiest one to persist), but I haven't figured out how
IPersistableElement is supposed to work yet, and still don't know if
substituting an editor's IEditorInput in the init() method will work.
Time will show.
|
|
| | | | |
| Re: How to delete File > Open File.. menu item? [message #460853 is a reply to message #460800] |
Sun, 31 December 2006 04:28 |
| Eclipse User |
|
|
|
>>>>> phuonglh <phuonglh@gmail.com>:
> I have the same problem as Steinar. My application has 2 system menu
> items Open File... and Open and I cannot remove them out.
> I worked around in the Eclipse documentation
> http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse. platform.doc.isv/guide/wrkAdv_retarget.htm
> and found that File > Open File... is not retargetable action. So I
> cannot retarget it to my own implementation.
> I read all the posts in this thread but I didn't find a solution. :(
Well, there _is_ a solution, but it isn't pretty. Something like
this:
- Create a class that extends ActionBarAdvisor
- Override the ActionBarAdvisor#fillMenuBar() method and use a
MenuManager to build _all_ of your app's menus manually (this is
what makes it not pretty in my opinion, especially when all you
want to do, is to remove a single entry from the file menu...)
- Create a class that extends WorkbenchWindowAdvisor
- Override the WorkbenchWindowAdvisor#createActionBarAdvisor()
method, and have it return an instance of your ActionBarAdvisor
class
- Create a class that extends WorkbenchAdvisor
- Override the WorkbenchAdvisor#createWorkbenchWindowAdvisor() method
to create, and return an instance of your WorkbenchWindowAdvisor
subclass
- Create a class that implements IPlatformRunnable
- In this class' run() method, call the static method
PlatformUI#createAndRunWorkbench() giving an instance of your
WorkbenchAdvisor subclass as the second argument
- Register this class with an application extension in the
org.eclipse.core.runtime.applications extension point
I may have missed a class or two that needs implementing, and there
may be more required methods, and registration of the application
extension may not be enough, but... this is hopefully enough to give
you a pointer for where to look to lose your undesired "open file"
entries...:-)
|
|
| |
| Re: How to delete File > Open File.. menu item? [message #460878 is a reply to message #460853] |
Mon, 01 January 2007 03:49 |
| Eclipse User |
|
|
|
>>>>> Steinar Bang <sb@dod.no>:
> Well, there _is_ a solution, but it isn't pretty. Something like
> this:
> - Create a class that extends ActionBarAdvisor
> - Override the ActionBarAdvisor#fillMenuBar() method and use a
> MenuManager to build _all_ of your app's menus manually (this is
> what makes it not pretty in my opinion, especially when all you
> want to do, is to remove a single entry from the file menu...)
This is the core thing to implement. The rest of the classes below,
are just leading up to calling this method at the appropriate point.
Javadoc for ActionBarAdvisor:
http://help.eclipse.org/help32/nftopic/org.eclipse.platform. doc.isv/reference/api/org/eclipse/ui/application/ActionBarAd visor.html
A code fragment for the start of the fillMenuBar() method:
protected void fillMenuBar(IMenuManager menuBar)
{
super.fillMenuBar(menuBar);
IMenuManager fileMenu = new MenuManager("&File", IWorkbenchActionConstants.M_FILE);
fileMenu.add(this.newAction);
fileMenu.add(new Separator(IWorkbenchActionConstants.MB_ADDITIONS));
fileMenu.add(new Separator());
fileMenu.add(this.closeAction);
fileMenu.add(this.closeAllAction);
...
menuBar.add(fileMenu);
...
}
Ie. create a MenuManager for each menu, fill it up with the
appropriate actions, and add it to the IMenuManager given as the
method argument.
> - Create a class that extends WorkbenchWindowAdvisor
> - Override the WorkbenchWindowAdvisor#createActionBarAdvisor()
> method, and have it return an instance of your ActionBarAdvisor
> class
> - Create a class that extends WorkbenchAdvisor
> - Override the WorkbenchAdvisor#createWorkbenchWindowAdvisor() method
> to create, and return an instance of your WorkbenchWindowAdvisor
> subclass
> - Create a class that implements IPlatformRunnable
> - In this class' run() method, call the static method
> PlatformUI#createAndRunWorkbench() giving an instance of your
> WorkbenchAdvisor subclass as the second argument
> - Register this class with an application extension in the
> org.eclipse.core.runtime.applications extension point
> I may have missed a class or two that needs implementing, and there
> may be more required methods, and registration of the application
> extension may not be enough, but... this is hopefully enough to give
> you a pointer for where to look to lose your undesired "open file"
> entries...:-)
This last comment still holds. :-)
|
|
| | |
Goto Forum:
Current Time: Fri Mar 21 20:41:49 EDT 2025
Powered by FUDForum. Page generated in 0.06372 seconds |
Home