Month: January 2005

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.