So, we've not entirely made the progress on ConnectBasic that we'd wanted to in the last week or so, but despite the lack of checkins it's not for a lack of effort.
Rob has been looking at implementing optional parameters which introduced some rather interesting new requirements for the parser - up until now we hadn't needed a look-ahead mechanism but Rob has had to look at implementing one, I'm sure he'll talk more about that in good time.
My principal focus over the last week or so has been thinking about how to port ConnectBasic to other systems and as I'd been thinking about taking a look at the world of Apple for a while, I decided to get myself a MacBook Pro and start hacking around.
I must confess to having unrealistic expectations about the effort that would be involved, I'd seen plenty of posts about IronPython and other DLR projects on Linux/Mac and surmised that my biggest problem was going to be porting the UI - and, while the UI is certainly the biggest problem, it is far from the only one.
I, perhaps naively, figured I'd be able to grab the code from subversion and just run xbuild (Mono's version of MSBuild) on each of the core projects (i.e. the non UI ones) - I couldn't have been more wrong. Unfortunately it turns out that xbuild is pretty embryonic at best and couldn't locate the CSharp targets files required by the projects, unfortunately the hour or two I spent searching the web was fairly fruitless - this is a project with a lot of promise, but on the Mac at least, it seems to be a long way off usefulness.
So, I decided to leave xbuild behind for the time being and try out MonoDevelop - now to be fair this is very early days for MonoDevelop on the Mac and I'm pretty impressed with how well it works so far, though the version I'm running doesn't support interactive debugging and various other niceties that Visual Studio has lavishly spoiled me with. That said - it worked, it all compiled! and more importantly the Windows Forms support seems to be pretty good from my limited testing so far.
Which, brings me on to the next problem, the code editor. As things stand ConnectBasic uses a WPF code editor, something I'd always know would be a problem but I figured it'd just be an (albeit not-easy) case of writing a new text editor from scratch using GDI/GDI+, boy could I couldn't have been more wrong.
On a side note, it might be possible to use the RichTextBox to build a code editor but there are two major problems with this:
1) on Windows at least making modifications to the RichTextBox involves selecting the text to be changed and changing it, which is astonishingly appalling abysmally slow, and though you can P/Invoke a Win32 API to suppress drawing of the Window while you do this to speed it up, it's a blunt instrument and very hacky.
2) It's far too limited, obviously the goal ultimately is to have a good quality code editor with line numbers et al, the RichTextBox, as is characteristic of most WinForms controls, is virtually completely unextensible in any meaningful way.
So, back to writing a new code editor from scratch. If you remember .NET before v2 you'll probably also recall the various problems around text rendering, this was because v1 and v1.1 both used GDI+ for text rendering, which unfortunately has various problems, e.g. it's slow because unlike GDI it isn't hardware accelerated, it doesn't have good support for other scripts (do a search for Michael Kaplan's discussion of this for more details), and there were various problems with the way it performed kerning. Disclaimer: I'm certainly not an expert on the very difficult topic of text rendering but there's some great discussions about the deficiencies of GDI+ in this regard.
So, realistically, that left me with GDI - except it doesn't. GDI support for .NET applications is provided by static methods on the TextRenderer class. Of which it provides two, with various overloads of each: DrawText and MeasureText, and MeasureText is the cause of the problems. MeasureText simply returns the bounding size of the input text - there's no information for individual characters, which adds up to a code window which you can't use a mouse with. Not great.
At the moment I've not really got a solution for this problem, I'm thinking about a few thing:
1. Writing a prototype using GDI's MeasureText anyway by measuring successively long sequences of text, but it strikes me that this would probably be slow, and I've a gut feeling it'll probably end up not working anyway.
2. Some how hosting a Silverlight/Moonlight control inside a WinForms control so that we can use WPF instead which would seem to have much better text support. I'm really not sure about this, but it could work well if it's doable.
3. Having two completely independent UIs on Windows + Mac, one based on WinForms, the other based on Cocoa (something I'm still in the process of learning) and using a Cocoa/.NET binding. The biggest problem with this is it just avoids the problem which I'm going to come across again when we do a Linux port, so I'm really not keen about it.
4. Giving up on WinForms and trying something like GTK# instead. This seems to be a good possibility but GTK# apps don't seem to play well with Mac user's expectations, they seem to feel very "Linuxy".
So, I've not really got any concrete answers, I'm still exploring the various options, and there doesn't appear to be much in the way of help/tutorials/information about porting .NET apps to Mac in the Internet at the moment, hopefully that's something that'll change in time. If anyone knows of a .NET on Mac community I'd be very interested in hearing about it.
So, with that said, I'm going to switch priorities for the time being, I'm still going to be looking into porting to the Mac when I get time here and there, but for now, I'm going to be focusing on the ConnectBasic hosting API - so that host applications can provide their objects to macros effectively, and also so they can control built-in functions such as IO capabilities to allow macros to run in sandboxed environments.
