Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ve-dev] Plan issues to discuss

Dave,

Do you know if these plan items have been published publicly anywhere
on the Eclipse.org website yet?  I know there's a Eclipse Project
Draft 3.1 Plan out there
(http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_1.html)
but I can't find any equivalent for the Tools projects.

Thanks,
 - Jeff


On Fri, 29 Oct 2004 14:16:24 -0500, Dave Orme <daveo@xxxxxxxxxxxxxxx> wrote:
> 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
> >
> _______________________________________________
> ve-dev mailing list
> ve-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/ve-dev
>


Back to the top