Food for Monkeys

First beta of MonoDevelop 2.6

2011-03-02T18:21:00.001+01:00

MonoDevelop 2.6 beta 1 was released yesterday. Like every major release, it has many new features. Here is a summary of what have we done.

The first new big feature is support for GIT. This was long time due, especially since Mono and MonoDevelop itself moved to GIT. I already blogged about it a few months ago, but basically we are using NGit, a C# port of JGit, as the core for the GIT add-in. It hasn't been easy to make this port fully operational, but we now have a GIT core that can be easily updated and which is fully portable.

We have also spent some time improving all the version control views. I like especially the new changes view integrated in the source editor, and the log view (which btw can show gravatar icons of committers). We plan to keep improving those views to make them even more functional.

Another big change in this release is the new MCS based parser and formatting engine. Mike Krueger (in charge of the C# support) and Marek Safar (maintainer of the MCS compiler) have been collaborating to make the MCS parser usable in MonoDevelop. By using MCS, we'll be able to quickly have support for the latest C# features, and we'll be able to report syntactic errors on-the-fly that exactly match those reported by the compiler. Also thanks to MCS, the C# formatter is more reliable and will allow to properly implement on-the-fly formatting on all contexts.

We also added in this release support for user defined policies. The concept of "Policies" was introduced in MonoDevelop 2.4. Policies are settings which can be applied per-solution and per-project. Policies include settings like code formatting rules, standard header for files or naming policies. Until now, we supported setting the default values for those policies, which would be used when creating new projects. Beside this, we now also support creating named sets of policies. So for example, an user could define a "Company" policy set with formatting rules and file headers specific for company projects. It could also define a "Open Source" policy set with different rules. When creating a project, the user can then chose which policies to use.

Another feature we added is support for IL disassembly in the debugger. This will be very useful for developers that need to debug dynamically generated methods and assemblies.

Finally, we also have a brand new add-in manager, which is more functional and looks much better. MonoDevelop is now subscribed to the public repository available in addins.monodevelop.com, which is open to everybody for publishing add-ins and making them available to all MonoDevelop users.

Update: forgot to mention one important improvement that has been requested by Mac users for long time: support for native OSX dialogs. Message and file dialogs on Mac now use the native UI toolkit.

There are many other improvements and new features in this release. Take a look at What's new in MonoDevelop 2.6 if you want to know more.

gui-thread-check

2011-03-01T12:35:00.002+01:00

MonoDevelop often makes use of threads to run operations on the background. Although we make sure to invoke all GUI update methods through the main GUI thread, sometimes there is a bug and an update is done in the secondary thread, which causes all sort of random locks and crashes.

To make it easier to track down those bugs, I created a simple profiler module for Mono which can detect invocations to GTK# methods from a thread other than the main GUI thread. This module is available here:

https://github.com/slluis/gui-thread-check

To use it, build and install the module, and then run your application with
the command:

mono --profile=gui-thread-check yourapp.exe

If the profiler is properly installed, you'll see an output like this:

*** Running with gui-thread-check ***
*** GUI THREAD INITIALIZED: 2861676352

While the application is running, if the profiler detects a non-gui thread
invoking gtk methods, it will print a warning message together with a
stack trace. For example:

*** GTK CALL NOT IN GUI THREAD: Widget.gtk_widget_get_parent
Widget.get_Parent
SourceEditorWidget.get_TextEditor
SourceEditorWidget.get_Document
SourceEditorWidget.HandleParseInformationUpdaterWorkerThreadDoWork
BackgroundWorker.OnDoWork
BackgroundWorker.ProcessWorker

2011-02-04T14:43:00.004+01:00

I'm flying to Brussels in a few minutes, heading to Fosdem. I'm not giving a talk this year, but if you are interested in knowing more about Mono and MonoDevelop don't miss the Mono track on Saturday afternoon. Many nice talks, and a good chance to meet Mono developers and contributors.

NGit

2010-10-27T16:03:00.003+02:00

One of the features we want to include in the next MonoDevelop release is integrated support of Git. I committed a first version of a git add-in some months ago which works by invoking the git command and parsing the results. This solution satisfied some basic needs (Mono was moving to git at that time), but it was done as a short term solution, since parsing git output is not very reliable, and has portability issues.

The next obvious step was to use GitSharp, a fully managed .NET library which implements most of git commands. This library is basically a port of JGit, a Java library for doing the same. I started replacing the git invocations by calls to GitSharp classes, and I could implement the basic functionality, but I found some limitations that were not easy to overcome. On one hand, GitSharp was a bit outdated, lacking some of the recent features and bug fixes done in JGit. Bringing GitSharp up to date with JGit would be a lot of work, since every JGit commit had to be manually translated from Java to C#. On the other hand, GitSharp depends on a set of cryptographic libraries (required for the ssh protocol support) which we can't easily include in MonoDevelop due to export regulations.

I then decided to try a different approach: the idea was to use Sharpen, a free Java to C# translator implemented by db4o, to automatically convert the JGit code to C#.

After some weeks of work, I have been able to generate a C# library (which I call NGit) with all the JGit code. Most of the work went into tunning and fixing Sharpen, and into implementing in C# some core Java classes which didn't have direct replacement in Mono. This was more complex and took more time than I expected, but I think the effort is worth it. The generation of the library is automatic, although not perfect since it requires some patches in the java code and some patches in the generated code, but the patches are small and easy to maintain. Keeping NGit in sync with JGit is very easy, since it is just a matter of pulling the java code and running the conversion (I already have the conversion process automated in a makefile).

I've also been able to convert and run the JGit unit tests, and got 90% of tests working. The failures of the remaining 10% are in general due to different behavior of Java vs C#, or JUnit vs NUnit, and are not real NGit bugs (although I still have to review some of them).

In the process, I also converted Jsch, which is the library used by JGit for the ssh communication. The new NSch library only has Mono.Security as external dependency, so it will be much easier to distribute for us.

So, we now have a fully managed git library with ssh support without any dependency external to Mono. The library has around 56000 lines of generated C# code (including the unit tests). I recently published the source code in github.

I'm now implementing the git add-in using NGit. Most of the commands are already implemented, although I'll have to do some testing before I push it to master. There are still some performance issues I'm tracking down, but things are looking good. I intend to submit my fixes to JGit. My fist patch has already been accepted and pushed, and conveniently ported to NGit.

Update: I'd like to clarify the relation of NGit with GitSharp. GitSharp is composed by two libraries: GitSharp.Core.dll and GitSharp.dll. GitSharp.Core.dll is a manual port of JGit. GitSharp.dll is a more high level and .NET friendly API that wraps GitSharp.Core.dll. NGit can be a replacement for GitSharp.Core.dll, but GitSharp.dll is still useful, since NGit may be a bit too low level and java-ish for some use cases.

Cydin source published

2010-10-20T16:19:00.002+02:00

I just published the source code of Cydin in github. Cydin is an add-in repository for applications based on Mono.Addins. The latest version is currently running the MonoDevelop add-in repo. I have many ideas to keep improving Cydin. Here are a few:

Add support for multiple applications. That's almost done, but there are still some issues to be fixed. The idea is that a single Cydin installation could be used as add-in repository for many applications (for example, MonoDevelop, F-Spot, Tomboy, etc). The add-in repo for each application would be independent, but they would share some services, such as user authentication and the build service. It would be nice to have in the future a single web server which can be used by all Mono.Addins based applications to host add-ins.
Add support for multiple add-ins per project. Right now, a project can only generate one add-in. In some cases it may be useful to be able to generate several related add-ins without having to create a project for each of them.
Add a search and browse views, so users can look for add-ins.
Add support for 1-click install. This would allow users to install add-ins by clicking on them in the web site, instead of having to do it through the add-in manager in the application. That's partially implemented, but requires changes in the application (that is, MonoDevelop).

So, quite a lot of work to do. I'm open to contributions :)

Comunity add-in repository for MonoDevelop

2010-08-04T12:13:00.000+02:00

Yesterday I published a beta version of what is going to be a Community add-in repository for MonoDevelop. This web site is based on the Cydin project, developed during the last hack-week at Novell.

The functionality it has is basically what explained in my last blog post:

The add-in developer creates a new project in the web site by specifying a name, description and version control urls to the source code. It currently supports Subversion, Git and Bazaar.
A build service pulls the code from the version control repositories and builds it.
The built add-ins are published in an standard Mono.Addins add-in repository in the web site.
Users can subscribe that repository and install the add-ins.

This site is still under development and needs testing, so I'd like people to start publishing add-ins to see how it works. I intend to publish the source code of Cydin so that other Mono.Addins based application can create their own add-in repositories. However, before doing it I want to polish a bit the code and add some documentation (and that requires time).

The long term goal is to have a kind of add-in marketplace site, where developers can publish add-ins and users can browse, download, rate and comment them.

For now, I'm happy with having a place where contributors can make add-ins easily available to all users. So if you have developed an add-in for MonoDevelop, please register it!

Hack Week project: Cydin

2010-06-17T13:00:00.000+02:00

Last week was a Hack Week at Novell, so I spent some time working on a new idea I've been cooking in the past weeks: a Community Add-in Repository for MonoDevelop, which I'm calling Cydin.

The idea is to have a web site where add-in developers can publish their MonoDevelop add-ins and make them available to all users. The site works like a build bot: it pulls the source code of add-ins from version control repositories, builds and packages them, and then publishes them in an add-in repository, to which MonoDevelop will be subscribed.

In one week I've been able to implement the basic functionality, although it still needs some polish before I can make it publicly available. I implemented the site using ASP.NET MVC. I didn't know much about MVC in ASP.NET, so it has been also great to learn something new.

Beware: I put zero effort to the visual design.

So, how does it work? This is the home page:

The first thing you have to do is to log in. Authentication will be based on OpenID, but this is not yet fully functional (I'm using the DotNetOpenAuth library but I'm having trouble making it work on Linux).

The home page is very simple. It shows a list of the projects owned by the user and a list of recent releases. I planed to include add-in browse and search options, but I had no time for this.

The Create Project link allows creating a new add-in project:

This page allows entering the add-in name, the identifier and a description. When clicking on Create, the source definition page is shown:

This page allows specifying the location of the source code of the add-in. Right now it only supports Subversion, but I plan to add support for GIT soon.

When specifying the URL of the subversion repo, there is a twist: if the URL ends with "/*" the build service will pull all directories bellow that URL, and each directory will be considered a

different release. So for example, if you specify:

https://test.googlecode.com/svn/trunk/tags/test-project/*

then all tags of test-project will be pulled as independent releases.

If the auto-publish checkbox is set, the build service will automatically publish new versions of the add-in at every commit.

After saving the changes, the project home page is shown:

The page will be empty because pulling and building the source code may take some time.

Source code is pulled and built by a Build Service. The build service is independent from the web site and can run in a different host. Communication between the two is done through a web service.

So after a bit we'll see:

This shows that the build service found six directories below the specified svn url, and pulled all of them. Then it started building.

Notice that the build service extracts some information from the add-ins: the add-in version, the MonoDevelop version that the add-in is targeting, and the target platforms.

Sources with the 'Ready' status are already built and packaged, but not yet available in the add-in repository. To make them available, you have to click on the 'Publish' link. This is not necessary if the auto-publish option is set for this SVN source (in this case the release would be automatically published after building).

This is how the page looks like after publishing some releases:

The site administrator has some control over which releases are published. By default, new projects releases have to be validated by an administrator.

Published add-ins can be installed using the MonoDevelop add-in manager:

There is still some work to do, but I hope I can publish the site as a beta soon so you can start experimenting with it.

Improving in the MonoDevelop user interface

2010-03-08T14:50:00.000+01:00

In the past weeks (actually, months) I've been doing some changes in the MonoDevelop GUI to make it more functional and better looking. Here is the result:

Before

After

Changes in the Status Bar

Everything started with the idea of removing the status bar, in order to save space in the main window. The plan was to use something similar to Chrome's status popups, which are visible only when there is actual information to show to the user. However, after playing with the idea and thinking about how would it fit in MonoDevelop, I decided to try something else. Instead of removing the status bar, we would make a better use of the space it takes. So in the new GUI I merged the status bar and the bottom dock bar. The dock bar is the area where the title of pads in auto-hide mode are shown (for example, the Test Results pad in the above screenshots). When you hover over the title, the pad is shown in a popup window, with a nice sliding effect. The bottom dock bar is now shown next to the status bar, growing as more space is required.

I also added support for custom pad labels. So for example, the Errors List pad now shows the error and warning count, instead of just the "Errors List" label. In this way pads can show some status information while they are minimized.

Less intrusive output pads

Temporary output pads such as logs for Version Control or Find in Files operations are now shown in autohide mode by default. Until now, those pads were shown docked at the bottom, taking space from the text editor. I also removed the standalone Build Output pad. The build output is now available in the Errors List pad, by clicking on the Build Oputput button:

Visual improvements

A noticeable visual change is that the main window new has a darker background, with some subtle shading effects. The pads look more "physical" and better delimited. The pad toolbars are now integrated in the docking system, improving the overall visual consistency.

Configurable GUI compactness

One thing I learned while working in MonoDevelop is that it is hard to find the right balance in the use of padding between the gui components (specifically, between the components shown in the main window). Using more padding makes the GUI more visually pleasant, and the components are better delimited. On the other hand, padding may be a waste of space when working on small resolutions.

I added a configuration option for selecting the level of compactness of the GUI. There are five levels, from Very Compact to Very Spacious. So for example, the screenshots shown above are using the 'Spacious' level. In that level, there is some padding always visible between the pads, the window borders and the main menu. There is no such padding in 'Normal' mode.

Zoomable tree views

MonoDevelop has an option which allows choosing the font to use for the tree view pads such as the Solution pad or the Class pad. Those trees may be large for big projects, so users find it convenient to use a small font, which allows seeing more information at once.

To make font reduction easier and more handy, I added a Zoom capability to the tree pads. So to zoom, all you have to do is hold the Control key and move the mouse wheel up and down (the standard zoom shortcuts can also be used for this, including Control+0 to reset the zoom). This screenshot shows the solution and class pads with different levels of zoom:

Conclusion

The changes I described are part of an ongoing effort to make MonoDevelop easier to use. There is more to come. It would be great to have feedback on the changes we are doing, so that we can further fine tune the interface for the 2.4 release.

Loading executables as MonoDevelop projects

2010-02-24T17:11:00.003+01:00

Miguel recently blogged about a trick for loading an executable assembly as a project inside MonoDevelop. I have now added native support for this feature, which means that it is now possible to directly open a .exe or .dll as a project, or add it to an existing solution. Also, MonoDevelop will get the list of source code files from the debug info of the assembly (when available). For example, this is what you get when you open gmcs.exe:

The code just landed in SVN.

.NET/Mono Code Camp: Registration is open

2009-09-29T19:19:00.002+02:00

Registration for the upcoming .NET/Mono Code Camp in Spain is open and filling up quickly, so if you are interested in attending, register now!

The agenda has also been published. It includes talks about Mono, MonoDevelop, mocking frameworks running on Mono, iPhone development (with MonoTouch), Moonlight, .NET to Linux portability, Mono.Addins and other stuff.

.NET/Mono Code Camp in Tarragona: Call for Papers

2009-08-31T23:33:00.004+02:00

We have started planning the sessions for the .NET/Mono Code Camp in Tarragona (Spain). The sessions are being organized in two tracks: a Mono track and an MSDN track. I plan to give at least a couple of talks: one about the upcoming release of MonoDevelop, and one about application extensibility based on Mono.Addins.

If you are interested in giving a talk, it is now time let us know. You'll find here a form you can use to submit your proposal. We will select the proposals we find more interesting, and we plan to pay the travel expenses for all speakers. Update: sessions are going to be held in spanish.
Update 2: we don't have a big budget, so we may not be able to pay full expenses to people coming from outside Spain.
Update 3: the deadline for the call for papers is September 11th.

I like how the Code Camp is shaping up so far. It will be a chance to meet with spanish Mono hackers and users, but it will also be a good chance to talk about Mono and Linux to an audience which typically is very Microsoft-centric.

MonoDevelop API Overview

2009-08-03T22:17:00.000+02:00

I added a new document to the MonoDevelop developers documentation page: API Overview.

The public MonoDevelop API is really extensive, and it is not easy for add-in developers to find out which part of the API they have to use to do certain operations. This document is basically a high level description of all functionality provided by the API, with information about which classes and objects provide that functionality. The document doesn't give much detail about how to use the API, this will come in separate feature-specific documents.

I hope you find it useful.

Building with MSBuild/XBuild in MonoDevelop

2009-07-30T12:13:00.000+02:00

I committed today very basic support for building projects using MSBuild / XBuild instead of MonoDevelop's own build system. Ankit has been doing a lot of progress in XBuild, and it is mature enough to build complex projects. XBuild support is for now disabled by default. To try it, you'll have to enable it in the Edit / Preferences / Build options panel.

The integration right now is simple because all it does is to launch the xbuild command in a separate process. That's not the best way of doing it, but the most straightforward. A more optimal option is to use the MSBuild API to load the project and launch the build. That's my next step, but there are some issues with it.

The main problem is that MonoDevelop now supports multiple target runtimes and frameworks. Multiple frameworks are not a problem because MSBuild already has support for that, but it doesn't have support for multiple runtimes.

Multiple runtimes means that for example when running MD on Windows, I can select either Mono or MS.NET as target runtime, and MD will build the project using the selected runtime. Each runtime has its own GAC and set of installed packages, even its own MSBuild version, so I can't use the MSBuild API to load and build the project. The only option in this case is to launch in an external process.

There is however and additional and more hard to fix problem. To get the list of assemblies referenced by a project (for example to do code completion), MonoDevelop right now just enumerates the reference elements defined in the project. When using MSBuild that's not fully correct anymore, since custom targets and tasks may inject references which are not explicitly set in the project. So the only way of getting the real list of references is by loading the MSBuild project and evaluating it, and that won't work when targeting a runtime other that then one running MD.

Anyway, this basic support we have now is good enough for many projects. I'll go step by step.

.NET/Mono Code Camp in Tarragona, Spain

2009-07-01T14:15:00.004+02:00

It's official: there will be a .NET/Mono Code Camp in Spain in October. The proposal was made some months ago by CatDotNet, a local .NET user group. Several other .NET user groups quickly joined. The initial idea was to do a traditional Microsoft.NET Code Camp, but I though it would be a good chance of putting together .NET and Mono developers, since after all we have a lot to share. Everybody thought this was an awesome idea.

This will be a good chance for learning and sharing knowledge about .NET and Mono, but I'd also like it to be a meeting point for the Spanish Mono community. I'll be there giving some talks, and I hope other Mono hackers can come too. If you want to propose a talk, or you want to contribute please join the official forum.

More info about the Code Camp in the official web site: www.codecamp.es.

How to build MonoDevelop with Visual Studio

2009-06-25T21:02:00.004+02:00

How to build MonoDevelop with Visual Studio in five easy steps:

Install GTK# (get installer here)
Install the Mono Libraries (get installer here)
Get MonoDevelop from SVN (update: instructions here)
Open main/Main.sln in Visual Studio
Press F5 (update: make sure you have the configuration DebugWin32 and platform x86 selected).

New MonoDevelop installer for Windows

2009-06-19T12:07:00.003+02:00

A new MonoDevelop installer for Windows is available. This release has many fixes and improvements:

Performance of the text editor greatly improved, thanks to a new text rendering logic cooked by Mike Krüeger.
The debugger is now more reliable, it properly handles enum values, and it now has an 'immediate' console.
The NUnit add-in now works.
Version Control now has a new Create Patch command, thanks to Levi Bard.
A new C# formatter, with support for per-project/solution formatting options.
MD now logs debug and error output to a file located in your AppData/MonoDevelop/log.txt, so if you get a crash or something you may find some info there.
Many other bug fixes.

The new installer is available here. Worth trying!

MonoDevelop installer for Windows

2009-06-03T21:13:00.004+02:00

Since my last blog post about MonoDevelop on Windows, things have improved a lot. I focused my work in making MD good enough to be used for everyday MD hacking. We are still not there, but close. Here are some improvements done in the past week:

Fixed the GTK# designer add-in. It is now fully working.
Implemented a new backend for the Subversion add-in. I tried using the add-in we have for Linux, but the libraries I could find for Win32 have some differences in the API and the bindings doesn't work. I finally decided to refactor a bit the SVN add-in to support different backends, and implemented a new one based on SharpSvn. So the SVN add-in is also fully working.
Added support for debugging, based on the debugger that comes with .NET. This is still work in progress, although most of features already work: stepping, breakpoints, inspecting variables with drill down and evaluation of expressions.
Support for .NET 4.0. This new version can now be selected in the project properties.
Improved the look of the main window. Reduced some spacing, improved the rendering of the tabs when docking several pads together, and other cosmetic fixes.
Improved the performance of the text editor. It now feels more responsive.
... and many other fixes.

There are still some stability issues, and are several add-ins are still untested, but MD is starting to look great on Windows. GTK+ with the Vista theme looks really nice. Here are some screenshots of the GTK# designer and the debugger:

Now, here is what you've been waiting for: a MonoDevelop installer for Windows. You can get it from the Windows Preview page in the MD site. Read carefully the instructions in that page. You'll have to install the latest GTK# package, also linked in that page. Also, beware that this is a preview built from trunk, so you can expect to find stability issues. In any case, bug reports are always welcome. Enjoy!

MonoDevelop on Windows

2009-05-06T13:00:00.005+02:00

Besides the efforts to make MonoDevelop play nice in MacOS X, we've also been doing progress in the Windows side. This is how it looks right now:

What you see above is MonoDevelop running on Windows Vista using Microsoft.NET. A lot of effort has gone into making it easy to build MonoDevelop. Mike Kestner has been working on an installer that provides the core libraries on which MD depends on (such as Mono.Addins), and I hope it will be soon available so that people can start using it. We've also fixed the MD project files, so now MD can be built by just opening the main solution in Visual Studio and clicking on build.

A new feature I had to add to MD in order to properly support Windows, is support for multiple runtimes. Thanks to that feature it is possible to select in the IDE which runtime you want to use for building and running a solution. It can be done using a combo box in the toolbar:

There is also a "Run With" menu which shows all runtimes, so you can run a specific project using a specific runtime. Notice that support for multiple runtimes is not specific to Windows, it is also supported in Linux. In this case, you can register several mono runtimes versions installed in different prefixes (I'll blog with more detail about that soon).

The basic funcitonality already works in Windows: loading a project, building running. Other features still don't work, such as the gtk# designer, the nunit add-in or the Subversion add-in. I haven't yet tried none of the add-ins in 'extras'.

I hope we'll be able to make a 2.2 release with a very decent Windows support. I'll keep posting and twittering updates.

MonoDevelop 2.0 beta 1

2009-02-17T17:33:00.004+01:00

Yet another step towards 2.0 release. We released Beta 1 last week with many fixes and some new interesting features (here are the release notes).

The one I like more is the support for per-project policies. This feature has been planned for long time but other work has been delaying it. Me and Michael Hutchinson had a chance to talk quite a lot about it while I was at Boston a couple of months ago. The policies model allows setting properties at global, solution, folder and project levels. Settings such as tab width can be defined in any of those levels and will cascade down to the lower levels (where it can be overriden if required). Many settings are already available in this way, and many more will be in future releases.

Another new feature, or rather improvement, is the support for multiple frameworks. MD already had support for targeting the 1.1/2.0 CLR for quite a long time, but did not have the concept of 'target framework', which is more generic. For example, .NET 3.0 is based on the 2.0 CLR and it just includes some additional assemblies. What complicates things a bit is that Mono does not follow the .NET releases, so for example Mono 2.0 includes bits from all .NET versions. To simplify all this and to be compatible with MSBuild, it is now possible to select the target .NET framework, which includes 1.1, 2.0, 2.1 (Silverlight), 3.0 and 3.5. The project system is fully aware of the chosen target framework, so for example it won't let you reference a 3.5 project from a 3.0 project.

The source editor keeps improving in many ways. Mike Krueger has spent quite a lot of time fixing issues in code completion, which now works in many more contexts. My contribution on code completion (besides stabilization work in the parser database) is support for completion of generic types with constraints. For example, in the following class code completion is showing the Dispose method because there is a constraint forcing the generic argument to implement it:

There are other improvements, such as the new Go to File dialog I blogged about some time ago, better support for completion in ASP.NET projects, and fixes in the GTK# designer. There is still a lot of work to do, but we are getting close to 2.0.

2009-01-14T13:35:00.004+01:00

One of the most unknown, yet most useful feature of MonoDevelop is the Go to File dialog. This dialog can be quickly opened by pressing Alt + Shift + O, and it can be used to quickly find and open a file of the project.

Some weeks ago I did several performance improvements, and introduced support for acronym matching. The filtering algorithm tries to find the best match, not only by searching substrings, but also by splitting the search string in several parts and trying to match them through all the words that compose the string being checked. This is an example:

When filtering files, the algorithm tries to match the file name, and if it fails, then it tries to match the whole file path. This allows filtering by directory. Following the example, if I type 'xml/ccomdata', it will fill find results under the MonoDevelop.XmlEditor.Completion directory. When there are several files with the same name, the list shows the parent directory name next to the file (inside brackets), so you can decide which one is the good one. Besides filtering, the dialog automatically highlights what it considers the best match.

After several weeks of use, I'm very happy about how the matching algorithm is working. Most of the time it manages to highlight the file I'm looking for by just typing 3 or 4 letters.

BTW, the same dialog supports searching by type name, using the same algorithm. In this case the shortcut is Control+Shift+T.

MonoDevelop 2.0 alpha 2 is out

2008-11-24T22:43:00.002+01:00

Last Friday we released MonoDevelop 2.0 alpha 2. This is an exciting release because for the first time it includes debugger integration. This integration is not yet perfect, the debugger is not yet 100% stable and not all features are available, but we finally have some debugging support. This has been the #1 feature request for long time. You can take a look at my previous post about the debugger to get an idea of what it looks like.

In addition to the Mono Debugger (MDB), I also have spent some time improving the GDB integration. We now have support for expression evaluation, which can be used in conditional breakpoints and tracepoints. The debugging service in MonoDevelop is extensible, so we can plug support for different debuggers into it. I hope we can add support for debugging other non-.net based languages in the future.

Anyway, here is a screenshot of a debug tooltip in a GDB debug session:

The other big improvement in alpha 2 is the new code completion engine, on which Mike Krueger has been working. The new engine supports "aggresive" code completion, which means that the completion window will be shown in any context by just typing the first char of an identifier. It also has some nice features such as automatic insertion of event handlers or anonymous methods when completing an event subscription. In addition, the C# parser has been upgraded to support C# 3, and we already support some of the new C# features, such as completion of extension methods. The new engine still needs polishing and performance improvements, but it is looking great.

Michael Hutchinson has done a great job improving the editing experience for ASP.NET, HTML and XML files. There is better support for code completion and CodeBehind files. Compatibility with Visual Studio 2008 has improved, and we now have preliminary support for creating Moonlight projects. Many hackers will also be interested in the new vi mode that has been implemented for the text editor.

The GTK# designer has also some improvements. Mike Kestner became the maintainer of the designer some months ago, and he's been learning about the inner workings, and doing some fixes and improvements. One of the main changes is the simplification of the GTK# settings panel. It is not necessary to explicitly enable GTK# support on projects in order to use the designer. Now it can be done by just adding a reference to GTK#. Also, exporting a widget so it can be used in another project is as simple as applying a [ToolboxItem] attribute to the widget class.

Ankit Jain did a great job with the new Override/Implement dialog, which allows to easily implement members defined in a base class or interface. Here is a screenhot:

Ankit is now working behind the scenes to complete xbuild, our MSBuild implementation. The mid term plan is to replace MD's build system by xbuild, but this won't happen before MD 2.0.

There are many other improvements in version control support, project management and others, but you'll have to take a look at the release notes to know more.

In the following weeks we are going to focus on bug fixing, and we plan to release a 2.0 Beta 1 soon (the plan was to release before Christmas, but holidays may not permit it). In the meanwhile I hope you find alpha 2 useful and file any bug you can find so we can fix it to make MD 2.0 an awesome release.

Planning a short stay in Boston

2008-09-06T02:08:00.002+02:00

Since my girlfriend wants to learn English and I'll probably have to attend a meeting in Boston, we decided to put it all together and we are planning to stay a couple of months in Boston, from end October to end December. After 5 years working alone at home, it will be refreshing to work in an office together with non-virtual coworkers. It also comes at a good timing because we are planning to release MonoDevelop 2.0 around the end of the year.

This is going to be an interesting end of year.

BTW, I'm currently looking for a small apartment (or big room) to rent, ideally around Cambridge. Unfortunately I'm not having much success, since apartments I found are either too expensive, or not available for those two months. So if you know about some good place, information will he highly appreciated! (mail lluis at novell dot com).

Debugger screenshotting

2008-07-09T14:21:00.003+02:00

The debugger integration in MonoDevelop is progressing, lots of work in the past weeks. I'm going to show what is supported right now, altough much work is still left to make everything stable.

Everything I'm showing here works both for the MDB and GDB backends, unless explicitly stated.

First of all, this is the Attach to Process window. Notice the "Debugger" combo at the bottom. It allows you selecting which debugger you want to use to start the debug session (MDB or GDB):

Breakpoints have a nicer look, and there is support for enabling/disabling. Also, when starting a debug session, invalid breakpoints (e.g. breakpoints placed in lines without statements) will be rendered as disabled.

The dissassembly window shows the assembler mixed with the source code when available. This mixed view is not supported in MDB, due to limitations in the API (for MDB, dissassembly without source code will be shown). The disassembly view supports single-stepping of assembler instructions.

Big improvements in the Watch View. The list now has icons for each type of member. Drill down has been improved, for example big arrays are now split in 'ranges' which makes easier to locate elements.

The Watch View now supports expressions. The expression evaluator is based on NRefactory, and although not all C# expressions are supported, many of them are (for example, arithmetic operations, method calls, array access, conditional expressions, etc). Expressions can be used both to select what to show in the view, and to assign values to variables or members. For GDB, the GDB expression evaluator is used. The screenshot below shows some examples. In one of the examples, the value of an expression will be assigned to the variable 'n':

The Watch View can also be used to inspect types. The view will show all static members of a type. Namespaces are also supported. For example, you can enter the namespace 'System' and drill down through all types and inspect their static members (not supported in GDB):

The Watch View also supports code completion (both for entering expressions and values). Code completion is based on data from the debugger backend, not on the MonoDevelop parser database, so it works for MDB and GDB, and even when debugging an application for which there isn't a MonoDevelop project:

Another nice feature is the support for debug tooltips in the editor. When moving the mouse over a variable or member, a tooltip will show its value. The tooltip is interactive and allows drilling down and modifying values just like the watch window:

It is also possible to use tooltips to inspect the value of expressions:

And works for GDB too! This final screenshot shows a Mono process attached with GDB, a debug tooltip for a MonoMethod, and a member of that struct being modified using code completion:

That's all for now. If you want to try it you'll have to get everything from SVN (see my last post).

Debugger integration in MonoDevelop

2008-06-26T10:24:00.001+02:00

Many people has been asking about the status of the debugger integration in MonoDevelop, so I thought it would be a good idea to post a quick status report.

The short answer is that we are working on it. The debugger integration work has started, and there is already support for breakpoints, stepping, call stack view, current frame selection, basic variable watch window, and attaching/detaching to/from running processes. All this is working in MonoDevelop from SVN (still with some stability issues).

And here are some big news: we are integrating not only MDB (the Mono debugger), but also GDB, and thanks to the debugger abstraction layer we built in MD, we'll be able to use the same GUI for both debuggers. Two debuggers for the price of one!

We are going to do a MonoDevelop release next week. However, this release will not include the debugger integration because it still depends on Mono and MDB from SVN and we would not be able to package it. If you want to try the debugger (beware, this is work in progress), you have to do the following:

Get and build Mono from SVN.
Get and build the Mono Debugger from SVN.
Get MonoDevelop from SVN.
At the MonoDevelop's top-level directory, run './configure --select'. Make sure the extras/MonoDevelop.Debugger.Mdb add-in is selected (and/or extras/MonoDevelop.Debugger.Gdb if you want GDB support).
Build MonoDevelop.

If you only want to try GDB, you don't need Mono and MonoDebugger from SVN, getting latest MonoDevelop is enough.

MonoDevelop 1.0

2008-03-18T11:43:00.002+01:00

Last Friday MonoDevelop 1.0 was released. It is the first time I do an 1.0 release, so it is really exciting to see the release after so much time working on it. To know more about the features of MD, take a look at the release announcement. Miguel also wrote a nice blog entry about the past and future of MD.

Our main goal for this release has been to provide a good IDE for developing applications for GNOME and the Linux desktop in general. Most of the features are being use nowadays to develop MD itself: the GTK# designer, Subversion integration, Makefile integration, unit testing, localization, and others. It means that MD is mature and complete enough to handle complex projects, and that's why we have an 1.0 release right now. This release is of course not perfect, there are still bugs and feature gaps, we'll keep working on it.

So what now? we are already working on next release, which should happen in about 6 months, and which will include long awaited new features, such as debugger integration, code folding, better ASP.NET support, and many other improvements. After so much time being focused on bug fixing, it is a pleasure to go back to real hacking :)

MonoDevelop 1.0 RC1

2008-02-21T17:00:00.004+01:00

Last week we released MonoDevelop 1.0 RC1, the (hopefully) last release before 1.0. This is a bug fix release, with no real new features, so the release notes are a bit boring this time. There is however a nice improvement: many icons have been redesigned to better fit the Tango style, so MonoDevelop now looks nicer. Those icons were designed by Vincent Depizzol as part of a GHOP project. We had other GHOP collaborations, such as for example new translations, I hope Michael can find the time to blog soon about all of them.

In addition to bug fixing, we are also starting to do some post-1.0 work in SVN trunk. Mike has been working on a new managed editor, fully implemented in C#, and it progressing very well. Ankit has started doing some preliminary work on the debugger integration, and I've been doing an internal redesign of the project model which will allows us to move to MSBuild as default file format. After so much time being focused on bug fixing, it is refreshing to start implementing new features.

I spent last week working on the add-in authoring extension for MonoDevelop, which has been stalling in my hard disk since I blogged about it almost one year ago. The add-in is not yet ready to be used, but it is close, and the code is finally in SVN. Let's see if I can find the time to finish it. So many things to do...

MonoDevelop beta 3 is out

2007-12-20T13:20:00.000+01:00

MonoDevelop beta 3 was released yesterday, with plenty of bug fixes and some nice improvements. This will hopefully be the last beta, everything should be ready for the final release by the end on January. MonoDevelop has now been branched for the release.

We did an important reorganization of the MD build structure. Add-ins which have uncommon dependencies, or which are still unstable have been moved to a new "extras" directory, and they will be distributed as separate packages. This makes the core MonoDevelop application easier to compile and install. The Boo and Gecko dependencies have been removed, and a new one has been added: Mono.Addins.

This is an important milestone for Mono.Addins, because for the first time we are distributing it as a separate package. Together with MD beta 3, I released Mono.Addins 0.3, which includes many fixes and some new features, such as support for add-in localization (see the release notes).

Mono Summit

It was awesome to meet all the Mono team again (some for the first time, since the team has grown a lot since last year), and also to have the chance to talk to many Mono users and contributors.

This time I gave two talks. The first one was a demonstration of MonoDevelop. It was a bit problematic because my laptop refused to show the video both in the LCD and the projector. The other laptop I had at hand with everything I needed for the demo was Ankit's, but it had the same problem. The solution we found just a few minutes before the demo was to run the demo in one laptop, and project it from the other laptop connected by VNC. Hacky, but it did the trick.

The other talk was about Mono.Addins. I did an overview of the library, explaining the basic concepts and common usage scenarios. This talk was also a bit problematic. Since the talk didn't include any demo, I just took the presentation and copied it to JB's laptop, who just had finished a talk about Cecil. I thought that a simple Impress presentation would work as expected in any laptop. I was wrong. I had spent several hours making some simple diagrams and animations in my OOo Impress presentation, which I think help a lot when explaining concepts. First of all, some text in the diagrams didn't show up. The cause for this was that JB's laptop had a dark GNOME theme, and Impress was painting white text over the white background of my presentation. Also, in the middle of the talk, Impress started freezing on some of the animations, and I had to stop several times the presentation because of that. I'm also wondering why Impress is so bad in drawing circles (in fact, curves in general). Despite all those problems, the presentation went ok and looks like people liked it.

Some MonoDevelop screencasts

The talks at the summit were not recorded, but I did some screencasts which more or less cover my demo. There are four of them: Creating a Simple User Interface, Creating Custom Widgets, Building Packages and Using Version Control.

Sorry for the low volume of the explanation (and for the bad english!), next time I'll try to do it better.

Holidays

I'm starting holidays tomorrow and I'll be back to work on January 7th. It doesn't mean I won't be online, answering mails or hacking. It means that I may just not.

Bon Nadal!

MonoDevelop Survey Results

2007-11-20T22:23:00.000+01:00

Thanks to everybody that answered the survey! I'm very happy about the amount and the quality of the responses we got: almost 900. This will be a great source of information for planning the future of MonoDevelop. I hope we can repeat this survey next year.

The results are summarized here.

Here are some initials considerations:

71% of responders are using MD to some degree. It means that who responded the survey is mostly our current user base. Not surprising since the survey was advertised only in the common Mono mailing lists and blogs.
People mostly use MD to build GTK# applications, which means that we'll have to keep improving our integrated designer.
There is more demand for System.Windows.Forms than for ASP.NET, although the numbers are close. I'm kind of surprised about that, since ASP.NET has been working very well in mono for several years. Looks like we'll have S.W.F around for long time.
Not surprising that C# is used by 95% of responders, but I expected more VB.NET demand as a secondary language. It's almost in pair with Boo. We clearly need to improve our support for C/C++.
Little demand for .NET 1.1. Most of projects are based on .NET 2.0 nowadays. MD still defaults to 1.1 when creating a project. That's because the 2.0 profile it is not yet officially supported by Mono. Maybe we should consider defaulting to 2.0 anyway. Amazing amount of people willing to develop applications for Silverlight.
No big surprises on the target platform.
Most of responders is using bleeding edge GNOME. I would expect corporate developers to use older GNOME versions. Does it mean we don't have many corporate users?
We've done a good job fixing bugs, but stability is still the most important problem that our users have. However, I feel that many of those stability issues are not being reported, and we can't fix them if they are not reported. Maybe we should make it easier to provide feedback?
In the comments some people are requesting features that MD already has (for example, support for .NET 2.0). This should be considered an usability problem, because it means that those features are not easy enough to find.
289 responders interested in developing MD add-ins? wow
Number 1 feature request is the debugger. That was expected, and it will be priority #1 when the debugger is finished.
Big interest for a Windows.Forms designer. We'll have to look on the work done by Ivan Zlatev on the designer, and see how it could be integrated in MD.
People request better editing tools. We have a good code base to start offering better intellisense and refactoring operations, but our text editor based on GtkSourceView is limiting us.
The feature ranking will be helpful in priorizing the work to do (at least in the core MD team), although I know that list is not complete.
I know the survey is not perfect. It is the first time I do something like that. The next one will be better :)

