Older blog entries for pvanhoof (starting at number 6)

13 Mar 2005 (updated 13 Mar 2005 at 16:48 UTC) »
16 Jan 2005 (updated 16 Jan 2005 at 11:16 UTC) »
Friday the fourteenth

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.

13 Jan 2005 (updated 13 Jan 2005 at 20:36 UTC) »
Having fun with Dia code: The properties of all selected objects in a diagram

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.

9 Jan 2005 (updated 22 Mar 2005 at 08:55 UTC) »
Tackling the many problems I have with clipboards on the current UNIX desktop

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.

22 Dec 2004 (updated 22 Dec 2004 at 16:02 UTC) »
Introducting the people behind gnome-schedule

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

21 Dec 2004 (updated 21 Dec 2004 at 11:10 UTC) »

This is a repost (old nickname nolonger in use) (original posting date was 21 Dec 2004)

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.

21 Dec 2004 (updated 21 Dec 2004 at 11:05 UTC) »
Adding calendar exporting features to Evolution

This is a repost (old nickname nolonger in use) (original posting date was 20 Dec 2004)

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.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!