[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-swt-dev] SWT port for Swing!
|
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
>
>