Month: April 2006

The newer Linux kernel releases will have a feature to drop caches in a clean way. Leio blogged about this. Check it out of you are into testing performance.

I very often write my blog entries and E-mails using gedit. For a lot such posts and E-mails I use HTML. So I started thinking, maybe I should write a gedit plugin that will allow me to copy the HTML source text in gedit and paste it as a text/html target?!

So I did that. (you can follow-up using this bug)

As on IRC Paolo was quite interested, I guess Paolo and/or Steve are going to clean it up and add it to the available gedit plugins soon?

For now I didn’t add pasting HTML source code from a “text/html” TARGET capable selection owner (like OpenOffice.Org, Evolution or Firefox) to gedit. Shouldn’t be very hard to add that. Be ahead of me if you really need that.

Update and FYI: Paolo redid the plugin in Python because such a Python plugin does not need a compilation procedure.

About the Adapter thingy of Friday: Matooo added support to the Gtk.ComboBox and the Gtk.ComboBoxEntry and fixed some annoyances. He also updated the demo so that it uses a multi-column Gtk.ComboBox, Gtk.ComboBoxEntry and a Gtk.TreeView.

The proof of concept is still an experiment so don’t count on anything becoming stable. Mike Kestner (one of the gtk-sharp developers) commented on the experiment here.

If you want to join experimenting, just ask me for a subversion account. I already gave Matooo one. So :-) update your checkout frequently.

Somebody asked for it and since it might be interesting, I’ll blog it.

This is the UML Class diagram of the IList adapter POC which I mentioned yesterday and which you can use for databinding with the Gtk.TreeView in a typical .NET fashion (so using your own IList as true datastore or list model).

As you can see I used a variation of the adapter design pattern.

ps. I typically use KDE’s Umbrello for making UML Class diagram because well .. Dia is very limited for UML, ArgoUML and Poseidon are slow and Gaphor isn’t finished. Actually is Umbrello also very buggy and it doesn’t write valid XMI files (but no free software tools do, perhaps maybe ArgoUML). Perhaps I should try ArgoUML one more time?

I did it again. I got arrogant while being excited about how we should make it more easy for language bindings to implement types that adapt the many C-isms we introduced in GObject and Gtk+. And as a result I got myself in the situation of having to prove the concept. Which most of the times isn’t a big problem. Often it’s just some work.

So by telling me that if I’d look at the NodeStore and NodeView implementations in gtk-sharp by Mike Kestner I could implement my ideas, toshok invited me to create such a proof of concept. I looked at it and decided that he was right about the fact that it’s possible. So I decided to do it.

The problem with the ListStore and TreeStore models is that in a correct Model View Controller paradigm, you don’t couple the model and the view. You decouple everything that is related to viewing the model, from the model. You put it in the view. That’s the purpose of the view! When implementing a GtkTreeModelIface you have to implement the typing of the columns in the model. “Columns”, is information about viewing the model. Fortunately for sanity but unfortunately for gtk-sharp this isn’t how it’s typically done in a programming environment like .NET.

In .NET (in this example System.Windows.Forms) you can do for example (say you have a Person object with a Name property):

DataGrid view = New DataGrid (); // Or use the .NET 2.0 DataGridView
DataGridTableStyle table = new DataGridTableStyle();
table.MappingName = "Person[]";
DataGridColumn column = new DataGridTextBoxColumn ();
column.MappingName = "Name";
table.DataGridColumns.Add (column);
view.DataGridTableStyles.Add (table);

Person [] persons = factory.GetPersons ();
view.DataSource = persons;

Types like the ComboBox also work like this. If you ask for the combo.SelectedItem, you get a Person instance. For the Gtk.TreeView the story is different: You can’t use a simple IList like the DataTable or collection types immediately. You have to flow them into a ListStore or a TreeStore first. And on top of that, you have to put column information in the model. Many OO designers will tell you that is wrong, others will tell you that now it no longer matters that the model and the view are two things. They are coupled for ever. So why do it in the first place? I’ve seen wrapper API’s that add a AddLine to the view. This is of course totally not the Model View Controller paradigm anymore.For a typical .NET developer, this is at least strange. It makes the model not reusable. So you end up creating user interface types and code that shouldn’t be there. And the Model View Controller paradigm eventually also gets lost. As the model is coupled with the view (it’s not reusable).

So basically: it’s not really how to do it correctly.

What you want is to set a datasource (the list model), and adjust the view so that it understands what to do with the datasource. But don’t require view related changes to the datasource (the list model). So I implemented a GtkTreeModelIface in C# and did it as an adaptor that will convert the C-isms to .NET.

The implementation will basically implement GtkTreeModelIface in C# (which was the hardest part). In stead of keeping my own store (for example by copying the references to an ArrayList), I inject the original IList into the custom tree model implementation and use that as store. Once done I simply use the integer index as TreeIter token and check for the Count property of the IList interface for letting the view know that it can ask for more rows/instances. That way it effectively adapts the IList to a TreeModel.

It’s an ugly ui application but read the code and run it while reading: you’ll understand what it does. You can get a checkout using this SVN repository. It should load in for example MonoDevelop.

So if I translate the above sample to this, you get something like this:

Person [] persons = factory.GetPersons ();
TreeViewAdaptor view = new TreeViewAdaptor ();
view.AppendColumn ("Full name", "Name");
view.DataSource = persons;

So when the GtkTreeView (the C thing) needs data from the model, it will ask the C# GtkTreeModelIface implementation for that data. And that implementation will use your Person instances and your IList instance. Not a copy. As a proof, feel free to put breakpoints at the getters and the setters in the Name, Surname and Number properties of that Person type. Or implement your own IList in stead of using the ArrayList (the demo is using an ArrayList) and follow when it’s asking for items by adding breakpoints in your IList implementation.

