RE: [Eclipsedotnet-developers] Removing SWT dependency on IKVM

[Kunle O. <kun...@vi...>]

Please don't post HTML mail to the list.

> I would like to have people's opinion on this: do you=20
> think that we should maintain the SWT branch (once=20
> WinForms/some other better windowing toolkit is up=20
> and running)?

Short answer? - "Yes".=20

Long answer? - "Maybe, it depends on whether we care about synergy with
Eclipse and on the resources available to us".

> And now, for my opinion:
=20
> I believe SWT is not cross-platform, no matter how=20
> much the IBM/Eclipse guys try to tell us it is=20
> cross-platform.

Well, if portability amongst the supported OSes is good enough for you =
then,
it is definitely CPE!

Where: CPE =3D=3D Cross-platform enough  ;-)

> I think the real question here is: "Where do we=20
> draw the line? When should we consider something=20
> to be cross-platform or not?"

When it runs on most/all of the platforms we care about. For many =
millions,
WindowsForms (even if it was Windows-only) is CPE!

> The major difference I see between SWT and WinForms / GTK#
> is that WinForms / GTK# are "frameworks" that effectively=20
> hide the underlying native layer from the developer, from=20
> code implementation time all the way to a "late" stage=20
> such as deployment time.

Isn't that true of Jface/SWT as well?.=20

AFAIK (and I'm not a Jface/SWT expert), the SWT API and Jface are fully
managed. Apps using Jface/SWT never interact directly with the native =
code
layer.=20

The real difference IMO is one of ubiquity/distribution. One is more =
likely
to find WinForms/GDI+ and GTK#/GTK on a system than Jface/SWT so, one =
must
be prepared to distribute all of SWT (managed and native) with one's =
apps.
=20
> But then the guys at Mono/Novell came to their senses=20
> and realized that their .NET implementation would be=20
> much more useful if they included something that many=20
> .NET developers use: WinForms.

And so must we. We have to support SWF. Period.

> And, worse yet, the compilation of SWT java source code=20
> is also target-platform dependent (as you can see in=20
> src_platform/java_src/org.eclipse.swt_2.1.3, there are=20
> multiple classpath files, one for each of the target OSs).
> In fact, I think it is safe to say that the only thing=20
> actually platform-independent in SWT is the API.

I think this is to be expected. The native code portion is different on =
the
platforms and so must the interface between the Java part and the native
code (if performance overrules an adapter pattern link).

> I think this clearly defeats the purpose of=20
> platform-independence that Java was based on and, to be=20
> honest, this is the point where I most disagree with the=20
> choices for Eclipse development.

You may be right but, Java also has JNI for a reason.

> Now, returning to the beginning question: do you think=20
> we should maintain the SWT windowing toolkit? If so,=20
> then a complete port to C# would be the best move, I=20
> completely agree on this. However, if not, maybe the=20
> development time would be better spent on starting a=20
> SWF-oriented re-implementation of the UI plugins (Jface,
> UI.WorkBench, etc.).=20

Well, SWT's API and Jface are fully managed code. It should be possible =
to
build a fully managed SWT/Jface on top of SWF (i.e. WindowsForms) or =
another
API.

I am not suggesting that we should do this btw, just pointing out that =
it is
possible. We might even build it on top of System.Drawing just like =
Mono's
fully managed SWF implementation.

Personally, I think leveraging the Eclipse guys work on SWT is easier. =
Our
C# port can continue to use an evolution of their native code layers. =
SWT
support on other OSes can be added when someone needs to scratch an =
itch.
All we need do is just keep the SWT code we have.
=20
> Also, does everyone agree that SWF is the best way to go?
> Or would you rather take the GTK# path?

SWF is a *must* I think. It may not be the best but we don't have the =
option
of not supporting it. Even the Mono guys came to realise that.

SWT is a little different. If synergy with Eclipse (including ease of
porting plugins between Eclipse and Eclipse.NET or maintaining a pluging =
on
both) is important, so is SWT support. It's a little richer than SWF, is =
CPE
for more platforms than SWF today and, is still being very actively
developed.

Priority-wise, SWF I think. SWT already works. Sort of...  ;-)

Kunle