[news.eclipse.platform.swt] Re: Swing port is coming - Lotus assists IBM

[Radu Racariu <rracaru@xxxx>]

Hannes Agus wrote:
> > 1) Mac SWT; give cocoa a try
>
> is already used.
no; carbon is used. please see the mess it does on SWT_AWT integration, 
meaning it is broken; cocoa could bring better integration with AWT, 
true aqua look and better performance
> > 2) QT SWT port
>
> won't be done - since QT's licensing model is not really compatible to 
> what IBM wants to do with Eclipse. In fact everybody who wants to deploy 
> his applications with QT/SWT would have to pay 2000$.

I was pointing out that this should be done by eclipse community and not 
by IBM, IBM doesn't have to dictate what goes in or out. if the 
community around Eclipse needs this port the answer will come from 
inside the community leaving politics behind. to bad that some nice work 
in not blessed by eclipse swt team, like http://swtfox.sourceforge.net/

> > 3) squeeze every bit of performance/stability from GTK port
>
> they are sqeezing since how long - 2 years now??
ok, and swing took what? 7 years to be in the shape that most end 
users(read the consumer of the final app) can be at least not irritated 
by how it performs? as a side note please don't take this as a start for 
the holly war of api's. i think that swing is nice in some parts of the 
design, but the implementations suck (-apple).
> > 4) add more features/fix bugs to SWT
>
> SWT is limited by design to a very small number of features. The more 
> features you add, the less stuff can be used from the underlaying 
> platform. (e.g. all complex widgets in the motif port are emulated)
>
> Although yous suggestion would maybe help in some areas there would be 
> still three main problems:
> - portability to platforms where no swt port does exist. (but if java 
> exists, swing does also)
> - skinnable ui at application logic.
> - restricted platforms like applets or webstart applications.
>
> Furthermore your suggestion would definitivly require 2-3x the work a 
> swing port would require and would still not solve any limitations 
> reported above.
ok, I'm pretty happy with what swt is right now, the more features 
direction could be addressed by a supper project based on swt and this 
could come from inside eclipse consortium or from outside; 
http://www.swtplus.com/ is an example.

and as a general conclusion i was just expressing my concern that this 
effort will affect the progress of swt as it is done right now, and if 
someone wants to do this should be done from outside of the core swt dev 
team, like it was done by the guys at 
http://sourceforge.net/projects/swtswing
> regards, Hannes