MonoDevelop Survey: Beyond 1.0

2007-11-08T14:05:00.000+01:00

MonoDevelop 1.0 is just around the corner, and it is mostly feature frozen. Now it is time to start thinking beyond 1.0. I published this this survey to get a more clear view of what MonoDevelop is being used for, and what features are the most requested. This will help us planning the future directions of the project.

Thank you for your feedback!

MonoDevelop Beta 2

2007-11-07T16:35:00.000+01:00

Yesterday we released the second beta of MonoDevelop (release notes here). This is mainly a bug fix release. It has tons of bug fixes (and a few new bugs I found while waiting for the packages, but such is life!). There are also some new features and improvements:

Basic support for ASP.NET web project deployment.
Support for Visual Studio 2005 web application projects.
Generation of satellite assemblies for localized resources.
Makefile generation improvements

We are getting closer to 1.0. The next release will be in about 1 month, just after the Mono Summit. If everything goes as planned, this will be our first RC.

Now let's go back to work. Lots of things to do in three weeks.

MonoDevelop Beta 1

2007-10-01T20:43:00.002+02:00

The first beta of MonoDevelop has just been released! I'm really excited on seeing a beta release of MD after so much time working on it, because it means that:

MD has feature set complete enough for real life use.
MD is becoming more and more stable. Yes, it still has bugs and crashes, but now that it is feature-frozen, we can focus 100% on bug fixing, and that's what we'll do in the following months.
MD 1.0 is just around the corner. I hope it can be a nice Christmas gift.

