Community
Participate
Working Groups
Build Identifier: With the extension point programing model being very popular in the IDE and RCP world and the pojo/dependency injection model in e4 being very modern, I wondered if these two concepts could be brought together. I did a quick prototype to check if this is possible for views. I added this to ViewRegistry#postConstruct: String className = element.getAttribute(IWorkbenchRegistryConstants.ATT_CLASS); if (className.startsWith("platform:")) { descriptor.setContributionURI(className); } else { descriptor.setContributionURI(CompatibilityPart.COMPATIBILITY_VIEW_URI); } Instead of only: descriptor.setContributionURI(CompatibilityPart.COMPATIBILITY_VIEW_URI); This makes the new e4 features like service tracking using @Inject accessible for programmers using the extension points. Of course, the class name starting with "platform:" is not a good distinctive criteria for deciding if the value should be treated as legacy or e4, something better would have to be found. But I wanted to validate my suggestion first and ask for your opinion about the general approach. A more general approach would also need to included editors, command handlers, etc. Reproducible: Always
Maybe the compatibility layout would make plugable to support such a approach?
Eric Moffatt did a related change in Bug 378298, here is his comment: ---------- Committed http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=ac4572d1c89b229bf6354cf199cd49372b7e7ebe This adds a new extension 'e4view' to the org.eclipse.ui.views extension point and changes the ViewRegistry code to recognize that the 'class' should be used as the contributionURI in the model (rather than CompatibilityView). This is the first step but there is still work to do so I won't close this one yet... -------
*** Bug 406307 has been marked as a duplicate of this bug. ***
*** Bug 278631 has been marked as a duplicate of this bug. ***
Moving to 4.4 M2 to keep it on the radar...
(In reply to comment #5) > Moving to 4.4 M2 to keep it on the radar... Cool. Can we discuss the next steps? Selection service integration?
(In reply to comment #2) I've pushed some follow-up fixes to views.exsd: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=c5d952117cac0829e46998e12ce417c6fdd38fc8
Hi, The cross referencing inside the manifest editor does not work for the e4view extension point. Would it not be easier to use the existing "view" extension and just check if the view implements IViewPart. If it does not then it defaults to an e4view. This will make sure that the cross referencing works. Since the "view" extension is referenced from various places it would require changes in these places to also reference this e4view extension.
Moving into M3 to allow for more extension changes. I'll try to remember bookkeeping this time (i.e. updating the copyright...), thanks Markus.
In an ideal world we would be able to do as Wim suggests but unfortunately there doesn't seem to be a way to have the extension point editors provide a 'flavor' of a given extension (where we'd just re-use the existing 'view' and have a checkbox or something to determine whether or not it's legacy / e4). I think the problem is that .exsd doesn't have conditionals so trying to express that 'if it's a legacy part it must subclass IViewPart otherwise not' isn't possible.
(In reply to Eric Moffatt from comment #10) > In an ideal world we would be able to do as Wim suggests but unfortunately > there doesn't seem to be a way to have the extension point editors provide a > 'flavor' of a given extension (where we'd just re-use the existing 'view' > and have a checkbox or something to determine whether or not it's legacy / > e4). > > I think the problem is that .exsd doesn't have conditionals so trying to > express that 'if it's a legacy part it must subclass IViewPart otherwise > not' isn't possible. You mean to allow the class selection dialog to select other classes then IViewPart implementations?
Have you tried the 'e4view' views of the 'org.eclipse.ui.views' extension point introduced in M1 for Luna: http://download.eclipse.org/eclipse/downloads/drops4/S-4.4M1-201308072000/news/Contribute E4 Views into the IDE Daniel
Daniel, original this bug would also cover POJOs for handlers and editors. With your title change this gets lost. Can you change it back or shall we open new bugs for handlers and editors?
(In reply to Daniel Rolka from comment #12) > Have you tried the 'e4view' views of the 'org.eclipse.ui.views' extension > point introduced in M1 for Luna: > > http://download.eclipse.org/eclipse/downloads/drops4/S-4.4M1-201308072000/ > news/Contribute E4 Views into the IDE > > Daniel We try to define some component owner during bug triage process (currently is my bug triage turn) so let me add missing components (feel free and update it if needed) By the way, I haven't noticed the entire discussion below however it was good to boost the Luna's M1 achievements :) Daniel
I created a separate bug for POJOs and handlers. Bug 420584.
M4 is done...
Another thing that does not work is the appearance of the view in the "Quick Search". It does appear in the "Show View" dialog.
I mark this bug as fixed, since Eclipse 4.4. we have the e4view and you can use the POJO programming model for e4 handlers in the IDE already.
(In reply to Lars Vogel from comment #18) > I mark this bug as fixed, since Eclipse 4.4. we have the e4view and you can > use the POJO programming model for e4 handlers in the IDE already. How about editors?
Any update on the registration of POJO for editors?
