Home › Journal › 2008

Journal for August 2008

Web Application Projects in MD and VWD

Fri, 2008-08-15 19:45 — Michael

I'm very pleased that Visual Web Developer Express 2008 has now gained Web Application project support in Service Pack 1. This means that MonoDevelop users will be able to share ASP.NET projects with VWD developers.

For those of you who haven't heard the story behind this, Web Application projects are support for developing your ASP.NET site as a project. Although VS.NET and VS.NET 2003 did this, it was removed in VS 2005 in favour of "Web Sites", which consider a web site to be a directory. As I'm sure you can guess, the latter system is convenient for editing websites in-place — and they even had FTP support for this purpose — but in my opinion it's a poor system for well-structured development. Clearly other people thought so, because Web Applications were added back to Visual Studio 2005 as an optional addon, and included in VS 2008. Finally in VS2008 SP1, it's reached the free version. The reason for this is quite simple; it's a necessity for proper ASP.NET MVC development.

At the moment, MD trunk does a passable job of opening projects from VWD 2008 SP1, but building and deployment isn't so great, because when I originally implemented these, I had to work around some of the limitations in MD's build and deployment system. These workarounds aren't quite compatible with the MSBuild projects from VS. I'm currently trying to make this seamless by tweaking our MSBuild loader to more closely match the MSBuild build targets and file copy semantics, making the MD deployment system slightly more generic, and implementing the build and deployment targets "correctly" for ASP.NET projects.

Support for importing Web Sites may come later, but for now, it's good to see that we can now interoperate with Microsoft's free ASP.NET development tool.

Demoing Mono in Games

Tue, 2008-08-05 21:03 — Michael

I'm trying to plan some examples of using Mono in game development, so that we have time to get together some solid demos and samples for next year's GDC.

I'm primarily interested in showing how Mono fits into the existing games development ecosystem; we don't really have an XNA-like story for developing fully managed games in Mono at this point. The focus of the demos will therefore be:

  • How easy it is to embed Mono into a game and use it for scripting and gameplay programming.
  • How the Mono and .NET development tools make development faster, easier and more robust.
  • How Mono's performance compares to popular scripting engines such as Lua and Python.
  • (Possibly) using Moonlight as a Mono-scriptable, artist-friendly UI engine.

Does anyone know of any complete games or cool demos for which source or C/C++ SDKs are available, so that Mono could be embedded as a scripting engine? (I'm already considering Source Engine and Quake 3).

Nice ideas for demos would be useful too, though obviously developing a serious game from scratch is out of the question...

Building an IDE Navigation History

Mon, 2008-08-04 21:18 — Michael

MonoDevelop has a code navigation history. When you switch views, or jump around between definitions, it logs the history, and you can browse back and forth like a web browser. However, it has some major issues -- the history it generates is unintuitive and erratic. It seems like it should be a really useful feature, but in practice is frustrating to use, so I recently decided to give it an overhaul.

Unfortunately, navigation isn't an easy thing to get right in an IDE. It's easy to log too many points. For example, if navigation points are logged every time the user switches between all their open document tabs looking for something, it gets very cluttered.

The most important thing is how it fits into the users' code navigation, so I decided to blog in order to get some feedback on my current thoughts.

In my opinion the following actions should not trigger logging of navigation points:

  • Switching through files by control-tabbing or clicking on the tabs.
  • Jumping using the search pad or the error pad
  • Navigation between items using the document outline or the class browser
  • Moving the cursor around with the keys and/or mouse (but this should alter/update the existing nav point)

Whereas the following points should be logged:

  • The destination of a "Go to definition" command
  • The point that's left behind when executing a "Go to definition" command, if it's not too close to the current point
  • A jump to an event handler from a designer
  • Locations in which text is edited, though these points should be carefully pruned so that there are no more than one or two per file

In summary, only direct interaction with the document -- and in particular, large jumps -- should be logged.

How will this fit into your coding flow?