GUADEC

Just got back to Boston from GUADEC. It was extremely fun and energizing, just like last years. It is a shame I had to leave early the conference.

And the Band Played On

This year, there was a cover band made up of GNOME hackers and they did a fantastic job keeping us entertained at the Maemo/Nokia party, congratulations to the Macaques!

Beagle

As part of my upgrade to SLED 10, SUSE's new enterprise Linux desktop am finally a full-time Beagle user.

Finding your documents and discovering information you did not even remember you had, playing $HOME archaeology, has been a very pleasant experience.

Although Beagle is fantastic, it needs a little bit of tuning for my day to day use.

Am a heavy email user, I have seven gigabytes of email in my laptop, and Beagle has a bad habit of optimizing the Evolution index files every 10 minutes if something has changed. And the optimization process hammers my machine very, very hard, to the point of not letting me get work done for a few minutes.

I spoke to Joe, and he said "it happens about every 15 minutes or so", armed with this information I found the problem, the Beagle.Daemon.ScheduleOptimize routine has a 10 minute delay to run the query again.

I tried rebuilding my modified Beagle from CVS, but CVS has new dependencies that I lack, so I decompiled the BeagleDaemonLib.dll, like this:

$ export MONO_PATH=/usr/lib/beagle:/usr/lib/mono/gmime-sharp/
$ monodis /usr/lib/beagle/BeagleDaemonLib.dll > a.il
$ vi a.il
   # Replace the ldc.r8 10. in ScheduleOptimize
   # with ldc.r8 100. for a 100 minutes.
$ ilasm /dll a.il
$ mv a.dll /usr/lib/beagle/BeagleDaemonLib.dll
	

This has brought up my machine back to usable for me.

There are a few other glitches here and there, but the Beagle team is aware of these. Beagle and Beagle-based applications have a lot of promise, I just hope that the core gets a few passes of love, improvements and small touch-ups before they jump on to new, innovative ideas.

Avalon, WPF and Michael Zucchi

Michael has started a blog about his experiences using Avalon/WPF on Windows. Michael was one of the main developers in Evolution while at Ximian and is now working in Australia hacking on WPF.

His comments on WPF are interesting. His regular blog has had some negative comments about it in the past and his new blog has some more.

I do not have as much experience as Michael has with Avalon/WPF, but I wrote about the complexity of the framework a few years ago (here and here).

Although Michael is not involved in Mono, I have added his blog to the Monologue blog aggregator as his comments are very interesting.

MonoDevelop

Lluis Sánchez demoed the new developments of MonoDevelop at the conference.

What was interesting about Lluis' presentation is that I did not know about half the features that MonoDevelop has. I was blown away. Specially, since am Lluis' manager and I read every status report, and try to read most of the MonoDevelop patches, but I did not know that MonoDevelop had all this magic behind it.

I knew we had Stetic integration in MonoDevelop, but the integration goes beyond generating the UI for applications. The Stetic/MonoDevelop integration uses the refactoring engine to add method handlers for signals (double-click on signal) and if you change the names of your widgets in the designer, the source code that references it is updated. It also has a number of nice touch-ups that went into SVN recently, like a context-sensitive toolbar which has the most common operations in a per-widget basis.

JPR raised some concerns, because this "smelled" similar to Glade's "Generate code" feature, but it is very different. The model that MonoDevelop uses for Stetic/C# integration is more similar to Glade and XML, it just happens to not use XML at runtime.

The MonoDevelop model is more or less like this, for each "UI" element (custom widget, dialogs or windows):

• A MyGUI.cs contains all the event hooks, top-level class handler for the given UI component. This code contains a call to Stetic.Gui.Build (this, typeof(MyGUI)).
  This is the equivalent of loading your Glade file in the Glade world.
• A gtk-gui/MyGUI.stetic contains the representation used by Stetic to manipulate the UI. This is not used at runtime, its only used by Stetic to load and save the UI.
• During compilation the gtk-gui/MyGUI.stetic produces a gtk-gui/generated.cs file that contains the code to create all the GUI widgets and hook up all the events.

So you are free to add and remove as much code as you want to your MyGUI.cs file, that file is never touched by MonoDevelop.

He also demonstrated creating custom widgets, and how these could be kept on a separate library that MonoDevelop can load into the GUI designer, the steps are:

• Add a "New Project" to your solution, select "Library".
• In the library, select "Add New Widget", develop your new widget, debug it, test it. When you are ready.
• On the main project (or every project that consumes your library), right click on "References". Select "Projects" and click on the Library you want to incorporate.
• The new widget appears on the widget palette, you can now drag it and use it in your main application.

Finally, he demonstrated the "Deployment" feature, which produces an automake/autoconf setup and produces a tarball that is ready for redistribution. There is talk about doing a "deploy to RPM" and "deploy to DEB" functionality right into the IDE.