[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-swt-dev] Re: FW: SWT History and Design Decisions ( WAS: [platform-swt-dev] AWT Toolkit using SWT (was: From Swing to SWT))
|
Hi Dave,
Is there a higher order document such as the API Docs allowing me to get
a gestalt of your contribution? Can I download a working version of the application?
Did you look at the API docs or the mvcGuide.pdf I referred to in my last
post to see what kind of distance exists between your contribution and Conga?
Conga represents thousands of hours of excellent design, implementation and
testing. It is shipping and working today. How far away are we from producing
a tool such as Conga using your development? Can it now and will it be able
to be given to a non-programmer to construct a GUI?
Thanks,
Lane
Dave Orme wrote:
Message
Hi Lane,
First, I am not absolutely certain that multiple choices for a SWT
GUI Builder is bad. If there ends up a couple of Builder choices down
the road, this may make SWT and Eclipse more vibrant. <<SNIP>>
Perhaps I didn't communicate clearly enough: We
don't disagree on the point you raise above. To the contrary, we agree
that there is room for many SWT GUI builders and that choice and competition
in the market is a good thing! :-)
About
a week ago, you were asking for input about how to approach supporting SWT
in your GUI builder. The official response from the SWT team was, "Develop
an adapter (or GUI builder API) layer."
However, upon reading that, our concern was that if (for example) you write
a SWT GUI builder API layer and we write a separate SWT GUI builder API
layer and Scott and Ramen also write their
own SWT API layers for their respective SWT GUI builders, that a
market for third-party SWT custom controls will never succeed. This is
because third party custom control authors would be forced to decide what
GUI builders to support, thus fragmenting
the market for SWT custom controls. Consequently, the market for
the GUI builders themselves would be likely to remain small because the
usefulness of a GUI builder is partially related to the wealth of its corresponding
third-party custom control market.
To mitigate this risk to all of us, Advanced Systems
Concepts would like to work together with all other GUI builder authors
such as yourself, Scott, and Ramen to agree on a common SWT API layer that
we all will support. We also believe that such a layer
ideally belongs inside Eclipse itself rather than maintained and managed
by any of our respective companies.
The result was that (as one of the other developers
on the list put it), we put our money where our mouth is:
Since we had already created a GUI builder API
layer for SWT, we open-sourced it as a starting point for everyone's Eclipse
GUI builder API and opened bug #30022 as a place for public comment on the
matter. We attached the complete source code (licensed under the CPL) to
the bug report and invite your, Scott's, Ramen's, and anybody else's comments.
Coming
back to where we started this whole discussion: about a week ago you asked
for input about how to approach supporting SWT in your GUI builder. Now
you don't even have to develop the layer the SWT team proposed. It's available
to you, free for the taking under the same license terms as you got Eclipse
itself. :-)
If
you don't like something in the API, let's discuss your concerns on Bugzilla.
We can all decide by vote which ideas to include in the final API. And
hopefully, our friends in SWT development will see fit to include our collective
result as part of Eclipse itself. ;-)
Let's write some great code together. I apologize
if my previous post was unclear about our intentions. :-)
Best Regards,
Dave Orme
Advanced Systems Concepts
PS: I'll post a similar message momentarily on
e.tools so all stakeholders will have fair notice of this opportunity.
--
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO