Skip to main content

[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))

Title: 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.
 
 

Back to the top