[Eclipsedotnet-developers] Removing SWT dependency on IKVM

[<jpp...@gm...>]

This one is in regard to a feature request posted by Kunle at the SF.net
tracker. This feature request also touches a very delicate subject and =
(what
I think is) the Achilles=92 Heel of IBM=92s Eclipse (and, to a degree,
Eclipse.NET).

=20

For anyone who hasn=92t seen it, it reads:

=20

=20

=20

Remove SWT dependency on ikvm

=20

=20

In the current codebase, SWT support is enabled by the use of the =
excellent
ikvm toolkit. This means SWT has been ported at all, just statically
compiled/run via ikvm.

This is a tactical decision that has speeded the delivery of the =
platform.
Nevertheless, it is less than optimal and a complete port of SWT to C# =
would
be the strategic goal.

I should note here that the SharpDevelop team attempted a port a few =
years
ago - called #WT - and their work may be of some use in this task.=20

**PLEASE READ THE #WT LICENSE CAREFULLY, ECLIPSEDOTNET HAS A LIBERAL =
LICENSE
AND THE #WT LICENSE MAY BE TOO RESTRICTIVE.**

=20

=20

=20

=20

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

=20

=20

And now, for my opinion:

=20

*************** BEGIN PERSONAL OPINION =96 PLEASE INSULT AT WILL (but =
behind
my back, please :-P ) *********************

=20

I believe SWT is not cross-platform, no matter how much the IBM/Eclipse =
guys
try to tell us it is cross-platform. I discussed this somewhat in
http://eclipsedotnet.blogspot.com/2005/09/whats-been-going-on.html . The
thing is, SWT uses native code and forces the code developer to ship =
his/her
product with swt.jar AND the dll for the OS in which it should operate.

=20

And WinForms (and by WinForms I mean SWF)? It=92s not cross-platform =
either.
Neither is GTK#. WinForms is an abstraction layer for GDI (only =
available in
Windows; and Wine, I think, but I=92m not sure). GTK# is just .NET =
bindings
for the GTK binaries.

=20

=20

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

=20

=20

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

=20

When one uses GTK#, the only thing concern regarding the UI system is
whether GTK# is installed in the target system or not. If the target =
system
is MacOSX, Linux, Windows or anything else shouldn=92t be a concern when
deploying the product; that=92s one of the ways I see the =93managed =
code=94
novelty (btw, I don=92t know if GTK# runs in MacOSX, but the point is =
still
here). In fact, that=92s the reason I adapted the native code of the
org.eclipse.core.resources plugin to managed code in the Core.Resources
plugin: so that the .NET framework handles the native part of the work.

=20

When using WinForms some time ago, one had also to worry about whether =
the
underlying OS was Windows. That=92s why I was very uneasy at the time I
started this project about making the UI in WinForms; I was getting =
tempted
by GTK#. But then the guys at Mono/Novell came to their senses and =
realized
that their .NET implementation would be much more useful if they =
included
something that many .NET developers use: WinForms. And so the worry of
whether Windows was the underlying OS or not was lifted, as Mono made =
SWF
available for the platforms in which it runs (Linux, Windows, MacOSX =96 =
I
don=92t know if the MacOSX implementation of SWF is complete or not, =
though).

=20

For the developer, this means that he only needs to worry whether the =
target
framework is installed (in the case of WinForms, Mono or Microsoft=92s =
.NET
Framework; in GTK#=92s case, Mono / .NET and GTK#) on the target =
computer; he
doesn=92t need to worry about the native components of the target =
computer at
all. Clearly not the case when distributing an SWT-based application =
(where
we must also include OS-dependent dlls).

In fact, the reason there are so many IBM/Eclipse download choices (one =
for
each OS) is exactly that: different zip files include different native
library dlls.

=20

And, worse yet, the compilation of SWT java source code is also
target-platform dependent (as you can see in
src_platform/java_src/org.eclipse.swt_2.1.3, there are multiple =
classpath
files, one for each of the target OSs). In fact, I think it is safe to =
say
that the only thing actually platform-independent in SWT is the API... I
think this clearly defeats the purpose of platform-independence that =
Java
was based on and, to be honest, this is the point where I most disagree =
with
the choices for Eclipse development.

=20

*************** END PERSONAL OPINION =96 NO MORE INSULTS NOW, PLEASE :-P
*********************

=20

=20

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

=20

Also, does everyone agree that SWF is the best way to go? Or would you
rather take the GTK# path?

=20

Opinions are welcome, these things need to be discussed.

=20

=20

=20

OK, sorry for the lengthy mail, but I think this is a subject that =
should be
well discussed before any decisions are actually made and implemented.

=20

=20

Regards,

JS

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20