Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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



Back to the top