Category: english

I’ve never been superstitious nor ever really believed in a God or anything that can’t be seen, can’t be studied with my own eyes. Nevertheless I’m okay with people who do.

Last Friday, however, (my) destiny seemed to have it’s periods.

Thursday evening I just couldn’t stop thinking about the meeting that we had at my current Customer, Maia Scientific (read about them and what I am doing there in my bio). The consensus was that we couldn’t use any other way than some difficult mathematics to know at which exact location the motor that makes focusing the microscope happen is.

Somehow I caused a breakthrough in knowing the exact position of the motor in real-time, programmatically, by using some special techniques for reading results from and instructing commands through the RS-232. Friday antemeridian, the result was that the microscope can be set in focus. And the really nice thing is that it actually can be reliably reproduced. The mathematically technique only 85% reproducible for a yet unknown reason. Mine, so far, has been 95% reproducible.

So we where all very happy about that. Postmeridian I went back to my personal laptop, and noticed that the screensaved was hanging. I couldn’t login to it either. It really seemed like a hardware problem, actually. So I forcefully rebooted the laptop. The result was that even GRUB failed to load! The harddisk was making funny noises: Tssk Tssskk Tsssk. Panic!

At home during my recovery attempts, using Knoppix, this weekend, it seems that sometimes I can actually mount the harddisk. But the more I try recovering from it, the more it starts failing. I am suspecting a headcrash or something.

So I decided to advertise the brand of my laptop, so that you people know what type you should buy if you want harddisk failures too: Acer Travelmate. I just hope that their service is good. I’ve bought this device a half year ago so it should be warranted. I wonder if and with what argument they’ll try to void that. Probably something like: Fedora Core 3 isn’t a supported software on the device, we can’t therefor test the harddisk and we can’t therefor test whether or not it’s broken. I guess I’ll have to pray to the Gods in which I don’t believe. Damned.

Yesterday (and other evenings this week) I had some fun with the code of the famous diagram drawing application Dia.

While I was doing a diagram for my current customer (Maia Scientific for whom I’m developing software for a scientifically microscopical device) I got very annoyed with the fact that Dia cannot handle setting the properties of multiple selected objects simultaneously. The current release will only set the properties of the first selected object. And it isn’t a bug. It’s actually coded that way.

So I decided I was going to fix that when I was done at Maia Scientific, that day. This illustrates how much of a code addict I am. I just can’t stop, also not in the evening. Luckily my girlfriend knows how to stop me, from time to times. IMHO, an addicted programmer, is a healthy programmer. No? We ought to be addicted. It’s our passion, job and life. (or replace “our” with “mine” if you’re a programmer and dissagree with this).

A few hours later I mailed my intentions to the mailinglist of Dia. A day later I had my first prototype diff file ready. Some other Dia developers responded. Eventually also the man in charge, Lars Clausen, who appears to be one of the current Dia-maintainers, responded.

Lars told me he likes the idea. There’s still a few features and bugs attached to this new feature (manipulating properties of all your selected objects). Like how to show which property has changed and thus will be applied on all selected objects, and which property isn’t changed. And how to store the undo/redo history (make the whole set of propertysets atomic. The undo will have to undo all applies on all objects that where selected at the time).

However. We or I am expecting support for this in Dia in the next release. They told me this has been a very frequently requested feature. So I guess it’s good news for all the Dia users that people, like Lars and me, are working on this today.

I got myself interested in clipboards again. I kinda lost my interest
while trying to maintain gnome clipboard manager a few years ago. The
clipboard of X has lots of problems which I wanted to tackle by doing a
clipboard manager.

I didn’t succeed for the simple reason that the X clipboard wasn’t very
accesible. For example to know when another xclient became the owner of
the current clipboard, you had to make sure you (as a clipboard
manager) had to own it at all times. By stealing it from the new owner
and claiming ownership. Simply because the only event available was
“you have lost the ownership”. Well actually, I did succeed in creating it. But I didn’t in making it actually being used. For the application itself was ugly clumbsy and needed to perform horribly ugly tricks to get it’s job done.

The new xfixes
extensions, however, make it possible to know about clipboard-owner
changes more easily. Therefor some common clipboard manager tasks can
be done more easily today. I’d like to create a common clipboard
manager daemon that can be shared by different popular desktop
environments.

Some of the tasks such a clipboard manager could do:

• Make the clipboard persist when an xclient who’s owning the clipboard is about to die
• Make the clipboard persist between X sessions
• Create a clipboard-history
• Share clipboards between different hosts

