[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [ve-dev] Plan issues to discuss
|
I noticed that I called the next version of VEP, VEP 1.5. In keeping with
Eclipse numbering schemes, this will be changed to VEP 1.1.
> -----Original Message-----
> From: Dave Orme [mailto:DaveO@xxxxxxxxxxxxxxx]
> Sent: Friday, October 29, 2004 12:59 PM
> To: ve-dev@xxxxxxxxxxx
> Subject: [ve-dev] Plan issues to discuss
>
>
> All,
>
> I received notification while I was out of town this week
> that I have until
> *today* to submit our proposed development themes to the
> Eclipse Requirements Council. So I apologize in advance for
> the late notice this gives everybody.
>
> Fortunately, this decision won't be binding; it is just
> feedback we need to give to the Requirements Council that
> they will factor into the overarching requirements that they
> will drive back down to the development teams.
>
> Also fortunately, I don't think we have anything very
> controversial to say, so I'm going to post what I believe are
> draft themes are in this message and contact the active
> committers by telephone and IM today to drive consensus. I
> apologize in advance if I can't contact you today.
>
> So without further ado, here are my proposed VEP 1.5 themes
> and how these will break down into plan items (again, this is
> considered by all parties to be a draft, and will not be binding).
>
>
> Overarching Theme: Platform Maturity
>
> With VEP 1.0, we have delivered a platform that is functional
> on Linux/GTK and is very usable on Windows. Further, we have
> implemented all of the minimum features required to support
> both the Swing and SWT widget toolkits, in standalone and in
> Eclipse Rich Client Platform applications.
>
> VEP 1.5 will focus on improving, maturing, and solidifying
> our existing support.
>
>
> Within that framework, I propose the following plan items for VEP 1.5:
>
> 1) Platform Performance. (Committed Plan Item)
>
> Put simply, VEP can be faster. We intend to do whatever
> rewriting and refactoring is necessary in order to make the
> experience of using VEP as pleasant and usable as possible
> from a performance perspective.
>
> 2) API documentation. (Committed Plan Item)
>
> Currently, all APIs are internal APIs. We will begin the
> process of solidifying and documenting APIs. This work
> depends on the Platform Performance work, because some of the
> performance optimizations we consider may have the effect of
> breaking our current (internal) APIs.
>
> 3) Evolve Rich Client Platform Support. (Proposed Plan Item)
>
> Currently, Eclipse's Rich Client Platform is supported by
> VEP's ability to edit an arbitrary Composite. It would be
> nicer to have more complete integration.
>
> 4) Support Eclipse's FormLayout and JGoodies FormLayout
> layout managers. (Proposed Plan Item)
>
> One of the first things we would like to document is how to
> extend VEP to support custom layout managers. Subject to
> time constraints, we will implement one or both of these
> layout managers in VEP and document how we did it to assist
> with future layout manager integration efforts.
>
> It is extremely likely that the implementation of both layout
> managers will be contingent on receiving adequate volunteer
> help from the Visual Editor Project open-source development community.
>
>
> Comments/concerns/etc. welcome. What I have by 4:45 CDT is
> what I'll send John D.
>
> (Please remember that this isn't our final plan and it isn't
> binding. It's just our input to the Requirements Council.
>
> Again, apologies for the late notice as I was out of town
> when this request was made and am still unburying myself.)
>
>
> Best Regards,
>
> Dave Orme
>
> _______________________________________________
> ve-dev mailing list
> ve-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/ve-dev
>