[news.eclipse.tools] Re: Eclipse SWT & Swing Coexistance - Help!

["Ilya Rozenberg" <irozenberg@xxxxxxxxxxxx>]

One thing for sure - SWT is a time saver for UI developers.
1. You don't have to straggle to make your interface look pretty.
2. Plenty of source code to look at.
3. Coding is simpler.


"Mike Walker" <michaelw@xxxxxxxxxx> wrote in message
news:9jkjvl$d8e$1@xxxxxxxxxxxxxxxx
> Veronika_Irvine@xxxxxxx wrote:
>
>
> I'm sorry, but this is a completely inadequate solution to geniune
> migration and functional issues that developers are running into trying to
> implement code on the Eclipse framework.
>
> Already, including ourselves, I know of three different groups with
> roadblocks which would be solved with real, supported SWT-Swing
> co-existence. One group needs Java2D to draw advanced graphics - another
> needs full Unicode support, and we don't have time learn the SWT and port
> our code from Swing.
>
> The AWT "plugin" is not an acceptable solution. The SWT should have a
> properly architected way of allowing heavyweight AWT/Swing windows
> (JFrame, JWindow, JPanel, etc) to be dropped into SWT container windows.
> With the correct SWT design this would not have been all that difficult!
> Why was this not done, and why is it not possible now? Isn't there anyone
> working on it.
>
> Sorry to be so negative, but I am genuinely disappointed by this issue.
> How many millions of dollars is OTI/IBM spending replicating AWT/Swing
> functionality (which is all 95% of the SWT is) just for a few new features
> (all I even hear is ActiveX support). And how many *more* millions of
> dollars will IBM and other ISVs spend learning SWT and porting Swing code
> to run on to of Eclipse??
>
> Mike Walker
>
>
> > What if I have existing swing code?<br>
> > The Eclipse platform is intend to foster the seamless integration of
> tightly<br>
> > coupled tools following a similar look/feel and behavior thereby
promoting
> a<br>
> > consistent experience for users on all platforms. Clients targeting
> Eclipse<br>
> > integration should use SWT based tools to ensure both tight seamless<br>
> > integration and portability. Clients with swing based components who
> cannot<br>
> > immediately take advantage of all aspects of the Eclipse platform should
> in<br>
> > most cases use mechanism #3 above (launch-tools yielding
> swing-in-process)<br>
> > as a stepping stone towards ultimately achieving tighter tool
> integration.<br>
> > The experimental internal mechanism for swing-in-place is discouraged,
> and<br>
> > should be used only after considering the risks and limitations as
> indicated<br>
> > above.<br>
> > <br>
> > /Greg<br>
> > Eclipse Platform Team</font>
>
>
>