Welcher Windows-Benutzer kennt sie nicht, die beliebte Registry, in der das System und diverse Programme die Konfigurationsdaten speichern – oder auch nicht, oder teilweise. Aber immerhin ist sie ganz einfach zu bedienen: mit der Maus. Es geht sogar noch ein bisschen einfacher.

Wie immer soll alles – vollmundig versprochen – besser und schöner werden. Diesmal geht es um die Möglichkeit, Konfigurationsdaten für Programme an einer einzigen zentralen Stelle zu speichern, zu verwalten und bei Bedarf abzufragen, beispielsweise beim Programmstart. Die Gnome-Entwickler haben begonnen dafür einen Mechanismus an den Start zu bringen, dem sie den Namen GConf gegeben haben.

GConf soll in der Version 2.0 von Gnome vollständig Einzug halten, liegt aber in einem Paket schon im Unstable-Tree des Quellcodes vor. Einige neue Programme, zum Beispiel Nautilus und Evolution, verlangen bei ihrer Kompilierung bereits jetzt nach GConf. Die Bibliothek soll jedoch nicht auf Gnome beschränkt bleiben, sondern sich letztlich auch für reine Gtk+- und X-Applikationen, KDE-Programme und sogar von der Kommandozeile aus verwenden lassen.

Laut Havoc Pennington in [1] – einem Artikel, an den ich mich im Folgenden stark anlehnen werde – steckt Gnome, was die Konfiguration von Applikationen betrifft, im Stadium von Windows 3.x, weil jedes Programm seine eigenen Einstellungen in separaten Dateien ablegt. Mit der Registrierungsdatenbank unter Win9x sei ein schlauer Schritt vollzogen worden, allerdings mit diversen Einschränkungen:

Dem Artikel zufolge möchte GConf mit einem zweischienigen System sowohl eine Bibliothek als auch eine Architektur zur Verfügung stellen, was sich wie folgt gestalten soll.

Das Konzept

In der Theorie soll GConf einen Haufen Vorteile bieten, wenn es erst mal fertig und ausgereift ist. So ist das eben: Wir reden von freier Software im Anfangsstadium mit erheblichen Ansprüchen an das, was einmal werden soll.

Das beginnt bei der Unabhängigkeit vom Back-End, in dem die eigentlichen Daten gespeichert werden sollen. Die aktuelle Implementation speichert alles in XML-Dateien ab, die sich natürlich, wenn man nur von Files ausgeht, für hierarchische Organisationen am besten eignen.

Aber auch ein binäres Format soll möglich sein wie bei der Registry, und wer richtig loslegen möchte, kann den Zugriff auch über LDAP oder sogar eine SQL-Datenbank seiner Wahl regeln. Die Idee dahinter ist, dass sich der Administrator eines Netzwerks ganz einfach das aussuchen kann, was ihm am besten in seine Infrastruktur passt.

1: 
2: #include <gconf/gconf-client.h>
3: #include <gtk/gtk.h>
4: 
5: void callback (GtkWidget* entry, gpointer user_data)
6: {
7:   GConfClient *gclient;
8:   gchar       *str;
9:   
10:   client = GCONF_CLIENT (user_data);
11: 
12:   str = gtk_editable_get_chars (GTK_EDITABLE (entry), 0, -1);
13: 
14:   gconf_client_set_string (client, "/extra/de/derfrosch/linux-magazin/gconf", str, NULL);
15: 
16:   g_free(str);
17: }
18: 
19: int main(int argc, char *argv [])
20: {
21:   GtkWidget   *fenster;
22:   GtkWidget   *entry;
23:   GConfClient *gclient;
24: 
25:   gtk_init (&argc, &argv);
26:   gconf_init (argc, argv, NULL);
27:   
28:   fenster = gtk_window_new (GTK_WINDOW_TOPLEVEL);
29:   entry = gtk_entry_new ();
30: 
31:  gtk_container_add (GTK_CONTAINER (fenster), entry);  
32: 
33:  gclient = gconf_client_new ();
34: 
35:  gconf_client_add_dir (gclient, "/extra/de/derfrosch/linux-magazin/gconf", GCONF_CLIENT_PRELOAD_NONE, NULL);
36: 
37:  gtk_signal_connect (GTK_OBJECT (entry), "activate", GTK_SIGNAL_FUNC (callback), gclient);
38:   
39:  gtk_widget_show_all (fenster);
40: 
41:  gtk_main();
42: 
43:  return 0;
44: }

