Here is a brief summary of some of the issues I have encountered while
working on porting the different views. Initially I wanted to focus on the
views listed under general, at least in my mind these are the views that
could be considered "core" RCP views. I recently officially parted ways
with my previous employer so I have been busy with that and haven't been
able to spend much time with the views. However, this week and next I was
planning on looking at these and some performance testing.
*Blocking issues (not really) :*
- In the fragment editor, the "Find" feature for the element id does not
work if the application model is named anything other than Application.e4xmi
- Bug 382717 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=382717> (just
noticed the patch and have not tested it)
*Other issues :*
- Required Minimum Execution Environment J2SE-1.5 (need annotations)
- Several plugins still have J2SE-1.4 as the min environment and
simply changing this to 1.5 may cause some issues with generics and raw
types (if not just a whole lot of compiler warnings). An analysis would
have to be made for each plugin to see if changing the environment would
cause problems and if so how to deal.
- PageBookView
- Several of the views extend from PageBookView which has obvious
dependencies on 3.x. Aside from just migrating PBV to e4, this
would be a
strong candidate for model extension (IMO). There is also the similar
TableView and maybe even CommonNavigator. So in general, should
any of the
supporting objects first become model objects?
- All e4 changes will be *Breaking Changes*
*Practice & Theory :*
- Should fragment naming schemes be set?
- Assumption -> The new e4 parts should be in their existing bundles and
not separate o.e.e4.* bundles. <-
- But what about o.e.e4.* packages within the bundle?
- Since there is a general separation of church and state in
o.e.e4.ui.workbench, should the "part" implementation be separate from the
"presentation"? Whereby any API provided by the part and maybe persistence
is captured in the base object and a separate object provides the
presentation (swt).
- The new e4 parts (views) will obviously break API, but before just
diving into the migration process should we solicit a wish list for future
api?
There are a couple of other issues (like collecting any applicable tags
into a central location) but none of which need to be addressed at this
point.
If anyone has any feedback or comments please do not hesitate, this is
clearly still very much a moving target. Again, unless there is opinion
otherwise, the complete list of views I am focusing on are:
- Bookmarks
- Console
- Error Log
- Help
- Internal Web Browser
- Markers
- Navigator
- Outline
- Problems
- Progress
- Properties
- Task List
- Tasks
- Templates
Thanks,
JD
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
