Community
Participate
Working Groups
Currently, if one wants to use the expression mechanism to define enablement according to content-type, the content-type test seems to only work on IFile. However, content-type is a more generic concept and the test could also apply to IEditorInput in general.
I'm putting myself as assignee to make sure I consider this bug, but if anyone wants to work on it sooner, that would be highly welcome and feel free to change assignee.
As the FilePropertyTester is in org.eclipse.core.resources, it's not good design to implement it in a way that allows any other IEditorInput. And vice-versa: we cannnot create a property test for a generic IEditorInput which can delegate easily to IFile. Several possible solutions: 1. Create aproperty test that takes as input IEditorInput and adapts the IEditorInput to IContentType[] in the impletion (and make main IEditorInput implementations able to adapt to IContentType) That would look like: <activeWhen> <with variable="activeEditorInput"> <test property="org.eclipse.core.runtime.content.content-type" value="org.eclipse.linuxtools.tapa.content-type" /> </with> </activeWhen> 2. create a property tester that takes as input some IContentType[], and to let the main IEditorInput implementations adapt to IContentType[]. So, in order to get something enabled on any file of content type X, it would be <activeWhen> <with variable="activeEditorInput"> <adapt type="[Lorg.eclipse.core.runtime.content.ContentType;"> <test property="contains" value="org.eclipse.linuxtools.tapa.content-type" /> </adapt> </with> </activeWhen> While 1 is simpler for users and matches the use-case better; 2 seems more generic as anything adapting to IContentType can take advantage of it. Which one should we prefere?
@Dani: do you have any advice regarding comment #2?
(In reply to Mickael Istria from comment #0) > Currently, if one wants to use the expression mechanism to define enablement > according to content-type, the content-type test seems to only work on > IFile. However, content-type is a more generic concept and the test could > also apply to IEditorInput in general. I don't get that point. When the editor has been opened all the checks have already been made.
The idea is to be able to plug content (context menu and so on) according to IEditorInput only, not to the specific editor.
(In reply to Mickael Istria from comment #5) > The idea is to be able to plug content (context menu and so on) according to > IEditorInput only, not to the specific editor. Not following. The input in the editor depends on the IFile or the content type reader. I have no clue what you are asking here.
Basically, I'd like to attach a command to *any* editor opening a specific content-type, independently of whether the backend is an IFileEditorInput or a URIEditorInput. I'd like to do it with regular enableWhen expressions. There are currently no way to properly deal with external files and editor input in general with such expressions, unless I missed something.
(In reply to Mickael Istria from comment #7) > Basically, I'd like to attach a command to *any* editor opening a specific > content-type, independently of whether the backend is an IFileEditorInput or > a URIEditorInput. > I'd like to do it with regular enableWhen expressions. There are currently > no way to properly deal with external files and editor input in general with > such expressions, unless I missed something. That's wrong. Once the editor has been chosen the set of features should be set.
(In reply to Dani Megert from comment #8) > That's wrong. Once the editor has been chosen the set of features should be > set. I didn't get what "that" exactly refers to in this answer, Ca you please elaborate?
(In reply to Mickael Istria from comment #9) > (In reply to Dani Megert from comment #8) > > That's wrong. Once the editor has been chosen the set of features should be > > set. > > I didn't get what "that" exactly refers to in this answer, Ca you please > elaborate? Sorry, I was somehow chasing down another use case. I now see what you want to do. Solution 1 (new property testers) is the right one, because you do not want to depend on implementers of IEditorInput/s to add an adapter.
Taking it in my plans for 4.9.
Alexander recently implemented such a property tester in http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=2994fd42fa988a1bbc9799f0a1e93cd6b775ea9f . @Alexander: would you be interested in copying this property tester in a more common plugin (like org.eclipse.ui.workbench) and make PDE use the common one instead? There is much value in having this property tester in a more reusable place.
@Mickael: yes, sure
New Gerrit change created: https://git.eclipse.org/r/133719
