Mono 2.0 has been released. It is a major release with a lot of bug fixes and new features. The main changes are the compiler upgrade to C# 3.0 with LINQ and the inclussion 2.0 version of ADO.NET, ASP.NET and System.Windows.Forms, which is more than enough for a 2.0 release. Please, go to Mono site to read more.

With this release, I hope Mono could attract a lot of new contributors and enterprises that depend on .NET and want to migrate their systems to Linux.

I encourage any .NET developer to try Mono 2.0, it has the actual heart of multiplatform and multilanguage development. Moreover, this release should be included in any Linux distribution, I hope this release is in time to be included in Ubuntu 8.10 (Intrepid Ibex) and soon to be backported to other distributions that has been released yet (Thanks Meebey to always let us have Mono in Ubuntu & Debian so soon after their release).

I'm happy for writing again in my blog. I hope to write more now... I was very busy.

MonoBoss page was very ugly and it needs a beauty page. Mono is the proyect in my heart and MonoBoss is the proyect of my life. I've got a lot of illussion with it. I hope that it can be useful for anyone in the future.

By now, the project is in the fridge. No public version is released yet. I hope to get a strong release at the end of this year.

Recently I saw new XCB (X C Binding) that will replace libX11. XCB uses XML descritption of the protocol to generate the bindings. I think it could be used to generate Mono/.NET managed bindings for using them in Managed.Windows.Forms (Mono's System.Windows.Forms). ¿Is it a good idea?

Recently I was thinking about changing GNOME's configuration management because I think GConf is like a hell and having a centralized daemon could be a bottleneck.

As an example of an application configuration could be the *.exe.config files that comes with many application in MONO. I think that having an XML file inside "$HOME/.config/{APPLICATION-NAME}" and using FileSystemWatcher to manage its changes can have the same features than GConf, it doesn't need an extra daemon and gets out GConf bottleneck.

The best way to provide these features is to have a very thin framework implementing the actions that GConf has: store, get, remove and watch. If this little tasks are enought efficient, applications can also use this framework to store big files and then we get all configuration of an application inside only one place.

I think this way could be a good direction for GConf. Making the implementation of this "new" GConf in managed code (C#) could be great but I think it's better to have an optimized implementation in C (using INotify) and a thin layer or other implementation in C# (using FileSystemWatcher), The first step should be to write a "libgconf" to provide an implementation of GConf using this framework I talk about and try how can impact in the applications.

Versions.

A good improve over GConf system could be to add profiles for config files, for example there could be "config" and "data" profiles. The "config" profile can have versions. Each stable release of an application should have an schema and it should be tagged with its version. An application requests configuration data providing its name and its version numbers, then the framework provides the configuration values.

Since last year I'm using MonoDevelop for a few projects and it is the best IDE I could never use because it's very simple and useful at a time. It has the few things I need for manage application development and its editor is very nice with a few helpers like code completion and auto-indenting features. Since 0.9 release it has easy support of plugins that makes it very extensible... ready to grow.

Today I've got a problem after my daily upgrade of Ubuntu Dapper, when I go to edit references of a project it crashes. Looking in the stack trace it seems to be some rendering of an icon, it is very strange and I think that there were no upgrade of MonoDevelop dependencies (only X packages). I recommend MonoDevelop and Dapper users don't upgrade and if they upgrade, take care of what breaks MonoDevelop and rever to the older package of it.

Ayer comencé la asignatura Sistemas Distribuidos donde me dispongo a aprender definitivamente las caracterísiticas que tiene CORBA y como utilizarlas. Ya tuve otra asignatura que tenía prácticas con CORBA pero no profundizaba en ningún concepto (era copiar y pegar ejemplos).

Tras instalarme un ORB me ha dado por probarlo con Remoting.Corba que es un canal para Remoting que permite utilizar objetos distribuidos CORBA en .NET/MONO o viceversa. Por el momento la primera prueba (Echo) me ha ido bien, solo he tenido que cambiar WStirng por String ya que Remoting.Corba no soporta WString por el momento. Ha sido una prueba muy bonita ver la posibilidad de comunicar mediante objetos distribuidos aplicaciones hechas en C++/CORBA con aplicaciones hechas en .NET/MONO.

Ahora no veo el momento de empezar a hacer objetos mas grandes y probarlos, con mas objetos que fluyan por la red y con objetos mas complejos... no le pido mucho a Remoting.Corba, pero lo veo un gran proyecto para ampliar las fronteras de .NET/MONO.

Today I thought in Gtk# and .NET/Mono integration. I think that Gtk# should be more integrated with .NET getting out Glib dependecies and making Gtk# control compatible with .NET control. Controls in Gtk# should implement, at least, IComponent and derive from Component (not from GLib.Object). I don't know the impact to Gtk# architecture and I don't know how hard it could be but there are a lot of new features that we can obtain. Using Glib is not necessary becuse all glib services are inside .NET/Mono.

This changes can make Gtk# a bit different for Gtk+ developers but it's not much more different than the actual Gtk# and in the other hand we have a very simple way to use it. For example, a Gtk# TreeView has its Model and I think that model could be a DataTable, an ArrayList, or other class. We should provide only a Tree implementation iside Mono or using SWF TreeView logic.

Other thought was to be able to use Gtk# widgets inside SWF application and SWF controls inside a Gtk# application. Gtk.DotNet is started and it can be the way to get this feature in Gtk#. It could be very useful for developers and for the evolution of the free GUI toolkits in .NET/Mono.

I've taken a few screenshots to show the status of the first painting implementation of DataGridView. Now it has the basic for run a little modified sample application I saw in MSDN documentation.

This week I have written a few nunit tests for ensure some of the members implemented. I started to write the painting feature of the DataGridView and here are the screenshots of the same application either in windows with .NET 2.0 Beta 2 and in Linux with Mono 1.1.8/2.0 preview.

I have finished to write the main classes (only interface, they don't work yet). The code has 5278 lines and I think that the hardest work is arriving.

I think that the next week I can get a little painting of a few things from the DataGridView and start to handle a few events from the keyboard and mouse. I love this job...

Now I can run a test that uses the DataGridView control but it's not painted and no user-interaction. DataGridView is in very early stage but now I have almost all members defined and a lot of them implemented. 3161 lines of code. I think that along this week I can finish the definition of the main classes and start to implement the painting/drawing.

At the end, Windows 2000 Professional inside Qemu Virtual Machine works. I needed half a day but now I've finished the installation of Windows 2000, .NET SDK 2.0 Beta 2 and Visual C# 2005 Express Edition Beta. I needed all of these things because I need to test DataGridView for the MONO implementation. Today I'll start to take notes of the work with the control I'm implementing and tomorrow I'll start to exec that control in MONO with the mimimum implementation to get an impresssion of what methods/properties/events should I implement first.

Today I made a page for XSP to upload a file using <input type="file" ....> and I had problems with big files. The problem was in the maximum length allowed for the requests of the HttpRuntime (used by XSP). This value is by default 4096 in mono 1.1.8 but it can be changed in the file "machine.config". I found that settings in Configuration/System.Web/HttpRuntime path.

I've just finished to install this blog, here is my first post. My main goal is to publish my ideas and projects, in special case the evolution of the work in DataGridView control from System.Windows.Forms 2.0 library.

After 1500 lines of code, the journey only is in the begining. I've written the property definitions for DataGridView and DataGridViewCell and I think that all the classes I need could be defined along this week. When I finish my university exams I'll be dedicated fulltime to this work.