*thump* Ow, watch your feet, GTK#!

I spent a couple of hours yesterday prototyping up a UI in GTK#. My real problems started once I started doing anything beyond 'the basics' - scary exceptions that were being thrown from the bowles of gtk itself. I gave it another whack today and stopped immediately because I just ran into an error where the application crashed when I unsubscribed from an event. Not so unexpected is the fact that everything works fine when running under Mono (in Windows). 'cept I don't want to use Mono on Windows.

So, today, I was toying with wx.NET. It seems promising, but there's a lot of rough edges. A lot. There are many, many fields that take integers instead of enums, and practically everything is undocumented. Its a bit unwieldly, like using MFC, but the API is simplier and does not require the herculean efforts of strength required to make simple stuff 'go.' Still, its unmaintained - they only update the library to keep it in sync with wxWidgets, and I hate programming against dead-end APIs. 'specially ones that are not particularily polished.

I'm not sure what to do now. The main reason for using GTK# was because, although its chock full of annoyances when dealing with simple stuff, it is powerful enough to let me do some pretty cool things with a little less effort than the equivilent using S.W.F. Same goes for wx.NET.

I'm not sure what I should do now; I obviously can't continue with GTK#, but I'm hesitant to pick wx.NET. I don't know of any other crossplatform .NET UIs, and using S.W.F would be a pain in the ass and require some P/Invoking, I think.

Should I take another look at booclipse and try to integrate some of my ideas into it? I hate Java.

Boodle!

Boodle is a GTK# application I've just started working on: essentially, its meant to be what IDLE is to Python.

I definitely plan on doing code completion, colorization, and launching the interpreter in a seperate appdomain or thread - having the interpreter hang is a real pet peeve of mine. Hopefully I will be able to move Boo Explorer out of my daily routine and replace it with Boodle. ;)

Ah, Boo, where's your killer IDE?

Was playing a bit with #develop 2.0 again, and it makes me crave a Boo addin. I use the term "playing" loosely, since I have not really had much time to do anything yet.

I believe Daniel Grunwald is holding off until Boo gets generics support, which could be sometime in the far, far future.

booclipse is nice, and I hacked a little on it today, but immediately reverted the changes - I don't know if I just don't like the language, or I'm rusty, or what, but it was damn unpleasant and not really something I want to spend my spare time on.

MonoDevelop of course is not an option, since I spend a lot of time on windows, and boo explorer is only good for simple scripts.

I wonder if its possible to wrap the generics exposed in #develop addins with C#, then expose plain-jane arraylists to Boo? Still don't know much about the architecture, and I would be duplicating efforts by Grunwald, but if he really is waiting for Boo to get generics, I would have a quasi working addin a lot sooner than that, to be sure.

SharpDevelop 2.0: The Next Generation

Corsavy, the codename for SharpDevelop 2.0, one of the most anticipated (and easily most hated) .NET IDEs available, has opened its source code repository for contributors. Well, I'm not really a contributor, but someone gave me the link and I downloaded and installed Corsavy before I realized this. ;)

After the clusterfuck that was SharpDevelop 1.1 (you know what I'm talking about if you've tried to use it for any serious projects), the constant pushbacks for Corsavy, and a forum post indicating that Corsavy hadn't been touched in months, it seemed like SharpDevelop was R.I.P.

It comes as bit of a suprise then that out of the blue the repository for Corsavy was opened for public consumption, and to be honest, I'm a bit amazed: SharpDevelop 2.0 is very, very good for what they consider alpha quality code.

Its got some pretty sweet features; when you find all references for a type, for instance, they appear in a little search window at the bottom, colorized by syntax and divided by columns. If you've had to deal with Visual Studio 2005's "let's cram everything onto one line in the same color and hope it works out" this is going to be sweet, sweet relief to you.

By default they ship supporting NUnit, MbUnit, and SVN support. You'll find SVN support under "Tools" which doesn't make as much sense as if first sounds when you think of it, but that's a minor problem.

Also nice to find was that if you right click on a project you have the option of deploying it via ClickOnce, although it seems that functionality for assembly signing hasn't been completed yet: ever see a ListBox with the words "TODO" in it before? Scary.

Generics support is just as you'd expect: generics in code completion. There's a minor annoyance when creating a generic type, as when you type List the cursor automagically highlights the 'T' so you can supply your own type, but when you press '>' you actually create another bracket, so your code comes out looking like "List>." Smarter behavior would be nice.

Did I mention that the debugger works? We all know that's what you were waiting for. Long awaited, long requested feature, but its here.

Corsavy is snappy - the IDE loaded quickly, only briefly showing the new splash-screen, and hasn't crashed on me yet. They seem to have locked down the memory consumption bug concerning the UI in SharpDevelop 1.1, so now you can actually hack for a couple of hours without having to restart the IDE or have it crash then refuse to load the project file next start-up. ;)

Oodles of small goodies, but they're like the little mints you find on your pillow at night: you don't notice them until you're there, and when you do, you smile. ;)

There are still some missing features, though:

• No background compiliation to check for errors. After having used Visual Studio 2005 and Eclipse for quite a bit, its become a *must.*
• No contextual help for error messages. This removes quite a few short-cuts that Eclipse and VS2005 made possible: you can't instanize a new type, click on the error message, and automagically import the namespace that holds the type.
• Weak refactoring. You can't refactor local variables, apparently, and the refactorings for methods and classes are pretty weak, as there are no convience refactorings like "explicitly/implicitly implement members" for interfaces and abstract classes.
• 
• You can't "go to definition" or "find references" arbitrarily by left clicking in the source code; you have to use the little class/interface/property/field icons that appear to the left of the screen if you want to find references for a class. I cannot click on a local variable that is an interface and go to that interface's definition. I can't even "find references" for a varaible, which is sometimes uber useful!

With some serious polish as Corsavy moves into beta, this could seriously put SharpDevelop into the same competitive ring as Visual Studio and X-Develop.

Definitely something to keep my eyes on.

Eclipse Boo Integration?

I just finished and posted my first cut of Boo.Lang.CodeDom; its still missing some features, and I should perhaps implement the parser so it supports reading Boo files, too.

And what do I find to my suprise as I go onto IRC but Rodrigo (The Boo Creator) showing off work on Eclipse integration, by himself and Georges -- a mysterious, unknown contributor who is likely lurking in the shadows to murderize us all.

It looks really sweet; once it gets checked into SVN and I clean up CodeDom to an acceptable level I hopefully have the time to incorporate code completion for the editor and some other stuff. ;)

Screenshots here.

A Boo code generator in Boo ;)

Its most commonly known to .NET developers as "CodeDom", a language abstracted way to generate code in another language. ;)

I started rewriting Boo.Lang.CodeDom in Boo; the original was in C#, and had numerous bugs. I'm actually kind of suprised that it worked at all, but it seems the samples that shipped with Boo never really touched the broken functionality. To make sure this doesn't happen I've written a unit test for each and every expression and statement that can be generated by System.CodeDom, and about 34 of 39 unit tests are working.

I've been using the Boo.Lang.Compiler API to 'bind' CodeDom elements to Boo's AST, so it will always generate proper Boo syntax.

I'm a bit of the way there, and when I'm done, well... .... eh.

And to think, all this came out of me trying to fix an annoying bug in the C# version of Boo.Lang.CodeDom ;)