RE: [platform-swt-dev] SWT port for Swing!

["Christian Gruber" <cgruber@xxxxxxxxxxx>]

If someone was going to make a "portable back-end" for SWT, it might be
better to make a straight-up Java2D raw implementation of button and
widget back-ends, without all the pluggable GUI stuff, since it's a drag
on performance, and you're limiting it by using SWT anyway.  

It's a cool idea, but you could actually make a high-performance
portable SWT backend in Java if you were willing to abandon the
(dubious) benefits of certain swing features.

Regards,
Christian.


> -----Original Message-----
> From: platform-swt-dev-admin@xxxxxxxxxxx 
> [mailto:platform-swt-dev-admin@xxxxxxxxxxx] On Behalf Of Liyu Liu
> Sent: Thursday, May 22, 2003 10:34 AM
> To: platform-swt-dev@xxxxxxxxxxx
> Subject: Re: [platform-swt-dev] SWT port for Swing!
> 
> 
> Just my 2c as some one new to this group.
> 
> It's interesting to have SWT over swing. However, IMHO, there 
> are at least three problems to be solved.
> 
> 1) SWT becomes at least as slow as swing. (slow)
> 2) People find swing's MVC design more flexible and don't 
> like the more restrictive SWT interface. (less flexible)
> 3) You have to emulate native UI again rather than simple 
> reused them. (it may be ugly, and reinventing wheels)
> 
> Weigh against the small and questionable gain, --more 
> portabitlity in theory but in reality doesn't pan out very 
> well. Actually SWT is proven to be more portable than swing 
> in real world and even better for native compilers like gcj.
> 
> SWT is what AWTshould have been. So it is probably more 
> useful to have AWT/Swing over SWT so that all the work of 
> swing can be reused and you can freely host AWT/Swing 
> components when flexibility is needed.
> 
> Also, it's needed to get SWT work in javabeans. Sun's 
> implementation will honor AWT/Swing only, but a good SWT UI 
> component frame work is important for the continuing 
> prospering of SWT.
> 
> 
> Luke
> 
> > Anyway, I think Swing is a really good idea for a port so that SWT 
> > applications could run without changing the code for the few 
> > non-supported platforms. Eventually developers could use some Swing 
> > specific code if they want (similar to OLE on Windows). 
> Moreover, SWT 
> > programs would work right away whenever a new platform with 
> new VM is 
> > out, while waiting for the real native port to be 
> developed. There are 
> > of course many other possibilities brought by such a port...
> 
> ^^^^^^^^^^^^^^^^^^^^^^^^
> These effort are probably more laudable in the unlikely case 
> we hit a hard wall in doing native SWT. 
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx 
> http://dev.eclipse.org/mailman/listinfo/platfo> rm-swt-dev
> 
>