Community
Participate
Working Groups
Converting your 3x RCP to e4 requires transformation to the application model. It would be nice to have some tools to help this process. I have created a little prototype that enables the import of commands into the model. This could easily be extended to other areas like views and editors. I think commands, handlers, views and editors are the parts of interest and I will focus on these first.
Example video: http://www.youtube.com/watch?v=lHu-aYEc88Y
Created attachment 228185 [details] Patch with three new components
Created attachment 228186 [details] Patch that modifies VCommandEditor to enable the import for commands
I think a lot of work already has been done in this area. I have found some early code that PW provided[1][2] but I am unable to find it. I assume it has been moved to platform somewhere or refactored. @PW, can you point me to the stuff that could be useful for this? [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=263090 [2] https://bugs.eclipse.org/bugs/attachment.cgi?id=124323
That kind of code ended up in the model processors. ex: org.eclipse.ui.internal.CommandToModelProcessor, org.eclipse.ui.internal.ContextToModelProcessor, etc PW
Implemented import support for Command Categories and Commands. http://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/commit/?id=12d71f4a0814299f451d6ae1242862c06157263e
Are you sure you want to add the dependency to org.eclipse.pde.core? Won't that prevent this bundle from running in most of the Release Train packages, restricting it to products built on the whole classic SDK? PW
Paul is right - you should not add a dependency on PDE-Core into this bundle. It should stay as light weight as possible! We normally abstract those services and provide a concrete implementation in the bundle which does the IDE integration.
I agree with Paul and Tom, such a dependency should be avoided.
There already is a dependency on pde in the e4.tools project. pde <- e4.tools <-e4.tools.emf.ui So I don't think it makes any difference.
(In reply to comment #8) > We normally abstract those services and > provide a concrete implementation in the bundle which does the IDE integration. That would be e4.tools?
So the one who introduced this dependency is also wrong!
Sopot made the change in bug 395371! This needs to be reverted!!!!
This slipped out of my promise here http://dev.eclipse.org/mhonarc/lists/e4-dev/msg06989.html to take the look at the UI thing. As soon I saw the issue that unkept promise came to mind. I'll re-open bug 395371 and find a way around this dependency.
Created attachment 228540 [details] Patch for Sopots change Here's how Sopots change should integrate into EMF-UI
Thanks. I fixed the dependency with: http://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/commit/?id=0eae36e110047190933db951f432f158aa935c47 http://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/commit/?id=8c49cc78f601c0c87e9297221ce583bb573c340d
Added support for handlers, perspectives and views http://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/commit/?id=ff55e2853be0606226374a4ef3f07f855ddc2877
Added support for editors can import editors and views in partstacks and part descriptors, general clean-up. Wizard description, javadoc. http://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/commit/?id=d94be04547b2f6c757a9b2accea934f3ce6c0467
Great work Wim! Maybe a little bit more descriptive Git commit message would be nice, I was just looking at the Git commit history and tried to figure out what "Added support for editors" means.
Do we have some standards describing the commit message? I normally commit like this: bug xxx: describe what this patch did in one line description of the bug bug url
*** Bug 392820 has been marked as a duplicate of this bug. ***
Our standard commit message (such as it is) is the full bug title, a blank line, and then whatever description you want to put about the fix or patch: Bug 402875 - Importing model elements from legacy RCP Added support for reading the commands extension point.
(In reply to comment #22) Thanks I will use that pattern from now on. I suggest to also add the bug url, maybe as the last line. Not having the bug url in the message will make it hard for people to link to the issue. For an example see [1] [1] https://github.com/eclipse/eclipse.platform.ui/commit/21121bd72dc7c1a271ccb9d681ba4a0ded7b44bc
If you use Mylyn you can link the commit to the bug (task) and it's fairly easy to provide a template and it adds it automatically. Something like ${bug number} - ${bug title} \n ${bug link}.
While you can put it in there if you want, it's not hard for people to go from the title to the bug. Also, when viewed in git.eclipse.org/c "Bug XXXX" is enough to automatically get a link. PW
Added preview functionality to add compatibility views to shared area and part descriptor. This to experiment with mixed mode. All imported part and partdescriptors now also get a toolbar and viewmenu with the same id. pushed to master: http://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/commit/?id=71eeea902eb307e0f6728baf7931a8e725f1ab50
I think this one is fixed.