Die einzelnen Keys – es werden ähnlich wie bei der Registry Daten in Schlüssel/Werte-Paaren gespeichert – sollen je ein eigenes Feld zur Dokumentation erhalten, das dann durch eine Applikation, mit der sich die Werte verändern lassen, dargestellt wird. Zusätzlich sollen weitere Informationen zu speichern sein, beispielsweise wann der Schlüssel das letzte Mal geändert wurde. Aus der bisherigen Dokumentation ist nicht zu ersehen, ob vielleicht ein Mechanismus vorgesehen ist, der das Editieren bestimmter Keys verhindern oder privilegieren kann.

Außerdem soll es einen Data Notification Service geben. In der Zeit der Komponenten, in der jedes Programm mit jedem anderen kommunizieren kann, ist es sinnvoll, Änderungen im Netzwerk so zu propagieren, dass alle Applikationen, bei denen das gewünscht ist, sich entsprechend umkonfigurieren.

Dieses Konzept ist auch deshalb interessant, weil man auf diese Weise laufende Programme umgestalten kann. Beispielsweise mit einer Einstellung, die festlegt, dass alle Toolbars keine Icons mehr zeigen sollen, und dafür sorgt, dass diese Änderung sofort in allen Programmen Gestalt annimmt. Ich weiß allerdings nicht, ob ich der Einzige bin, für den sich das nach einem äußerst interessanten Ansatzpunkt dafür anhört, ein ganzes Netzwerk von Rechnern empfindlich zu stören.

Eine von Anfang an gut durchdachte API – also das Gegenteil zu dem, was im Moment bei Bonobo betrieben wird – und zusätzliche Details wie ein sinnvolles Locking sollen das Ganze abrunden.

Da lediglich Schlüssel/Werte-Paare gespeichert werden sollen, handelt sich auch nicht wirklich um eine Datenbank. Jeder Schlüssel hat wie unter Windows einen eindeutigen Namen. Um die Hierarchie darzustellen, wird ein System benutzt, das an das Dateisystem unter Unix erinnert: ein Schlüssel könnte zum Beispiel /programme/editor/fenster/schriftart heißen. Die Werte sind typisiert, werden also bereits vorher zum Beispiel als String, Integer oder durch einen anderen Datentyp festgelegt.

1: #include <gconf/gconf-client.h>
2: #include <gtk/gtk.h>
3: 
4: void callback (GConfClient* client, guint cnxn_id, const gchar* key, GConfValue* value, gboolean is_default, gpointer user_data)
5: {
6:   GtkWidget *label;
7:   
8:   label = GTK_WIDGET (user_data);
9: 
10:   if (value == NULL)
11:   {
12:     gtk_label_set(GTK_LABEL(label), " leer ");
13:   } else {
14:     if (value->type == GCONF_VALUE_STRING)
15:     {
16:       gtk_label_set (GTK_LABEL (label), gconf_value_string(value));
17:     } else {
18:       gtk_label_set (GTK_LABEL (label), " falscher Typ! ");
19:     }
20:   }
21: }
22: 
23: int main(int argc, char *argv [])
24: {
25:   GtkWidget   *fenster;
26:   GtkWidget   *label;
27:   GConfClient *gclient;
28:   gchar       *str;
29:   
30:   gtk_init (&argc, &argv);
31:   gconf_init (argc, argv, NULL);
32: 
33:   gclient = gconf_client_new();
34:   fenster = gtk_window_new (GTK_WINDOW_TOPLEVEL);
35: 
36:   str = gconf_client_get_string (gclient, "/extra/de/derfrosch/linux-magazin/gconf", NULL);
37:   
38:   if (str)
39:   {
40:     label = gtk_label_new (" leer ");
41:   } else {
42:     label = gtk_label_new (str);
43:   }
44: 
45:   if (str)
46:   {
47:     g_free (str);
48:   }
49:   
50:   gtk_container_add (GTK_CONTAINER (fenster), label);
51: 
52:   gconf_client_add_dir (gclient, "/extra/de/derfrosch/linux-magazin", GCONF_CLIENT_PRELOAD_NONE, NULL);
53:   gconf_client_notify_add (gclient, "/extra/de/derfrosch/linux-magazin/gconf", callback, label, NULL, NULL);
54:   
55:   gtk_widget_show_all (fenster);
56: 
57:   gtk_main();
58: 
59:   return 0;
60: }