We also have a new logo for the project. The logo started with this image of a monkey tail and ended being what you see up there. Inkscape does wonders.

Sept 14th: MonoDevelop Bug Day!

2007-09-10T20:19:00.000+02:00

If you found some annoying bugs in MonoDevelop that you'd like to get fixed in the next release.
If you reported some bugs which are not yet fixed maybe because we've not been able to reproduce them.
If you want to help in tracking down some of the issues that MD has...

please join us next friday (September 14th) in the #monodevelop IRC channel (in irc.gimp.org) for an interactive, collaborative and intense bug hunting effort.

MonoDevelop is approaching the beta 1 release, which should happen by the end of the month, so this is a chance for helping the development team in tracking down and fixing MonoDevelop issues.

Thanks to all!

Architect

2007-07-15T21:35:00.000+02:00

My hack week project about building a library repository for Mono turned out to be more complex than expected. Actually, I didn't expect it to be simple, but I wanted to have something working (even if not complete) after that week. I finally spent the week doing research and implementing some of my ideas as a proof of concept.

My initial idea was about building a Library Management System, but after all the feedback I got and after looking at similar systems for other platforms, that idea evolved into building something more generic. Here is a summary of my conclusions.

The end goal is to simplify the development with Mono, improve productivity and code reuse. There are three main areas that we need to improve:

