devfs is dead!

Yay! and thanks to Greg Kroah-Hartman for killing it.

GTK TreeModel implementations and language bindings.

I have tinkered with gtk+ many times in the past for various reasons. This has included my own mini-projects as well as changes to more widely used apps.

Only recently though have I tried anything more serious with it. This time it is via the gtk# binding using mono. Overally, I’m impressed with gtk#. It manages to stay close enough to the standard c api for gtk+ that anyone familiar with it could use gtk# easily, but also it gives a more c# friendly api where it matters.

One thing I wanted to do that is fairly important to my project was to write a custom TreeModel implementation. The reason is that the data will be retrieved on demand from a webservice running on another machine on the LAN and cached in the model implementation. I don’t want to use the usual TreeModel implementations because they use the “push model” and that would mean loading all the data ahead of time. Not good.

Easy, I thought. I just write a class that implemented TreeModel and code up the required methods. Not so. Apparently it is not possible yet to implement GInterfaces when using gtk#. Now, I have tried to think about what this might involve to implement in gtk# and I freely admit I got lost very quickly. Writing a binding for anything glib based cannot be a simple task.

However, I can’t help thinking this is something of a glaring omission. In fact, it pretty much means (as far as I can see) that I have to either:
1) Wait until gtk# allows this.
2) Put hacks into my project such as the ManagedTableModel that is floating around. (which will make portability slightly harder because I have to worry about DllImport - yes, I’m lazy)
3) Wait until gtk# provides something like ManagedTableModel itself
4) Choose another platform.

I started to wonder if this is possible in other gtk+ bindings. I haven’t searched exhaustively, but it appears that neither java-gnome or pygtk support this either. (anyone please correct me if I am wrong.) pygtk does have a solution for my case in the form of GenericTreeModel that can be extended and would work brilliantly.

Maybe I should be looking at using python and pygtk instead then?

Faster yum?

I just noticed that a new package called yum-metadata-parser has gone into rawhide. Interesting.

10 seconds googling later reveals that it’s a ~10 times faster yum metadata parser that is reported to also use a lot less memory. This might make fedora suddenly useable on a whole bunch of my machines. I look forward to trying it out.