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!
-
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 :)
9View comments
-
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!1View comments
-
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
Now let's go back to work. Lots of things to do in three weeks.2View comments
-
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.
8View comments
-
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!1View comments
-
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.
- 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.
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).
- 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.
- 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.
- 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.
- 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.
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.6View comments
- Library management. Most of projects depend on third party libraries, and yet there isn't a common model for sharing them.
-
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.
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.8View comments
-
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.
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.
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.
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 :)36View comments
- 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.
-
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 :).8View comments
View comments