Library management. Most of projects depend on third party libraries, and yet there isn't a common model for sharing them.
Project dependencies. Dependency checking is traditionally done by configuration scripts using tools like pkg-config. However, this system falls short when trying to implement more advanced features, such as on-demand dependency downloading or better integration with IDEs.
Development life cycle. The way applications are developed in Linux is very complex for many developers, specially those coming from Windows. There is an important gap between IDE based development and command line based development, and that's specially noticeable when a project has to be published, packaged and distributed.

The idea is then to create a better Mono development platform built on top of what we have now, but providing more advanced and better integrated development tools. This is what it would provide:

A Library Management System, which would be used to share libraries in an on-line repository. It would provide tools for publishing, searching and downloading libraries. It would also define a common model for dealing with libraries in projects.
A new model for project dependency checking, with support for on-demand downloading of dependencies. Projects would be able to define dependencies on libraries, compilers, code generators or any other kind of development tool.
It would define a common development model which would work with independence of the development environment being used.

Right now I'm using the codename Architect to refer to this platform (subject to change). Following are some more details about this it.

Archtiecture

Architect will be based on Mono.Addins. What's interesting about Mono.Addins is that it allows defining an add-in ecosystem which is not limited to a single application, but which can be shared by many applications. There will be an Architect add-in ecosystem, and development tools will be able to plug into it in order to offer extension points, or to extend other tools.

