Thursday, September 08, 2005

What's been going on...

Those of you who have gained an interest in what could be the outcome of this project may have been wondering about its (apparent) lack of activity. Well, truth is, I have been working around the clock on this; so, no time for bloggy-stuff... :P
Well, now for the important stuff: I developed a (rather buggy) prototype (still based in SWT) in the context of my graduation. For those of you wondering, this prototype was based on the source-code of Eclipse 2.1.3 (I didn't go for 3 because of the trouble of converting the OSGi platform; in its core, 2.1.3 is much more simpler); most of the code was converted using JLCA and some other parts of the code (not too many, luckily for me) I had to re-implement. When I remember to do so, I will make this prototype available in the Sourceforge.net (SF) project site.
Since the time when I (finally) put this project on SF, I have been cleaning up the code, removing (some) dead code, changing documentation formats, etc. In other words, house cleaning.
However, what I don't lack are ideas for Eclipse.NET, one of which is the adaptation to WinForms. Truth is, I don't like the way we have to develop the UI in Eclipse: we have to develop the code by hand, in an era where any RAD tool that deserves that title provides a way to visually design your window and quickly change its look. Why the heck should we have to design Eclipse.NET windows by manually coding? It's insane, if you ask me.
However, like everything else in life, this issue has two sides: the one I have just presented and its reverse: in some ways, WinForms is more limited than SWT, for example in layout management terms. Sure, you can use the Anchor and Dock properties for WinForms controls (and Splitter controls and etc.), but some situations just beg for layout managers. Good news is: the guys at Microsoft have finally included this in WinForms.NET 2.0, in the form of a TableLayout and FlowLayout. Good news for those of us who don't like to code in the layout of the form manually, into the Layout() event :) . And good news for me :D .

Another issue is cross-platform interoperability. There have already been great discussions (they didn't involve fist-fighting, as far as I know; but I could be wrong... :P ) about whether SWT should be considered as a cross-platform windowing toolkit or not. Why? Just continue reading.

For those of you who don't know what SWT is, it stands for Standard Widget Toolkit and it's supposed to be what AWT should have been (I say "supposed to" because I read this somewhere; I leave it to others to evaluate if SWT lives up to that objective). It consists of Java code that uses the underlying operating system native widgets and emulates widgets not available in a given platform. I highlight the word "native" because that's exactly what they are: they are invoked directly to the underlying OS, using JNI. Therefore, you can't take a windows version of Eclipse and start working on it in Linux: the SWT binaries are different. I referred Eclipse here because it is based on SWT, but I could have referred any other application that uses SWT. (OK, I'm kind of lying here; you CAN use windows Eclipse in Linux, but you would be limited to a text-version of the platform... :P Also you would have to get the plugins to supply the text-version yourself...). And the big discussion I mentioned in the previous paragraph is due to exactly that: SWT uses native code; but it also uses platform-independent code (in Java).
Should SWT be considered as platform-independent?

I'm evil; I won't give you the answer. :P

Well, back to the point. What made me reluctant to take Eclipse.NET and adapt it to WinForms was exactly that: cross-platform interoperability. Mono has been growing fast lately, and it's making the .NET platform a reality in multiple platforms (Linux, Mac, etc.). The problem with it was the windowing toolkit: applications that used WinForms (i.e., that you could run on Windows) could not be run in Mono (understandable, as WinForms can also be considered a wrapper for GDI+). However, the Mono team has recently started developing WinForms for their platform. This means that, in the future, WinForms will be a reality in platforms other that Windows.
It was this, combined with the fact that WinForms provides us with some very cool control features (like DataBinding), that made me decide to adapt Eclipse.NET to WinForms. All I'm waiting for is .NET 2.0, and its Layout Managers. I can barely wait to get my hands on those TableLayouts... :) Hopefully, some time from now, we will be able to create windows for the platform from within the Visual Studio winforms editor (or whichever visual editor you use).

Well, I'm tired of writing now.

JS

4 Comments:

Anonymous Kunle Odutola said...

Hi João,

Just found out about your project and this blog. Sound like a useful venture.

Questions/Comments:
1. Is this a full port of Eclipse v2.1.3 to the .NET platform?

2. Is this a true port to C# or, an ikvm-enabled port?

3. Does Eclipse v2.1.3 include a GUI designer for it's SWT-based UI library?

4. If (3) is true, you may want to consider simply adding a WinForm GUI designer to Eclipse.NET (rather than replacing it's SWT underpinnings with WinForms). When Eclipse.NET's GUI designers matures, you can use Eclipse.NET to (re)design it's own GUI.

Of course, WinForms may still offer more in the way of thirdparty controls (although most aren't open source).

5. Is Eclipse.NET open to contributions?. Is there an accessible CVS/Subversion/etc depot somewhere?

Kunle

Tuesday, November 22, 2005 1:39:00 PM  
Blogger João Saraiva said...

Hi, Kunle!

As for your questions, here are the answers:


1. It is intended to start as a (as complete as possible) port of Eclipse v2.1.3 to the .NET platform. However, the original plan is to make it evolve into a new platform, as .NET-oriented as possible, in the sense that IBM's Eclipse ends up just being the "grandfather" of this new platform :P . But please note that the future of the platform is always open for discussion. So, if anyone has ideas for it, please feel free to present them :) .
As for the current state, I can tell you that the Core plugins are pretty stable (i.e., Core.Boot and Core.Runtime run with practically no problems, although this probably means that I'm not testing them extensivelly enough). The SWT UI is also presented to the user, although there are a few problems here and there (mostly derived from the conversion using JLCA and from some bugs of Resharper). The Debugging framework has not been ported yet, although I'd like to start that sometime in the near future. I would also like to start serious implementation of the testing framework of Eclipse, so in my spare time I've also been looking at the NUnit framework (I consider this part to be of VERY high importance).
The objective of this project is to last (i.e., it's not just to make a platform that'll be dead in 1 or 2 years) and to (try and) bring some innovation to the IT industry. This reminds of Nike's(?) slogan: "Don't immitate. Innovate." :) .


2. For the time being, it is in part an IKVM-enabled port (because of SWT, and i'm also temporarily using IKVM to port some - relatively independent - plugins, like org.eclipse.draw2d_2.1.1 or org.eclipse.text_2.1.0, to the .NET platform; this allows us to elliminate some bugs that would inevitally come from porting task), and also a full C# port (the Core plugins are completely in C#, as is the most part of the UI - with the exception of SWT, which is using IKVM).
But the plan is to, eventually, change the windowing system to WinForms and release ourselves of IKVM completely (it's not that IKVM is bad; in fact, it is excellent software; but as long as IKVM is still in use, the question "why not just use IBM's Eclipse with IKVM?" will haunt the minds of everyone who sees this project for the first time).


3. AFAIK, v2.1.3 does not include a GUI editor for SWT. I'm not so sure about Eclipse 3.x, but I remember reading something about a project (for Eclipse, what else? :P ) called "Visual Editor". I think it also enabled users to develop GUIs based on SWT, although I am not really sure about that. I'll check it out (when I have the time; my MSc is turning out to be quite time-demanding :'( ) and get some info here ASAP.


4. That's an excellent idea! Even if there turns out to be no SWT GUI editor for Eclipse, I don't see why we can't/shouldn't create our own. :)


5. Absolutely! Eclipse.NET's source code repository is located on SourceForge.net (http://www.sourceforge.net/projects/eclipsedotnet). For the time-being, SF only has support for CVS (although they are preparing to release a beta service of SVN, according to their latest news).
Also, any contributions are more than welcome. If you (or anyone else) wishes to contribute, you will need developer access to SF's CVS repository; to get that, register with SF (if you haven't already) and apply to join (or something like that; I don't know the exact steps for that). Also, you can send me e-mail to joaosaraiva@users.sourceforge.net with your username for SF, so I can add you to the developer list.



Well, thank you for your questions and comments!

Also, if you'd like to download an updated (version) of Eclipse.NET, feel free to browse to http://ottawa.inesc.pt/eclipsedotnet_files/ and download the zip file there (I'm having trouble logging in to the Admin page in SF.net, so a new Release will have to wait a bit :( ).


Best regards,
João Saraiva

Tuesday, November 22, 2005 2:28:00 PM  
Anonymous Kunle Odutola said...

Hi João,

Scratch my comments about keeping Eclipse.NET as an app written using a C# port of SWT.

SharpDevelop's SWT# project is dead and Mono's new Managed WindowsForms (MWF or SWF) implementation seems to be progressing nicely.

It may be too much work to maintain C# SWT ports for the leading OS platforms. Unless you decide to build a Managed SWT (ala Mono's managed SWF)...

Kunle

Tuesday, November 22, 2005 2:35:00 PM  
Anonymous Kunle Odutola said...

Hi again João,

I guess I should really be using your mailing list on SourceForge for this but, here goes...

Your latest binary release

I have downloaded and tried your latest release. I can report that it starts up fine under .NET 2.0, the menus are functional and, the About box works (complains about missing info if you request more info about some plug-ins). It seems to run slowly though this might be due to debug-compiled assemblies and/or Eclipse itself. Eclipse v2.1.3 wasn't exactly a snappy application.

One snag, it barfs if it is run from a directory that has spaces in the full path.

There were also a number of entries like the ones at the very end of this post in the file RuntineTraces.txt.

Replies to your points

1. I understand that it will diverge from Eclispe once it is up and running.

I'm familiar with NUnit. Once I get the latest sources, I'll have a look at the testing framework. We should really co-ordinate this on SourceForge.

Would the Debugging Framework still apply on the .NET platform. Is it sufficiently generic?

2. I've come to agree with you that Windows Forms (SWF) is the way to go for .NET version. I hope we can still keep the JFace/SWT support though. They offer a richer model that SWF.

5. Is the latest code usually in CVS?


Example of entries in RuntineTraces.txt


Activating plugin: Core.Runtime
Plugin activation stack:
Core.Runtime
Class loading stack:
Stack trace:
at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
at System.Environment.get_StackTrace()
at Core.Internal.Runtime.PluginStats.TraceActivate(String id, PluginStats plugin)
at Core.Internal.Runtime.PluginStats.StartActivation(String pluginId)
at Core.Internal.Plugins.PluginDescriptor.DoPluginActivation()
at Core.Internal.Plugins.PluginDescriptor.get_Plugin()
at Core.Internal.Runtime.InternalPlatform.ActivateDefaultPlugins()
at Core.Internal.Runtime.InternalPlatform.LoaderStartup(Uri[] pluginPath, String locationString, Properties bootOptions, String[] args, IExecutable handler)
at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Core.Internal.Boot.InternalBootLoader.Startup(Uri pluginPathLocation, String location, String[] args, IExecutable handler)
at Core.Internal.Boot.InternalBootLoader.Run(String applicationName, Uri pluginPathLocation, String location, String[] args, IExecutable handler)
at Core.Boot.BootLoader.Run(String applicationName, Uri pluginPathLocation, String location, String[] args, IExecutable handler)
at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Launcher.Launcher.BasicRun(String[] args)
at Launcher.Launcher.Run()
at Launcher.Launcher.RunEclipse(Launcher launcher)
at Launcher.Launcher.Main()


I would have investigated further and tried to fix the issues I found but, I no longer have the latest code ;-). Is this in CVS?

Thanks

Kunle

Tuesday, November 22, 2005 7:55:00 PM  

Post a Comment

Links to this post:

Create a Link

<< Home