Ein Dämon und mehr

Um GConf benutzen zu können, muss eine Dämon mit dem Namen Gconfd laufen. Es soll immer genau einen Dämon pro Benutzer geben, der sich über CORBA mit Applikationen verständigen kann.

Eine wichtiger Grad Abstraktion, der zum Beispiel auch bei einigen Widgets in der Gnome Application Library zum Tragen kommt, trägt den Namen MVC. Sein Konzept wird im Kasten “Model – View – Controller” näher erläutert.

Es gibt einige verschiedene Datentypen, mit denen man bei GConf herumhantieren kann. Es sind: GConfEngine, worüber eine Konfigurationsdatenbank angesprochen wird. In den meisten Fällen handelt es sich dabei um die Verbindung zu einem laufenden Gconfd-Dämon. Hinzu kommen GConfValue, eine Struktur, die die typisierten Werte aus einem Schlüssel/Werte-Paar kapselt, sowie GConfClient, ein Client, der mit einer GConfEngine kommunizieren kann, zudem diverse kleine Schmankerln wie Caching und schließlich GConfError, eine Struktur, mit der sich Fehler handhaben lassen.

Beispiel

Jetzt darf natürlich ein kleines Beispiel nicht fehlen. Die beiden Listings 1 und 2 enthalten einen Client und einen Controller, die die Funktion von GConf demonstrieren. GConf muss dafür natürlich installiert sein, entweder, indem man es explizit tut wie im folgenden “Installieren”-Kasten kurz beschrieben, oder indem man beispielsweise den Ximian-Desktop [4] installiert hat.

GConf muss wie Gtk+ initialisiert werden. Es wird sodann ein neuer Client erzeugt, der über die Verbindung mit einem Signal an die Callback-Funktion übergeben wird. Tippt man nun einen Text in das Eingabefeld und schließt mit der Return-Taste ab, wird der Inhalt des Feldes ausgelesen und im Callback als Wert in den Schlüssel geschrieben.

Wie bereits aus den Include-Zeilen ersichtlich, ist GConf tatsächlich nicht Gnome-abhängig. GConfClient benötigt im Moment noch das Linken gegen Gtk+, aber auch dieser Missstand soll noch aus der Welt geschafft werden.

Im zweiten Listing wird erst ein eventuell schon vorhandener Key ausgelesen und in einem Label dargestellt. An dieser Stelle ist es wichtig, den Zeiger str mit g_free() wieder wegzuwerfen, da man eine Kopie übergeben bekommt. Nachdem das Label ins Fenster eingefügt ist, wird das Programm angewiesen, auf Änderungen im betreffenden “Verzeichnis” zu reagieren.

Dann erfolgt ein Aufruf der Callback- Funktion, wenn beispielsweise der Client in Listing 1 benutzt wird. Die restlichen Zeilen im Callback dienen im Wesentlichen dazu, den ausgelesenen Wert auf den korrekten Typ – einen String – zu testen. Enthält der Key keinen String als Wert, wird ein entsprechender Hinweis abgesetzt. Ist gar kein Wert gesetzt, wird auch darauf hingewiesen.

Der verwendete Key befindet sich unter der Extra-Hierarchie, die für Ergänzungen durch dritte Personen eingerichtet worden ist. Ich denke, dass eine weitere Unterteilung durch Domainnamen, wie hier mit meiner eigenen vorgenommen, durchaus Sinn ergeben könnte.

tar xzvf GConf-0.x.x.tar.gz
cd GConf-0.x.x
./configure
make
make install

GConf in Gnome 2.0

Es wurde schon darauf hingewiesen, dass GConf erst in Version 2.0 voll in Gnome integriert werden soll. Dabei geht es auch um den Einbau einiger kleiner. Zum einen soll ein globaler Client für einen eingeloggten Benutzer laufen, der über einfache Funktionen der Gnome-API ansprechbar ist. Hinzu kommen noch Dialoge im Gnome-Stil und diverse andere Funktionen, die man braucht, um als Programmierer GConf komfortabel nutzen zu können.

Fröhliches Gnomen! ( uwo)