| Re: [e4-dev] Some random thoughts after browsing the e4 code base |
Hi Philipp,
Philipp Kursawe wrote on 07/22/2009 06:19:19 AM:
> I hope its ok for non-contributors to post on this list?
Of course! (but be warned that we'll try to make you one! ;-)
> 1. Why is e4 still using an (empty) Activator in almost every project?
This is just an oversight (the current PDE default options still create an activator class, for example). Patches for removing these would be welcome!
> 2. Why are you still using Require-Bundle in almost every bundle when a
> I-P would do just fine? And then the CSS core bundle is requiring the
> batik bundle which it does not use one class from, does it?
Not sure about the CSS dependencies, but I believe we would happily switch to Import-Package if there are no downsides with regards to API tooling, build, etc. Again, probably due to old habits and we could use help...
> 3. The CSS bundles are too tightly coupled with each other. As far as I
> understand the concept, there are handlers for CSS elements. Couldn't
> those handlers and other components that make up a CSS engine
> implementation be contributed by extensions?
I hope Kevin can comment on this, I believe it's just a matter of more focus on getting a different "look" implemented in time for 0.9, and worrying about code structure later.
> 4. What is the use of OSGi services in e4? So far I have seen there is
> an IEclipseContext which allows you to fetch services like the old
> IServiceLocator in 3.x does. What about putting more services directly
> into OSGi (that are not local to any part of the workbench)? I would put
> my declarative services to more use depending on the workbench services
> available. For instance, now in 3.5 I export the IWorkbench as a service
> myself and have my other services consume it. Similar to the
> ISelectionService, IProgressService and others.
These services (selection, progress) typically cannot be exposed as OSGi services because there can be many instances of them. I believe the e4 whitepaper explains the story behind this well: http://eclipse.org/e4/resources/e4-whitepaper.php
> 5. I actually like the idea of being able to define the layout of RCP
> applications. Currently I have gone through great pain to have a custom
> view on top of each perspective that you can not close/move or whatever.
Thanks! All kinds of wonderful things are possible now - views outside of perspectives for example, or not using perspectives at all...
> Please understand my points not as criticism purely, I am sure for a lot
> of things there are good reasons just unknown to me.
>
> Said that, I am more than willing to contribute to e4 if possible after
> I got more insight on the processes going on.
>
> Keep up the good work!
Thanks again, and if you'd like to contribute, a possible start would be to help us switch to current OSGi programming best practices. Let us know, we are known to nominate committers on the slightest sign that somebody is interested in contributing.
Boris