That is, everything will be modeled as add-ins (in the more generic sense of the word): libraries, compilers and other development tools. A project would then depend on a set of add-ins.

Mono.Addins defines an add-in model with support for dependencies, and it has some support for on-demand dependency downloading that would be integrated in the IDE and other development tools.

Library Management System

Architect will provide tools for publishing, searching and downloading reusable libraries. Libraries will be published as add-ins, and as such they will be able to depend on other libraries or tools. Library add-ins will be able to include not only the library itself, but also other things like for example Monodoc documentation or designer editors (if the library implements a widget).

Reusable libraries may or may not come with source code. Mono binaries are portable, so we could build a library repository which contains only binary libraries and be able to reuse them from any system. However, when developing an open source project, the source code of the libraries will be needed soon or later. Architect should take it into account, and should make it easy to handle.

When developing an application, I don't really need the source code of the external libraries I use. The binary assemblies are enough to build the project. At development time, the most comfortable way of dealing with libraries would be to specify that my project needs for example Mono.Cecil.dll and get it automatically downloaded by Architect when I need to build the project. In this way I can avoid adding binaries or a private copy of the Mono.Cecil sources into SVN. Architect would take care of giving me what I need.

However, at packaging time, when creating a tarball of my project, I may need the source code of the library. It depends on whether the library is being individually distributed as a package or not.

There are two kinds of libraries. On one hand there are API stable libraries which are installed in the GAC and which are distributed in a package. For example, gtk#. On the other hand there are libraries which are not so stable, or which are small and which are not installed in the GAC. Mono.Cecil is an example of such library. To make things a bit more complex, some distros may decide to package some libraries which are not packaged by other distros.

So, when creating a tarball for a project, Architect should take into account the kind of libraries needed by the project. It should download the source code of Mono.Cecil and include it in the tarball. Well, not only include the source, but it should also take care of building the library using the included sources when the tarball is built. And that leads to an important question...

Should Architect provide its own Build System?

Defining a new build system with a new project model is not really necessary right now. However, Architect should provide a generic API and a generic command for building projects. It would be like a proxy command which would end calling the native build tool. That's required to support building of libraries downloaded from the repository in a generic way.

Add-in Management

Right now Mono.Addins has an add-in manager which can be used to download and install add-ins, and it defines a repository format for publishing add-ins. However, the add-in engine is independent from this add-in manager. The add-in engine only cares about add-ins existing in the file system, doesn't matter how those were installed.

So, what we could do is to make the add-in manager pluggable, so it could support additional distribution systems. For example, we could add support for apt. It means that there could be an apt repository with a deb package for each add-in, and the apt support add-in would be in charge of mapping add-ins to packages.

So for example, if we are trying to build an application that requires Mono.Cecil, MonoDevelop would request Architect.Mono.Cecil to be installed to the add-in manager, and the add-in manager would request this add-in to the apt support add-in, which would pull Architect.Mono.Cecil.deb from the repo.

However, I don't think that everything in the Architect repository can be published as a deb package. We might end having 1000's of libraries in the repository, many of them very small or rarely used. CPAN has over 11.000 modules. Publishing all of them as packages would be crazy. So, downloading of unpackaged add-ins should still be allowed.

What's interesting here is that Architect based applications always work in terms of 'add-in', and will be the duty of the add-in manager find the best way of locating and installing all required add-ins.

A Common Development Model

All the features provided by Architect will be available both through an API and from command line tools, so they can be used from different development environments. To illustrate how all this would work, I've written some use cases:

Creating a new project with MonoDevelop

The user creates a new project of type Boo.
The project will need Mono.Cecil, so the user selects it in the reference selector. If it is not installed the user can open the library manager, look for the package that provides the library, and install it.
If the user wants it, MonoDevelop can generate a makefile for building the project.
Commit the project to SVN (or wherever).

Checkout and build and existing project in MonoDevelop

Get the code from SVN.
Load the project in MonoDevelop.
If Boo or Mono.Cecil is not installed, MonoDevelop will use Architect to download and install it.
Build the project.

Checkout and build and existing project using a makefile:

Get the code from SVN.
Run the build configuration script, generated previously by MonoDevelop. This script will use Architect's command line tools to check and download dependencies if necessary, including the Boo compiler.
Run the makefile, also generated by MD.

Create a tarball of the project:

Run the package configuration script. Since Mono.Cecil is not a packaged library, the source has to be included in the package. The package configuration script uses Architect to get the source code of the library and include it in the tarball.
Run make dist.

Build a tarball of the project

Run the build script and the makefile, as usual.
The makefile will use a tool provided by Architect to build the embedded Mono.Cecil sources.

Conclusion

Implementing all this will take quite a lot of work, but some of it is already done. Mono.Addins already has some support for add-in management and on-demand downloading of add-ins. MonoDevelop has some support for library management, and has a generic build api. I spent part of the hack week improving Mono.Addins and extracting code from MonoDevelop into an independent library. I also implemented some command line tools which could be used to automatically include source code from libraries in tarballs. I finally was able to more or less support the use cases I described above. However, I consider this code still a proof of concept.

In the following months that code may make it into SVN. All depends on the feedback I get and the release plan for MonoDevelop. One important first step would be to stabilize and freeze the Mono.Addins API, and publish it as an independent package. In this way we would have the basic infrastructure on top of which to start building the new platform.

What about Maven?

2007-06-27T01:36:00.000+02:00

Today I spent some time learning about Maven. I got some comments about my library repository idea, and several of them suggested taking a look at Maven.

Maven is basically a pluggable development environment (not to mistake it for an IDE). It defines a project model, a project development life cycle, and a model for extending both the project model and the process using plug-ins. Maven is able to automatically download all required dependencies of a project, including compilers, libraries or whatever is necessary to build a project.

Would it be good to have this kind of environment for Mono? I think so, and I have several reasons:

It greatly simplifies the work of developers. The development tools we are using for Mono were not really designed for modern managed platforms. For example, resolving the needed library and tool dependencies should be much more simple, just for the "simple" fact that Mono binaries are portable.
It allows offering development tools which are more consistent and integrated. For example, if I install "Boo" (the language), it might provide the Boo compiler (for compiling Boo projects), the Boo runtime (so projects build with Boo can distribute it), a Boo CodeDom provider (so code generators like wsdl or stetic can generate Boo classes), a graphical Boo compiler options editor (so I can change the options of a Boo project in an IDE) and MonoDoc documentation. All that are extensions to the development environment, and all the tools can use them.
It improves reusability by making it easy to share libraries and tools.

