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