Community
Participate
Working Groups
I'd like to contribute a menu to editors and selections when the current selection is an IResource, I do something like the following... <extension point="org.eclipse.core.expressions.definitions"> <definition id="resourcesDefinition"> <iterate ifEmpty="false"> <adapt type="org.eclipse.core.resources.IResource"/> </iterate> </definition> </extension> <extension point="org.eclipse.ui.menus"> <menuContribution locationURI="popup:org.eclipse.ui.popup.any"> <dynamic class ="abc" id="def"> <visibleWhen checkEnabled="true"> <or> <with variable="activeMenuSelection"> <reference definitionId="resourcesDefinition"/> </with> <with variable="activeMenuEditorInput"> <reference definitionId="resourcesDefinition"/> </with> </or> </visibleWhen> </dynamic> </menuContribution> </extension> Now I'd like to use similar code for my activeMenuEditorInput variable to work for the IFileStore case. Unfortunately, it seems like I have to add my own adapter factory for this to work out. Since a FileStoreEditorInput doesn't appear to adapt to an IFileStore.
Dani, send it back if I've got it wrong. PW
Time permitting. Needs testing as this will change the behavior of existing code.
To be decided during M6.
Do you have a concrete use case where you have IFileStore objects directly at hand? I'm asking because in the IDE the user/client only "sees" the editor input.
(In reply to comment #4) > Do you have a concrete use case where you have IFileStore objects directly at > hand? I'm asking because in the IDE the user/client only "sees" the editor > input. Sorry, can you rephrase this, Dani? I'm tweaking the shared editing code to work for textual editors both for resources inside and outside the workspace so I'm trying to declare it in XML based on editor input...does that help?
> I'm tweaking the shared editing code What's the "shared editing code"? >Sorry, can you rephrase this, Dani? I'm looking for a use case where you have the IFileStore at hand and not the editor input. I know it might make sense if you're an RCP that include ui.ide but in that case you could either duplicated the contributions or add the adapter yourself. I could not find a use case where it would be needed for the IDE.
(In reply to comment #6) > > I'm tweaking the shared editing code > What's the "shared editing code"? Sorry, I mean the ECF shared editor thingamajig. http://codesurgeonblog.com/2008/06/cola-real-time-shared-editing.html > >Sorry, can you rephrase this, Dani? > I'm looking for a use case where you have the IFileStore at hand and not the > editor input. I know it might make sense if you're an RCP that include ui.ide > but in that case you could either duplicated the contributions or add the > adapter yourself. I could not find a use case where it would be needed for the > IDE. No, I don't believe I would have the file store without the editor input in my case.
Adding this has no immediate benefit for the SDK but in turn could result in strange behavior RCP apps (using the ui.ide plug-in) that either already have an adapter or which do not expect such an adapter to be in place and hence get strange results.
I'd like to revisit this issue. Please consider the following use case: A menu item should be visible in the context menu of an editor when the editor input is a "special" file: <definition id="myplugin.isSpecialFileOpenInEditor"> <and> <with variable="selection"> <not> <instanceof value="org.eclipse.jface.viewers.IStructuredSelection"/> </not> </with> <with variable="activeEditorInput"> <reference definitionId="com.google.eclipse.project.ui.isSpecialFile"/> </with> </and> </definition> <definition id="myplugin.isSpecialFile"> <or> <adapt type="org.eclipse.core.resources.IFile"> <test property="org.eclipse.core.resources.name" value="special"/> </adapt> <adapt type="org.eclipse.core.filesystem.IFileStore"> <test property="myplugin.fileStore.name" value="special"/> </adapt> </or> </definition> In the example above a file is considered special if it's name is "special", but it could be any other condition. Unfortunately, the above condition doesn't work for files outside workspace because FileStoreEditorInput doesn't adapt to IFileStore. Lack of symmetry between FileEditorInput, which adapts to IFile, and FileStoreEditorInput which doesn't adapt to IFileStore, is troublesome and doesn't seem to have any rational justification.
The was a minor inconsistency in the condition definitions in comment #9. Here are the corrected definitions: <definition id="myplugin.isSpecialFileOpenInEditor"> <and> <with variable="selection"> <not> <instanceof value="org.eclipse.jface.viewers.IStructuredSelection"/> </not> </with> <with variable="activeEditorInput"> <reference definitionId="myplugin.isSpecialFile"/> </with> </and> </definition> <definition id="myplugin.isSpecialFile"> <or> <adapt type="org.eclipse.core.resources.IFile"> <test property="org.eclipse.core.resources.name" value="special"/> </adapt> <adapt type="org.eclipse.core.filesystem.IFileStore"> <test property="myplugin.fileStore.name" value="special"/> </adapt> </or> </definition>
New Gerrit change created: https://git.eclipse.org/r/45905
I can have another look during 4.6, but not for 4.5, since this affects the API.
It makes sense to get this change in earlier rather than later since it would leave more time for discovering and fixing potential problems.
Gerrit change https://git.eclipse.org/r/45905 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=1a1a45f708fcbd670ebc99e7b63fcce8694a393c
(In reply to Sergey Prigogin from comment #9) > Lack of symmetry between FileEditorInput, which adapts to IFile, and > FileStoreEditorInput which doesn't adapt to IFileStore, is troublesome and > doesn't seem to have any rational justification. Makes sense.