I've been thinking about this idea for quite a long time now, and some of the work I've done in the past years has been in this direction. When working on MonoDevelop, I always had in mind that we were building a development platform, not just and IDE. That's why one of the first things I did in the project was doing a complete reorganization of the assemblies, which had as a result a well defined Project Object Model (implemented in MonoDevelop.Projects). I spent half of the time making the project model independent from the GUI, and the other half improving the add-in engine to better support complex add-in relations.

However, the MonoDevelop add-in engine, even if improved, had important limitations. It wasn't really suitable for a large add-in ecosystem. I took into account those limitations when I designed Mono.Addins, and this new add-in engine is more scalable and ready to be used in a more global and generic add-in space.

Does it mean that we are ready to create a "Maven" for Mono? To some extent, yes. The infrastructure I'm going to implement to support the library management system may be the foundation over which to build it (well, in fact Mono.Addins already provides most of the needed infrastructure). Once we have the basic infrastructure in place, we can make it organically grow by adding more extension points. At some point maybe we'll extract the Project Model from MonoDevelop, make it more generic, and move it to the development foundation. But that's long term, maybe a goal for MD 2.0.

Mono Gems

2007-06-25T21:45:00.000+02:00

So, this week is a Hack Week at Novell, and we are free to choose what we want to hack on. I had several ideas in mind for this week, but I finally decided to work on something that might be completed in one week, and that will be really useful for the Mono community: a repository for sharing Mono libraries.

Well, the idea is not building the repository itself, but all the needed infrastructure to make it easy to share libraries, that is, something like Ruby Gems. So, I'm going to create a set of tools which will allow searching for libraries, downloading and installing, and referencing them from projects. I'm also going to define a way of publishing libraries, and I'll eventually create a real repository in some server where we can start adding some libraries.

Scope of the Project

So, first of all let's state the scope of this project:

This is going to be a library packaging and distribution system designed for development only. That is, I'm not trying to compete with existing packaging systems. You'll be able to more or less automatically download libraries from the repository, but when building a package for distribution, the package will have to either include the library binary, or have a dependency on a package that provides it.
Only fully managed libraries will be supported for now. In the future we may add support for libraries which need some C glue code by compiling them after downloading.
It will allow parallel installation of different versions of the same library.
It will support dependencies between libraries. So, when a library is requested, all libraries on which it depends will be downloaded/installed. Of course it will only work for libraries in the repository.

Architecture

My plan is to use Mono.Addins to implement this infrastructure. It may sound a bit strange to use add-ins for building a library management system, but if you think a bit about it you'll see that it makes perfect sense:

A library can be seen as an extension to the system. There will be an extension point where new libraries will be registered. An 'add-in' will be able to register one or several libraries.
Mono.Addins already provides a system for publishing, downloading and installing add-ins, including support for dependency check. We can share the same file formats and package management tools.
Such add-ins might include not only libraries, but also Monodoc documentation, support tools or other extensions. For example, we could publish a library which implements a Chart widget, and we might include a chart designer to be integrated in Stetic.

Different ways of sharing a library

There will be three different types of library packages:

Binary package: it will include the library compiled in an assembly. Projects will directly reference this library. At deploy time, the library will be copied together with the application using it.
Binary package with GAC install. Same as previous, but the library will be installed in the GAC. To run the project it won't be necessary to copy the library to the project directory (since it will be loaded from the GAC). At deploy time, the developer will be able to choose between packaging the library together with the application, or not packaging it and generating a package dependency instead (of course this last option only makes sense if a package providing the library is available).
Source package: I'm still unsure about this type of package. My idea is that it may be useful to be able to share some classes which are very common, but for which it is not worth to create a .DLL because they are too small. So projects would just include the source files in the project. However, it may also make sense to include the source files in binary packages, even if it's only for debugging purposes. Also, given the multi-language nature of .NET, source-only packages would too limited, since they would be useful only for projects using the same language.

Integration in MonoDevelop

My idea is to provide something like the add-in manager, but specialized to installing library packages. After installing a library package, all assemblies it provides would be shown in the references dialog. After adding an assembly reference to a project, if the assembly belongs to a package installed in the GAC, the user will be able to set or reset the 'local copy' flag.

I'm still not sure if it would make sense to add an "Include Library as Source" command, which would include the source files of the library to the project.

Integration in Visual Studio

Why not? it would dramatically increase the number of potential libraries and users. Any volunteer?

Command Line Tools

There will be a command line tool for managing library packages, and for querying information about libraries. This should be some kind of replacement of pkg-config for Mono. It will be able to check if a library package is installed, and which assemblies does it provide.

Configuration scripts might be able to use this tool to automatically download packages not installed in the system.

Library Repository

I don't plan to implement any server-side logic or service for publishing or browsing libraries. An on-line library repository will be a set of package files in a directory and an index file. We can easily generate a set of static html files for the repository and for each package, so that people can browse it and Google can index it.

Looking for a Name!

"Ruby Gems" sounds really cool. Any idea about how all this infrastructure could be named in Mono?

Other more general comments and suggestions are also welcome :)

GTK# versions

2007-06-15T19:45:00.000+02:00

One of the changes done in the last MonoDevelop release is that now MD depends on GTK# 2.8. In previous versions the dependency was GTK# 2.4. We decided to do this upgrade because 2.4 is now a few years old, and 2.8 is nowadays present in most distributions (at least those used by developers).

One of the problems of depending on GTK# 2.8 is that the applications built by MD will work only in system with GTK# 2.8. That's because it is not possible to install two different versions of GTK# at the same time, so if we require 2.8 to run MD, apps will need to be linked against 2.8. And if an application is built with GTK# 2.8 it won't run on a system with GTK# 2.4 (notice that it will run on a system with GTK# 2.10, because GTK# installs some GAC policy files which redirect old GTK# versions to new versions).

This is an important limitation, so I started looking for a solution.

The first I'm doing is to add support for multiple GTK# versions in Stetic (the GUI designer). The idea is that when you create a project you can select the GTK# version you want to target. The widget palette and the properties window will be filled according to the selected version, so if you select 2.4, widgets or properties introduced in newer versions won't be shown. No big deal to implement.

The real problem to solve is how to allow building applications against GTK# 2.4, even if what is installed is GTK# 2.8. The solution to this problem is simple: even if GTK# 2.4 is not installed, we can have the GTK# 2.4 assemblies copied somewhere, and when building the application link against those assemblies. It doesn't need to be a full 2.4 installation, since we only need the assemblies to compile the application. Once linked to 2.4, the application will happily run on top of the installed GTK# 2.8, thanks to the policy files.

That's what I did. MD now has an extension point which can be used by add-ins to register new assemblies, and those assemblies will be shown in the reference selection dialog. So, I can create an add-in called "GTK# 2.4 compilation support" or something like this, and after installing it the user will be able to select gtk-sharp 2.4 assemblies in the references dialog.

However, this solution doesn't work. Or, it is not so easy to make it work.

When you use "mcs -r:/path/to/my/gtk-sharp.dll myapp.cs" to compile an application, mcs will correctly load gtk-sharp.dll from the specified location, but when trying to load the assemblies on which gtk-sharp depends, e.g. gdk-sharp, it will load them from the GAC, since it will be applying the assembly binding policies which translates 2.4 version requests to 2.8 versions. The result is a compilation failure with some weird casting errors. Explicitly referencing all gtk-sharp dependencies as "-r" references also doesn't work. The assembly loader seems to always apply the binding policies.

I finally found a solution for this problem, although I'm not very happy with it. The idea is to create a private GAC for MD, and install there the GTK# 2.4 assemblies. The compiler would be run using the MONO_GAC_PREFIX env var for pointing to that private GAC, so the compiler will try to load assemblies from this private GAC and will fallback to the main GAC when not found. This solution works, but it needs an additional hack. For some reason Mono is applying the assembly binding policies before looking at the private GAC. I'm not sure if that's a Mono bug or it is supposed to work in this way. To overcome this problem I had to add dummy assembly binding policies to the private GAC which bind 2.4 versions to 2.4.

Nothing of this is yet committed, since I want to do some more tests to make sure I'm not missing a more obvious and easy solutions. So, ideas are welcome :).

MonoDevelop 0.14 released

2007-06-13T13:29:00.000+02:00

MonoDevelop 0.14 has been released today. Those suffering triskaidekaphobia will be specially happy about it.

This release has quite a lot of new features and improvements, which are detailed in the release notes. It's worth trying the new packaging system (which simplifies the creation of packages for projects), the improved support for C# smart indent, or the new code refactory commands.

This is also the first release which is based on the new Mono.Addins framework, and I hope I can now find more time to work on my add-in authoring add-in to take full advantage of it.

So, what's next? There are several features we plan to work on for the next two releases: configurable key bindings, improved ASP.NET support, improved makefile integration, C/C++ projects support, debugger integration (the last two from Google SoC projects), and others. A lot of work to do, but I hope we can finish all this in the following three months and then do a code freeze for the long time due 1.0 release.

Mono.Addins keeps growing

2007-05-08T03:57:00.000+02:00

Last week I completed the migration of MonoDevelop to Mono.Addins. Everything seems to work fine so far, although there may still be some uncovered bugs. It's awesome to see Mono.Addins being adopted in several Mono applications, since there is a lot we can share.

So, thinking about what we could share, some weeks ago I took some spare time to start working on an add-in authoring add-in for MonoDevelop, that is, an extension that will help developing add-ins for any Mono.Addins based application. This extension still needs a lot of work to be useful, but I thought that it would be good to show what I have in mind with some screenshots. Nothing of all this is yet in SVN, and won't be for some time since there are still many things to be finished.

Everything starts when creating a project. The new project dialog is now a two-step wizard. Well, this is not new in this extension. If you update MD from SVN you'll already get this new dialog. Hmm, I planned to talk about it in another post, but I guess it's ok to talk about it now. The first step of the wizard is the same we always had: it allows choosing the kind of project to create and its location and name:

The second step is new, and allows selecting a set of features we want to enable in the project. Some of the features may be already enabled depending on the kind of project. Other features can be enabled by the user. This list of features is of course extensible, so add-ins can define new features. It looks like this:

