Hi Kai, Thanks for your input, I think you raise very important points. Do you know if Siemens would be interested in working with us on some of these issues?
I'll comment on some of your points below: > - Can we reduce the complexity? > o Right now, after one week of training, a RCP newbie > just touched the very basic things of RCP. > This is one reason why many big industry companies have problems > adopting RCP. > o A less complex application model > and a UI presentation model might help here, > but clean, simple and concise Java APIs all over the place are > also very important. I hope that our work area "architectural foundations" together with the "Eclipse application model" will address this. I agree that it is important to have clean and concise APIs, and additionally, I believe that we need more consistency - things that have a similar structure should have a similar API. I don't know how we can get there, but for example, we have too many different flavours of objects-with-data-in-a-hierarchy such as preference nodes, the extenstion registry, XML mementos, JFace tree content providers, you name it. > - Can we reduce the footprint? > o Do bundles like ICU (4.3MB) have to be part of the RCP core? > o Can we refactor the workbench bundle (3.7MB) and take optional > things out of the RCP core? I expect that by coming up with an application model, defined in terms of services and interfaces, we will be able to componentize the Workbench, and even allow replacing some of the implementations with ones that we don't own. Also, I am hoping that p2 will make it easier to assemble the exact pieces you want to ship with your RCP app, so that the current pain of having to define your own RCP feature with the replacement bundle instead of the full ICU4J goes away. > - Can we focus on THE best practice of doing things? > o In the current RCP implementation there's very often more than > one way how to archive the same goal. > o Can we integrate just the best practice into the core and provide > an optional compatibility layer? > o Example: ActionSets vs. menu contributions (+commands & handlers) Yes! > - Can (and should) we provide a more customizable UI for the desktop? > o The ongoing discussions about a canvas based UI core are very > interesting... > o For RCP UI customization currently we have the Presentation API, > custom SWT widgets, Equinox transformations etc., > But besides that, current RCP applications look similar to the Eclipse IDE. I agree that we currently have a lot of accidental complexity that gets in your way when you want to customize the UI. We should be able to reduce that complexity by allowing styling similar to CSS. However, since there are so many ways in which you can customize a UI, I don't think this will ever become something that anyone can just go and do. Just have a look at what it takes to define a CSS style sheet for a decent-looking blog, and multiply by some factor that takes into account that an IDE is more complex than a blog. > - Should we integrate authentication/authorization better in the RCP core? > o In the Equinox area there is some ongoing work to integrate these things > o A standard user/role with UI support concept would be very > helpful (see bug 201052) Sounds like a very good idea. This is one of the areas that I don't see covered in our list of work areas - it looks like this problem looking for someone who wants to own it! > - Should we integrate provisioning better into the RCP core? > o Currently Equinox p2 is integrated into Eclipse 3.4M6, and I like > the p2 approach. > o But as of today, it is not so easy to reuse p2 in a domain > specific RCP application > o Some of the provisional p2 UIs could be part of the public API in > the RCP update story This sounds like something that should be addressed in the 3.x stream, not just in e4. Boris _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