I also want to tackle the problem that an xclient needs to first
deliver it’s clipboard to the xserver when another xclient is
requesting it. While often both xclient processes are running on the
same host, the xserver isn’t always. It makes sharing larger clipboards,
in such a situation, a very network intensive job. It causes lots of
network-traffic. And honestly, it’s slow. In my humble opinion, it
would be better to utilise an Inter Process Communication mechanism. An
added advantage would be that sharing the clipboard between non xlib
applications and xlib applications could take place much more easily.
Today this is only possible while utilising a clipboard manager or an
xclient like xterm which will copy it to the console-window it’s
displaying, as if it’s being typed by the user. Imagine vi supporting
pasting the HTML-source behind the selected text of your Firefox
instance without the need for first going to the source of the website
you’re viewing. Imagine two instances of vi copy and pasting to each
other in both directions without the need of temporary files (which is
more or less how mcedit does it). Imagine copy and pasting on the
console as easy as today on X.

One problem with implementing such an idea was the fact that there
wasn’t an IPC-system being liked by the programmers of the popular
desktop environments. For example KDE preferred to use DCOP whereas GNOME preferred
ORBit. Today, however, a new such mechanism is being designed just for
the purpose of desktop inter process communication by the
freedesktop.org organisation: DBUS.

We have all the ingredients to implement these idea’s. I am working on
a very first piece of testing code here. For
non-programmers there’s nothing interesting to see there at this
moment.

There’s a discussion about this going on at the xdg mailinglist of freedesktop.org.

Yesterday I invited Gaute Hope and Kristof Vansant to this advogato-site. They are co-authors of the gnome-schedule module. Gnome-schedule is a userinterface for configuring the crontab and at daemons. In some future Gaute Hope is planning to add support for anacrontab.

If you are interested in scheduling mechanisms, you also want to checkout (the highly unfinished project) Eventuality
by Maciej Katafiasz which promises a scheduling mechanism that works like how GConf works for configuration. So events to which you can subscribe to in your applications.

We’re planning a first stable release of gnome-schedule very soon. Dag Wieers will probably create Fedora packages for it. It’s being written in Python and uses PyGtk.

Personally I started to dislike Python and PyGtk after this first project I made with it. It’s not really something for me. I’m one of those developers who like to code with and for the very latests GNOME technologies. PyGtk from CVS offers that, but the distributions weren’t using such an unstable version of course. So it has been holding me back lots of times during development, and is has been holding back a packaged release for various distributions. Next time I’ll just use plain C or perhaps C++. Maybe C# once it’s going to be adopted by the distributions. Other than that doesn’t python feel like my programming language. Sorry.

However, it looks like both Gaute Hope and Kristof Vansant liked it for the purpose of creating gnome-schedule. So I guess it’s okay as a development environment for many other people

Hey wlach! Glad to read that at least one person used that little document. I’ve noticed indeed that some comments about Ubuntu where added. Which is an addition I like, of course.

So now you got it’s code compiled (the code of Evolution) nothing is stopping you from exploring it and perhaps making contributions? I suggest you take a look at the plugins/ directory. There’s lots of work todo! The Evolution dudes organise an IRC-meeting from time to times. Hackfests. Join the next one?

Also check out the developer pages for Evolution.

Oh and Damien: I’m very interested in that GnomeMeeting and GAIM integration -topic. What can be done to still get some integration between Gaim and GnomeMeeting going? Or perhaps with other Instant Messaging clients?

My personal opinion on Desktop Integration is that a (new) foundation like freedesktop.org should focus on this subject and get projects to work together.

This must be my first diary/blog ever created. So bear with me, I am not sure what to put here. Hmm, perhaps something about this new EPlugin system of the current Evolution CVS HEAD-tree.

A few weeks ago I got interested in exploring the newest features of the upcoming Evolution. So I decided to checkout the different modules needed to compile it. After I was done I decided to put online a wiki page explaining how to actually compile that Evolution code.

Then I started reading about EPlugins. There’s not much information available already so most of the times I dived into the code of the current EPlugins and into the other Evolution code. I really hope more development information about EPlugins is going to become available as the new developer-feature gets more known.

I decided to implement a GNOME Bounty of last year using the existing save-calendar plugin. The plugin already supported saving a calendar in the ics-format. The bounty, however, asks for a comma separated value format. Novell/Ximian hasn’t payed me the $300 yet but, thats okay. Surprisingly they (and more specifically Rodrigo) did, however, accepted my patches! Which is actually, for me, my real reward. Thanks Rodrigo!

So with lots of new enthusiasm I went further and implemented support for the RDF-format too. Sooner or later it also got accepted. The resulting RDF-file should be verifiable against the RDF-schema but I haven’t yet tested it with a lot calendar-types/records.

When in a few months you right-mouse click on a Task-List or Calendar in Evolution and choose “Save”. Most of what you can use and do is what I’m describing here.

Next on my list is fixing the ics-support. At this moment it’s writing a single ics-file (calendar.ics or tasks.ics) in a directory while the dialog is letting the user choose a filename rather than a directory-name. And this way it’s also not really using gnome-vfs.

For now people using Evolution from CVS can checkout the code for all this here.
Actually, I gave you the link which will explain you how to compile evolution from CVS. So everybody: Have fun.