eclipsedotnet-developers

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

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

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

> Please don't post HTML mail to the list.

Sorry. I had Outlook configured to send html messages by default and I'm so
used to it that I don't even notice when I'm using HTML. Me bad :( .

> 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. 
> 
> 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.

And I never said otherwise. What I meant to say with all this is that, even
in distribution the developer does not need to create a distribution zip
file for each different target OS, i.e., 1 zip file for Windows, 1 zip file
for Linux, 1 zip file for MacOSX, etc. Instead, one only has to state in the
system requirements: "Needs the .NET Framework or the Mono Framework
installed.". Distributing SWT is like distributing WinForms :-P . But you're
right, the question at the core of this all is ubiquity and distribution, as
you mentioned.
Still, you have to admit that creating multiple distributions, one for each
OS, does *kind-of* defeat the cross-platform purpose of Java...
But I suppose that's a necessary evil, and we have to deal with it.

> 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.

SWF and SWT are somewhat similar in the way that they both use the
Single-Thread Appartment model. However, the differences between them can
turn out to complicate the implementation of SWT on top of SWF. One of those
differences is in the fact that SWF only exposes a small part of the Win32
API (as an example, you have the Tree control, but in SWF you can't use the
tri-state options that are available through the Win32 API - and which SWT
uses).
Maybe it would be best in the long run to use System.Drawing. Maybe some of
the SWT widgets should be emulated and others should use the SWF controls.
I'll take a look at these things and get back to you later (I'm not an
expert in this either :P ).

> 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...  ;-)

Personally, I think that the *really* important thing is not to cut
developers' wings. Therefore, we should keep their options as open as
possible/convenient and only prune their choices when we have a very good
reason.


OK. Taking this into account, I think it's safe for me to create a
subproject called SWF_UI in the src_platform module (like SWT_UI) and move
some of UI's content into it. That way, we can have the two projects running
simultaneously, so that one does not hamper the other.


Regards,
JS

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.10/189 - Release Date: 30-11-2005