I haven't had a chance to dig through the code yet (next day or two), but have you been using P/Invoke or any nonmanaged libraries? What would be the chance this project could be altered to work with Mono? If you're using VB.NET and C# this could very easily be a cross-platform application.

I haven't looked at the code in the slightest yet so this could be a ridiculous hope.

Yes I'm hoping to get Quest 5 working with Mono too. It's pure .NET - there's no P/Invoke, unmanaged libraries etc. so it should be relatively straightforward to get it working in Mono.

I had a bit of a play with MonoDevelop a few months ago and their VB.NET compiler doesn't handle everything correctly, so there would be a bit of work to get it to compile under Mono. But getting it just to run under Mono using the normal binaries should be easier.

The only complication I can think of is in the Player component. This embeds a browser, so Internet Explorer obviously under .NET, not sure what would be embedded under Mono. The Player component has to be registered via COM so that JavaScript within the browser can call the .NET functions. This probably won't work under Mono but there may be workarounds.

I'll see what I can do to get this running under Linux at least. I have Slackware and Debian running on another box, and I do plenty of development on that. From what I understand the Mono WebBrowser component doesn't have support for window.external.

This page has some useful information: http://www.mono-project.com/WebBrowser

I have Q5 compiling under Windows 7, and I'll see what I can do to compile it through Mono.

Ah, thanks, that's interesting. It's a shame that Mono doesn't support window.external because that's exactly what Quest uses in WebFunctions.js to implement ASLEvent.

Currently ASLEvent is only used in a couple of demo ASLX files for doing "custom" things on the interface, so it's not a big problem yet. Hopefully the hyperlinks will still work as that's done by handling the Click event on the HtmlElement.

There's a hacky solution to the lack of window.external support here: http://stackoverflow.com/questions/1084 ... w-external - maybe worth considering, or perhaps there's a better solution?

Have you considered using Gecko instead of IE? window.external is very IE specific, and I can't see proper support being added in Mono's WebBrowser any time soon (and WebBrowser development is kind of slow or nonexistent). It would probably be easier to do this than any workaround.

http://code.google.com/p/geckofx/

I'm slowly poring over what you have for Quest 5 right now.

I think you're right, that is probably the solution. Frankly I find the WebBrowser control a bit of a pain anyway!

I need to do some work on the (desktop) Player component to add in functionality which I've recently added to WebPlayer, so it's probably a good time to look at migrating it over to GeckoFX before any more significant work is done on it.

I think GeckoFX may be overkill for this problem actually - it will bloat the download hugely, and it will add a dependency on a COM object which I want to avoid if possible.

But the good news is I've now removed the requirement for window.external - the ASLEvent function is now able to bridge the gap between JavaScript and ASL in a different way, using a hidden div element which we add a click event handler to. It's not hugely elegant but then neither was the window.external solution.

The nice thing is this means we don't need to register the Player.dll component for COM interop any more, which means you no longer need to run Visual Studio in admin mode! Maybe it even means you won't need admin rights to install Quest either.

Latest code is uploaded to CodePlex...

I had a bit of a play with Mono the other day and the implementation of WinForms seems very glitchy - it was quite hard to get anything to run at all, and I had to remove a load of controls in order to do so.

I think a better approach will probably be to rewrite the front end for Mono. I don't think this should be too enormous a pain, as I've tried to keep the UI code totally separate throughout - we've already got two IPlayer implementations, the desktop Player and WebPlayer. So adding a third, say MacPlayer using MonoMac, shouldn't be too hard and it will give us a nice native UI on Mac.

I guess for Linux that Gtk# would the way forward?

If we want a cross-platform Editor that will be a bigger amount of work as there's more UI there, but again the way I'm writing it I'm trying to keep the UI component as small as possible, with the "real" work happening in the EditorController component which can be used as the basis for multiple Editor UIs in the same way.

I think for Quest 5.0, the IASL and IPlayer interfaces are now reasonably stable and unlikely to change significantly, so now would be a great time to start looking at a Mac version of the Player. Any volunteers?