Know what? Simply check out the source of the demo. You’ll see.

I’ve been editing this gdc.spec in such a way that the resulting D compiler works correctly with your existing FC4 gcc installation. As the gdc patches don’t yet work on the gcc version of FC5, I didn’t repeat it for FC5 yet.

So I announce the direct availability of a gdc package for Fedora Core 4 and the stuff for building it (like the source RPM) yourself. Please do not consider this package as an official package. It’s not, I repeat, it’s not an official package. And I’ll repeat it again: it’s not an official package.

Please join the D.gnu newsgroup if you are interested in building packages for other distributions.

[root@zeus ~]# rpm -e gdc
[root@zeus ~]# gdc
-bash: /usr/bin/gdc: No such file or directory
[root@zeus ~]# rpm -Uvh /usr/src/redhat/RPMS/i386/gdc-0.17-0.i386.rpm
Preparing… ########################################### [100%]
1:gdc ########################################### [100%]
[root@zeus ~]# gdc test.d
[root@zeus ~]# ./a.out
Yes
[root@zeus ~]# cat test.d
import std.string;
extern (C) int strcmp(char* string1, char* string2);
int myDfunction(char[] s) {
return strcmp(std.string.toStringz(s), “foo”);
}
int main () {
if (myDfunction (“foo”) == 0)
printf (“Yes\n”);
else printf (“No\n”);
return 1;
}
[root@zeus ~]# cat /etc/issue | head -n 1
Fedora Core release 4 (Stentz)
[root@zeus ~]#

I finally compiled myself gdc, a d frontend for gcc. Surprisingly it was very simple.

I basically had to unpack the gcc tarball, cd into gcc-4.0.3/gcc/ and unpack the gdc tarball which created a d sub directory. Then cd .. and run ./gcc/d/setup-gcc.sh which basically patched the gcc sources which added the d language.

Then I had to make a build directory, I decided to create /opt/gdc and then cd /opt/gdc. And then simply run (from that directory) /path/gcc-4.0.3/configure –prefix=/opt/gdc –enabled-languages=d,c,c++ followed by make and make install. Easy!

I’m planning to experiment with the d programming language and I will probably do all my concept-projects using this programming language. I’m for example planning to implement a reference implementation of deconf-spec in d. But I guess it depends on the results of the experiments I’m going to do.

Surprisingly some people where silently interested in the standard about configuration of user software. So I added some chapters and restructured the document a little bit. Just in case.

There’s still a lot specification-work to do. Most people probably can’t imagine why. Others simply start implementing. I don’t think the approach will work for this. But anyway, if people want to do that they should.

In my humble opinion can’t the configuration problem be solved by just hacking together an implementation. In fact aren’t the proposed solutions solving any real problems. GConf and KConfig solved those problems already. Unifying them is a.t.m. pointless. And actually as the proposed solutions introduce yet another ad-hoc standard, they in stead add to the problem.

More about this and also read this.

ps. I might soon also post some UML class diagrams of the current idea I have for the reference implementation of the service. I also have some working experiments. Vaporware–, it’s more about popping todo items.

Project deconf isn’t per definition implementing a replacement for existing systems like KConfig nor GConf. In fact do these systems work and don’t need a replacement.

Project deconf is about first specifying and then building infrastructure for futuristic computing environments. I foresee that most of the really used Information Technology will become embedded in specialized devices.

Take for example the iPod, cellphones, VoIP phones, personal data assistants, navigation assistance, digital television, printers that don’t need a desktop and soon instance messaging and video conferencing hardware. I have to conclude: Most people hate desktop computing. A lot people love the technology that it created. It’s not surprising Steve Jobs is again pioneering it with the iPod.

The focus of deconf (which will probably be renamed a few more times) is specifying and then building infrastructure that will survive and be useful in such a future computing environment. So this basically means that there’s a focus on distributed configuration management, on keeping the requirements small and most importantly, making every piece of technology replaceable.

Anyway. As a lot people hate it when you talk about configuration management and as I don’t really care about those people (and I certainly don’t want to spark yet another flamewar about it). Here’s what I really wanted to blog about.

By the way, I know I should cut my introductions.

As David was so smart to join a discussion about configuration management, I decided to for one evening put aside my work on tinymail and improve that funny specification of mine.

I actually even renamed it from A standard for desktop application configuration to A standard for user software configuration. It’s a much better description of what the specification is about. It’s about user software. Not just desktop applications.

I’m done, you guys can now continue calling things vaporware, flaming about configuration management and blocking innovation happening from the free software camps. So that soon, when Apple or Microsoft decide to do implement it, you can all start whining about how they should make that open. So that we can catch up, again.

GUnit

On Friday Peter Hagg has put the official GUnit documentation online.

There’s a manual, API reference and some demos (like a “Our first test case”) and samples.

GMainLoop vs. worker thread

A few days ago Emmanuele blogged about “Lazy loading”. He illustrates how to make it possible to offload the loading of many items in for example a liststore. Yet not having to use a worker-thread.

Interestingly I used the exact same technique for destroying the header proxy instances in the summary view of tinymail. ps. Grep for “relaxed” in that source-code.

Note that tinymail uses proxy instances and a custom gtktreestore implementation for making it possible to show huge amounts of rows in the view (yet not using a lot memory, which is the most important aspect of tinymail). It basically uses the model view controller paradigm in such a way that only the visible rows are really loaded. It really depends on the context which technique you should use. So called “programming patterns” (like design patterns) don’t exist to force you into using a specific one. They serve as a guideline.

I guess both samples illustrate that you can do various tasks in the background without using threads.