The previous screenshot shows the new Add-in Support feature. That's the only one not yet in SVN, the other ones are already available if you update from SVN. What I like about this feature list is that it helps the user in discovering what MonoDevelop can do. There are many features hidden in contextual menus and in options dialogs. The Project Feature List helps in making those features easier to select and configure.

OK, so lets go back to the add-in authoring extension. What does the Add-in Support project feature provide? It allows defining a project as being an add-in or an add-in host. In case of choosing the 'add-in' option (the only one I have partially implemented), it allows selecting the add-in registry (needed to find the add-in host or other add-ins to be extended), and allows entering basic information about the add-in.

The new project will have a new element in the solution tree: "Add-in description". Clicking on it will show a window which will allow describing the contents of the add-in:

This window will have several tabs. The first one (shown in the previous screenshot) will allow entering basic header information about the add-in. But the most interesting one is the Extensions tab:

OK, it doesn't look so interesting, but that's because the project is new and we still don't have nothing there. This tab will show the list of extension points being extended by the add-in. So, the next thing to do would be to select the extension points we want to extend. This can be done by clicking on the Add button, which will show a dialog like this:

This dialog shows a tree with "everything" that can be extended. All information is taken from the add-in registry selected when creating the project. At root level there are add-in namespaces (namespaces are usually mapped to applications), then there is a hierarchy of add-in hosts and add-ins grouped in categories ("Deployment" is a category, "MonoDevelop Runtime" is an add-in host). Expanding an add-in host will show the extension points that it provides. We can then choose which extension points we want to extend.

If an extension point already has some extension nodes registered on it, those will also be shown, to make it possible to extend a specific node of an extension point. For example:

The previous screenshot shows the extension points offered by the IDE. One of them is the Main Menu extension point, which already contains some nodes on it. Those nodes are the main submenus, so we can choose to extend a specific submenu of the main menu. After choosing all extension points we want to extend, the Extensions tab would be filled with them like this:

Well, not exactly like this because in the screenshot some nodes have already been added to some of the extension points. That's because I copied the add-in definition file from MonoDevelop's version control add-in to show the example. But the idea is that it will show the list of selected extension points and you would be able to add new nodes. So, in the screenshot you can see the Main Menu extension point, and that the submenu File is being extended with a CommandItem node which defines a new Checkout command.

When double-clicking on a node, a node editing dialog will be shown. It might look like this:

This dialogs allows entering the value for all attributes of the node. Notice that all that information shown in the screenshots is taken from the selected add-in registry using the Add-in Description API that Mono.Addins provides. That includes the list of available extension points, the name and description of those, the types of extension nodes that each extension point accepts, the attributes supported by every node type, the type and description of every attribute (shown in the tooltip above). That's a very rich set of information that is used to fill and drive all those windows, and that will also be used to automatically generate documentation.

I also plan to automatically generate classes referenced from nodes. For example, the defaultHandler attribute shown in the screenshot is the name of a class that implements the handler to be run when clicking on the command. The IDE will detect it, and will automatically generate a class implementing the required base class or interface.

That's what I have so far. There is still a lot to do, but I thought it would be good to show a glimpse of the kind of development tools that Mono.Addins will allow creating, and which will be shared with all Mono.Addins based applications.

Horizontal extensions

2007-04-28T18:26:00.000+02:00

MonoDevelop has always allowed creating new types of projects by subclassing the Project class. A Project subclass can for example override the OnBuild and OnExecute methods to provide custom behavior for building and executing. In this way add-ins can provide support for new languages. That's what I call vertical extensions (I always envision inheritance as a vertical hierarchy)

At some point I saw the need of allowing "horizontal extensions". For example, the gtk# designer needs to plug into the build process to generate the GUI code just before the project is compiled. Using a project subclass and override OnBuild is not possible in this case. We don't want to create a new project type, just add some behavior to all existing project types (well, maybe only those which can use the designer, but it is still an undetermined number of project types).

The first quick and dirty approach to allow this kind of extensibility was to create a new extension point where add-ins could register implementations of an interface like this:

public interface IBuildStep
{
    ICompilerResult Build (IProgressMonitor monitor, Project project);
}

When building a project, the project would get a list of all IBuildStep implementations and would call Build() on each of them. In fact, the default implementation of the project build was just another IBuildStep implementation, so add-ins would be able to add build steps before or after the default project build operation.

This design has the advantage of being very simple, but it has some important limitations. For example, an extension cannot have control over the sequence of execution. If an add-in wants to do something before and after the project build, it has to add two steps in the correct position of the pipeline, and it won't be easy to share data between them.

Those limitations were not a problem for the gtk# designer add-in, but they became evident as I tried to extend the build pipeline for other purposes. So, I decided to rethink the design and do something more generic.

The first idea was to use the "message sink" model on which Remoting is based. Using this model the interface would look like this:

public interface IBuildExtension
{
   ICompilerResult Build (IProgressMonitor monitor, Project project);
   IBuildExtension Next { get; set; }
}

The idea here is that the project service chains all extensions by setting the Next property of every extension to the next extension in the chain. Then it calls the Build method on the first extension, and the extension is supposed to do whatever custom operations it needs to do and then call Build on the next extension in the chain. In this model, an extension has more control on the build process because it can do whatever operation before, after, or in replacement of the build operation (it can decide to not call Next.Build at all, for example). This model is not as direct to implement as the previous model, because the extension has to handle the Next property, but still it's quite easy.

One problem I find in this model is that it can't easily scale. The Build operation is not the only operation that makes sense to extend in a project. Other operations like Clean, Execute, Load and Save might also be extensible. One option is to add all those methods to a more generic IProjectExtension interface. The problem with this option is that if an add-in only wants to extend one operation it has to add dummy implementations for all methods. Another option is to create an IxxxxExtension interface for each operation. This solution is maybe better but it isn't ideal because it requires dealing with many interfaces and having one extension chain per operation. Every time you want to extend some operation you would have to find the interface that defines it, implement it in a class, find the correct extension point for that interface and register it.

Also, I'm becoming lately a bit tired of using interfaces. Interfaces are very commonly used in extensible APIs: you define an interface and the extender implements it. Using interfaces has advantages, but also important limitations: you are forced to implement all methods (even if you are not interested in all of them), they can't provide a default implementation, and you can't add new methods without breaking the compatibility with old versions. I've seen many APIs which define interfaces without a clear idea of what benefit does using those interfaces have. In many cases interfaces are not really needed, and using a simple class is just enough. I think the build extension example is one of those cases.

I finally designed the build extension more or less like this:


public class ProcessServiceExtension
{
   internal ProcessServiceExtension next;

   public virtual ICompilerResult Build (IProgressMonitor monitor, Project project)
   {
       return next.Build (monitor, project);
   }
}

So, to provide an extension to the build method you don't implement an interface, but a subclass of ProcessServiceExtension, and then you override the Build method. For example:

public class MyExtension: ProcessServiceExtension
{
   public override ICompilerResult Build (IProgressMonitor monitor, Project project)
   {
      // Do some custom processing
      bool res = base.Build (project);
      // Some post-processing
      return res;
   }
}

This class is similar to the previous IBuildExtension interface, but using a class has several advantages:

You don't have to implement the Next property. The base class does it. In fact, it is hidden to the extender. What I like about this model is that it allows implementing horizontal extensions just like if they were regular vertical extensions.
I can add new overridable methods to ProjectServiceExtension without breaking old extensions, and without having to define new interfaces or extension points.
ProjectServiceExtension can define overridable methods for all project operations, and extenders can override only the methods they are interested in.
ProjectServiceExtension can provide specialized overloads of the operations. For example, it could define generic Build(item) method, which would call a Build(project) method, or a Build(solution) method depending on the item type. Extenders interested in projects can just override Build(project), while extenders interested in more generic extensions which apply to all types of items can override Build(item).

I'm getting addicted to this extension model. MonoDevelop is using it in several places, and so far I haven't missed the "benefits" of interfaces at all.

Mono.Addins!

2007-03-26T20:06:00.000+02:00

Today I finally announced Mono.Addins, a generic framework for implementing extensible applications in Mono.

I've been maintaining the MonoDevelop add-in engine for almost two years now. This engine is based on the SharpDevelop add-in engine, which took ideas from Eclipse. At some point I decided that it would be interesting to be able to reuse the engine in other applications, so I decided to take it out of MD, move it to an independent library and make it more generic. That became Mono.Addins.

This is the list of features of Mono.Addins taken from the announcement:

Supports descriptions of add-ins using custom attributes (for simple and common extensions) or using an xml manifest (for more complex extensibility needs).
Support for add-in hierarchies, where add-ins may depend on other add-ins.
Lazy loading of add-ins.
Provides an API for accessing to add-in descriptions, which will allow building development and documentation tools for handling add-ins.
Dynamic activation / deactivation of add-ins at run time.
Allows sharing add-in registries between applications, and defining arbitrary add-in locations.
Allows implementing extensible libraries.
In addition to the basic add-in engine, it provides a Setup library to be used by applications which want to offer basic add-in management features to users, such as enabling/disabling add-ins, or installing add-ins from on-line repositories.

Reusing an add-in engine has many advantages. It's not only about reusing the library, but it also allows reusing an add-in model. Developers will be able to reuse knowledge and development tools to develop add-ins for different applications. Mono.Addins is specially good for this because it encourages self-documentation of add-ins, and it provides an object model for reading add-in descriptions, so building documentation and development tools based on it will be easy.

However, creating an add-in engine that fits all application needs is not trivial. Different applications will have different extensibility needs. For example, in MonoDevelop some add-ins need to extend other add-ins, so add-in identity and versioning is an issue to take into account. Lazy loading of add-ins is also important, since and IDE may integrate many tools, but not all of them are needed at the same time. MD also needs to provide complex extension points, such as the solution tree pad, build pipelines or hierarchical menus. MD describes those extension points using XML manifests.

Other more simple applications will have more simple needs. For example, an application may just need to load types from some assemblies copied to some directory. Mono.Addins can also be used in this case without adding development complexity. Instead of using XML manifests, extensions can also be declared using custom attributes, and there is no need to assign identifiers or versions to add-ins, since there won't be add-ins extending other add-ins.

