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.
Jim Pubrick has written an 
Tonight Laura, Duncan and myself went to watch 
