1. 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.
    Posted by
    26

    View comments

  2. 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 :)

    Posted by
    2

    View comments

  3. 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!

    Posted by
    0

    Add a comment

  4. 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.
    Posted by
    5

    View comments

  5. 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.
    Posted by
    24

    View comments

  6. 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.
    Posted by
    1

    View comments

Blog Archive
Blog Archive
About Me
About Me
My complete name is Lluis Sanchez Gual, and I work as a developer for Novell. I'm part of the Mono team, and I'm leading the MonoDevelop project, a very exciting open source IDE for GNOME.
Loading