What's interesting is that both applications will be using the same add-in model, and it will be possible to use the same API, documentation and development tools for both cases.

I'd like Mono.Addins to set an standard for building extensible applications in Mono. That's why I'd like to get feedback from applications developers about the library and about add-in development in general. I created a mailing list to collect this feedback: http://groups.google.com/group/mono-addins. If you are developing an application which can be extended by add-ins, please take a look at Mono.Addins and say something!

To know more about Mono.Addins you can read the Introduction to Mono.Addins.
A more detailed guide on using the library can be found here.
And the source code is here.

Enjoy!

MonoDevelop SoC projects

2007-03-21T19:40:00.000+01:00

Just like last year MonoDevelop is participating in the Google Summer of Code as part of the Mono project. If you are a student, don't miss the chance of working on a very nice IDE for GNOME, and get paid for it! There are some project suggestions here, although fresh ideas are also welcome.

Having fun with properties

2007-03-03T00:23:00.000+01:00

If you open the View menu in MonoDevelop you'll find listed there two pads which look very similar: "Properties" and "Widget Properties", and you'll also find "Toolbox" and "Widget Palette". The reason for this duplication is that there are two designer models in the IDE: the Stetic model used by the GTK# designer, and the System.Component based model used by the ASP.NET add-in. Today I decided put an end to this duplication, and I started integrating those pads into a single Properties/Toolbox pair.

The System.Component based toolbox is actually not so System.Component dependent. There is a MonoDevelop.DesignerSupport add-in which implements the property and toolbox pads, and which is designed to be pluggable, so I only had extend it from the GTK# designer. After some fixes and improvements I've been able to show the GTK widgets in the toolbox, and to drag&drop them in the designer. It's almost 100% functional now, there are only some small issues to fix, such as the order in which components are shown. But not too much...

Integrating the properties pads has been a bit more tricky. I wanted the properties pad to be very generic and usable not only for visual designers, but also for the IDE in general. So for example if you select a file in the solution pad you would see the properties of the file.

The first problem about the integration is that the Stetic model and the System.Component model are very different. In particular, properties of Stetic components are defined in class descriptors (specified in an xml file), while System.Component model is purely reflection based. Since it's not trivial to implement a property grid which can support both models, the solution has been to completely replace the properties grid depending on what has the focus. When the focus is in the GTK# designer, the properties pad will show the Stetic property grid, and when clicking on the solution pad, it will show the standard System.Component model property grid. We still have two property viewers, but now we have only one properties pad.

The second problem to be solved, is how to detect that the currently selected object has changed, and that the properties pad has to be updated to show the properties of the new selection. In Stetic it is done by tracking focus change events, but it won't work as a generic solution, because the "currently selected object" can be *anything*, not only widgets. For example, the properties pad should change when the selection in the solution tree changes. So I decided to go for a pull model like the one used by the command manager for updating command status. Status of commands is checked periodically by getting the widget that has the focus. If that widget has a handler for the command, it is executed. If not, the command manager looks for a handler in a route of objects which starts on the active widget. This route is by default the chain parents of the widget, but it can be altered. For example, the solution pad re-routes commands to tree extensions before re-routing back to the parent. In this way node extensions have a chance to provide custom behavior for commands.

How is all this related to the properties pad? Well, I'm using the same command target infrastructure to find a potential target object for the properties pad. So, any class in the command route can now not only handle commands, but also provide the "selected object" to be shown in the pad (it only needs to implement the IPropertyPadProvider interface and specifically the GetSelectedComponent() method). I quickly managed to implement a solution pad extension which implements that interface and returns the current tree selection. The result is what you can see in this screenshot:

That is, by selecting any item in the tree, it will show its properties in the properties pad. It still needs a lot of polishing since some properties need to be hidden (it can be done by applying System.ComponentModel attributes), and the properties grid itself is not very stable, but it's looking nice.

MonoDevelop 0.13 released!

2007-02-23T13:41:00.000+01:00

After 5 months of intense work MonoDevelop 0.13 has been released. It includes lots of new features and fixes. Thanks to all contributors that made it possible!

This is not yet the first beta release we planned for this month (well, in fact for last month), because there are several features that still need to be finished and polished. I hope we can finish all them for the next release. I'm optimistic because in addition to Ankit Jain, we now have Jeffrey Stedfast working full time on MonoDevelop (welcome!).

Making a release is stressing. I always have the feeling that after publishing the packages, a last minute fix will break everything. I should take some real resting this weekend. Although I have the feeling that I wont. Hmm.

Enjoy!

More on MonoDevelop work

2007-02-01T17:53:00.000+01:00

I'm probably one of the most constant MonoDevelop users, and although my opinion as user may be a bit biased, I really feel that I'm very productive using the IDE, specially after the latest features implemented and the bugs that have been fixed. I'm going to summarize some of them, and since I've been hacking quite a lot on code completion lately I'll start writing about that.

Code Completion Performance

There were several long time pending bug reports, and I also wanted to improve a bit the performance and memory use. MonoDevelop creates a Parser Information Database (pidb) file for each assembly or project. This file contains all the information about classes implemented in an assembly, together with documentation pulled from Monodoc. A pidb file has trhee sections: the first one is a header which contains among other things the version of the file format (that version is checked when loading the pidb, and the file will be regenerated if it doesn't match the current implementation version). The second section is the index of the pidb file. It contains an index of all classes in the database. The index is always fully loaded in memory to be able to quickly locate classes. The third section of the file contains all the class information: list of methods, fields, properties, documentation for each of those, and so on. Each entry in the index has a file offset field, which can be used to completely load all the information of a class (the index only contains the name).

So, one of the changes that I've done lately is to replicate some of the class data in the index. Not to much data (only the class type, modifier flags and some other flags), but enough to be able to fill a code completion window without having to read any other class information from the database. This results in a big improvement in performance, and also some improvement in memory (although the parser service already did a good job in managing class information memory).

Showing subclasses

A nice improvement is a better support of completion of the "is" and "as" keywords, and the implementation of completion for "new" (which still won't be able to complete in all cases, for example in method parameters). Properly implementing completion of those keywords requires getting all direct and indirect subclasses of a given class. So if you type: "CollectionBase b; b as ", it will show all subclasses of CollectionBase. The same for "b = new ...", and when the type is an interface, it should show all classes implementing that interface, and all subclasses of that class. To be able to quickly get this information I had to add base-class/subclasses relation information in the pidb index (since recursively scanning all the databases would be really slow). So now the index is a bit bigger, but getting a complete subclass tree is very fast (fast enough to be useful).

Did you see that? The type of the variable is selected by default in the list. That's cool :-).

Improved Code Completion Infrastructure

Another important improvement I've done is removing all c# language specific checks from the generic code completion classes. Some of the checks done to determine if the code completion window had to be shown and the entries it had to offer were specific to c# (for example, checks for "using" or "is/as"). This was an important limitation for other language bindings, and for c# itself, since there wasn't a chance to support code completion in more complex contexts.

To solve this problem, there is now a TextEditorExtension class which can be implemented by any language binding to support code completion. In this class a language binding has full control of the whole code completion process, and can provide completion for situations not previously supported by the generic classes. For example, this morning I implemented support for completing overridable members. That is, when you type "override" on a class declaration, a code completion window will be shown offering a list of members which are virtual/abstract in base classes (it will show interface members too). When selecting a name, MD will create the full declaration of the member. Here is a visual example:Ah, this example also shows another improvement in code completion: full support for instantiated generic types. So, if you have a variable of type List, the code completion window will show all methods using the int parameter type.

Improvements in Version Control

I'm also saving a lot of time thanks to this window:

This is what you get when you run the Status/Commit command on a folder: a list of all files which have changes. You can expand a file to see the changes, mark it for commit and enter a commit message. You can even select multiple files and enter a comment for all them at the same time. What is also interesting is that comments are stored in disk, so if you close MonoDevelop and restart it again, the status window will show the comments you entered.

So, when I've done several changes in several MD projects, I run a "Status/Commit" command on the root MD solution, and see what changed. I can browse through the changes and enter comments for them. I can select files from all projects and enter the same comment if I need to. I then I run the status command on a specific project (for example the CSharpBinding project) and I click on the Commit command. This is what you get:

The commit dialog will summarize all commit messages from all files, and will group files which have the same message, and will update the ChangeLog file if there is one in that directory. I haven't manually edited a ChangeLog file for several weeks now, and I certainly don't miss it.

Version control integration in the solution pad

We've had source control integration in the solution pad since the first version of the addin. There is a Version control menu which looks like this:

However, nowadays version control integration is much better. When a project is under version control, all file operations you can do in the solution pad, such as copying. moving and deleting files, will be handled by the version control system. So for example, if in the project shown in the previous screenshot I move the file Main.cs to the Tercera folder (by just dragging it there), this is what I would get:

The version control system takes care of the move operation, that's way it is registered and the "Status/Commit" command shows the resuling remove + add operation. The same would happen when deleting or renaming a file or folder.

MonoDevelop is slowly getting in shape for the 1.0 release. There are still many bugs to be fixed (although I squashed quite a lot in the last two weeks), and we are a bit delayed according to the plan posted some months ago, but we are on track.

Broken leg

2006-12-30T21:46:00.000+01:00

What a way of starting the new year! Two days before Christmas I badly broke my right leg while doing roller skating with some friends. It didn't hurt very much, so I wasn't aware it was broken, I just could not move it. But once in the hospital the doctor gave me the bad news. My right femur was broken near the head of the bone. It is a bad fracture indeed, and I had to go through surgery just the day after. I spent the whole week in the hospital, and today I was allowed to go home (my parent's home in this case). I now have three months ahead in which I cannot put my right foot in the ground, and after that hope everything is ok. Fortunately there is no problem in seating and it doesn't hurt, so I'll be back to hacking soon again, or I'll certainly die of boredom.

Anyway, such is life, health is bad, but mood is good.
Happy new year everybody!

New home

2006-12-30T16:22:00.000+01:00

Hi from blogger! I had to find a new home due to some nasty comment spammer problems. Old posts are available here.