RE: [ve-dev] Plan issues to discuss

[Dave Orme <DaveO@xxxxxxxxxxxxxxx>]

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
>