e4 0.9 review - 01 - on the road
After some recent job interviews and ecmascript 5 specification(final draft) reading, I have the breathing time in this weekend to come back to our Eclipse community. I find that there is one trend for me to do a lengthy blogging. One reason for this is that I'd like to discuss the useful, not trivial technical aspects of Eclipse evolvement in our community at least. However, this need a long time to prepare the contents usually in the span of one week or more. Maybe I can break one lengthy blog article into more short ones to make my life easier?:)
To my surprise, there are only several pieces of blogging targetted to the e4 Feedback Contest, compared to the huge number of reviews in the recent Galileo blogathon. Maybe the prize of the contest is not big? I have got one Eclipse shirt in the past. Yeah, it's great. To make me to write this review(oh, maybe a series), it is the McQ's words. This blog article is the longest one I've seen in our Planet, which address the current status of e4 and how the committer think the e4. As a healthy ecosystem, it is the responsibility for the committers to discuss the big changes before they made with the community. I really appreciate the McQ's work. So, he hope to get the feedback from the community, and I hope to give the feedback to him.
Like my Galileo review, I will not repeat the common basic informations about the e4 here. You can find enough stuffs at [1][2][3].
I review as the follow,
Compatibility:
I test the templates binding with the plugin creation wizard. For the plugin, the compatibility for 3.x plugins seem nice. Because the main existed concepts of framework have not been changed. However, all of the 3.x RCP application templates can not run on the e4 platform directly. That is a question: the 3.x application is a e4 application as well? The answer is "YES". The e4 has a provide a compatibility layer. The problem is, why we can not run the 3.x RCP application. After simply browsing the sources, I get the key to solve this problem: you can add a "applicationCSS" property to the product extension to guide the legacy workbench environment working for you. Here is the "RCPMail" product.
Usability
General
The default legacy workbench inherit the main face of recent Galileo platform. So, you can not see more wisdom from the a bit ugly face. In fact, there are some common but trivial unfinished parts in the e4 0.9(said by McQ's blog).
odd "Design" top menu
- No toolbar for workbench
- views don't support the layout
- no saved last preference
- clicking the current breakpointed statement in "Debug" View will not location of the sources when debugging ...
- hard to close one editor if there are many opened editors
- bad performance when the running time become long
Modeled UI
The Modeled UI capabilities could be played with "UI " in the top menu "e4". This is my interesting part. One reason is that I am a EMF fan. The EMF has many designs to make you happy at the Eclipse world. The dependency is one kind of responsibility. Although great Ed is still there, I hope the whole of platform with million of users dependency will not be too heavy for EMF.
Still, one obvious bug for the attribut "visible" existed.
Declarative UI
The eye-catcher of e4 is the capability of the declarative UI. There are two demo products shipped with e4. They are the standard e4 products. If you want to see how to code one new e4 powered application, see those demos. I am not a UI fan, I don't use any UI theme in my Windows desktop environment. So, I just enjoy the photos of our committers:)
Wisdom behind the e4
The most important things are the back-end ideas behind the shining or ugly face. The programming model(new?) and thus the different language support is the next milestone of Eclipse as a Utopian platform. These topics will be addressed next.
Summary
Yeah, the e4 is on the wonderful road. As a platform, I agree with the direction of e4. However, please carefully choose e4 dependencies. Hopefully, make all additions in e4 optional as possible. If one user don't like to change the skin or model something(he just want to edit his Java codes), will we force the 200+MB bulk to his disk?
No comments:
Post a Comment