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
