Category Archives: KDE

Beiträge zu KDE Programmen

Spellchecking, KDE 4, OO 3, Thunderbird

Posted on by

Wieder mal ein Beitrag aus dem bunten Linux-Alltag. Diesmal zum Thema Wörterbücher. Auch hier nimmt die Vielfalt und damit die Verwirrung des Anwenders zu, wie ich heute wieder erfahren durfte.

Das Vielfalts-Problem

Meine liebe Anne ist Norwegerin und benutzt ein Opensuse Linux mit deutschem KDE 4. Nun steht sie natürlicherweise immer mal wieder vor folgenden Aufgaben

  • Verfassen von E-Mails auf Norwegisch mit Thunderbird
  • Verfassen von E-Mails auf Norwegisch auch mal mit Kmail
  • Verfassen von norwegischen Texten mit Openoffice

In all diesen Fällen möchte sie natürlich gerne eine Prüfung der Rechtschreibung der Wörter in norwegischer Sprache vornehmen lassen, um Tippfehler schnell korrigieren zu können.

Leider ist es nun nicht so, dass für diese Aufgabe unter Linux/KDE ein einheitlicher Spell-Checking-Mechanismus herangezogen würde, der sich auch einheitlich bedienen ließe. Und deswegen lief bei der guten Anne heute das Linux-Frustrations-Fass mal wieder über – mit der unmissverständlichen Aufforderung, ihr gefälligst ein brauchbares Arbeitsgerät bereitzustellen.

Tatsächlich muss man feststellen, dass in puncto “spell checking” zur Verzweiflung des Anwenders eine Vielfalt blüht, die nicht nur applikations- sondern auch noch versionsabhängig ist. Und in den von meiner Frau benutzten Anwendungen muss man doch recht spezielle Schritte unternehmen, um zum Erfolg zu kommen.

So wurde bei Openoffice mit dem Übergang von OO 2.4 auf OO 3.0 von “myspell” auf “hunspell” gewechselt. Gleichzeitig kam für den Anwender (oder den Admin) die Notwendigkeit, “add-ons” installieren zu müssen. So mancher Admin, der sich nicht um individuelle EInstellungen kümmern mochte, vergaß allerdings, seine Kollegen/innen auf diesen Umstand hinzuweisen.

Ähnliches gilt für Thunderbird und Firefox; auch hier wurde mit der Version 3 auf “hunspell” gewechselt. Blöd nur, dass einige der für Firefox und Thunderbird bereits etablierten “add on” Wörterbucher – leider auch die norwegischen – wegen Kleinigkeiten eine ganze Weile lang nicht mehr mit Firefox Version 3.6 und Thunderbird Version 3.x kompatibel waren.

KDE 4 setzt dagegen auf die GNU “aspell”-engine, die “ispell” ablöste und mit UTF-8 umgehen kann. Hier müssen die notwendigen Basis-Einstellungen für eine Reihe von KDE-Applikationen nicht in den Applikationen selbst, sondern in den KDE-Systemeinstellungen vorgenommen werden.

Was also muss man unter Opensuse 11.2 und KDE 4.4.3 für die oben genannten Anwendungen genau tun, um z.B. ein norwegisches Spell Checking hinzubekommen?

Maßnahmen für KDE und damit auch für Kontact/Kmail

Man installiere (z.B. über Yast) zunächst die erforderlichen “aspell”-Sprach-Pakete (myspell-Pakete nutzen hier nix!). Im Fall von Norwegisch sind das die Pakete “aspell-nb” (bokmaal) und “aspell-nn” (nynorsk). Danach kann man unter KDE4 über die Systemeinstellungen

“Systemeinstellungen >> Land/Region und Sprache >> Rechtschreibprüfung”

kontrollieren, dass die Korrekturmöglichkeiten für die neuen Sprachen zur Verfügung stehen. Die “automatische Prüfung” aktiviert man über die entsprechende Checkbox. Einzelne KDE-Applikationen haben aber wieder eigene Schalter, die die Aktivierung oder Deaktivierung einer automatischen Rechtschreib-Prüfung während der Texteingabe steuern.

rechtschreib_KDE

Als Standardsprache haben wir in unserem
Fall “Deutsch” als Einstellung belassen. (Wenn man aber eher Texte in einer anderen Sprache verfasst, lohnt sich ggf. eine andere Einstellung.)

Unter Kmail setzt man das Spell Checking für Norwegisch dann nach dem Öffnen des Mail-Editors für eine neue E-Mail wie folgt ein:

Erst einmal die “automatische Rechtschreibprüfung” über den Menüpunkt “Optionen >> automatische Rechtschreibprüfung” deaktivieren, um bei der Eingabe des norwegischen Textes nicht von vornherein durch irritierende rote Linien gestört zu werden. Danach die ersten Zeilen schreiben. Dann “Extras >> Rechtschreibung” wählen. In der Dialogbox die richtige norwegische Sprache auswählen und nach Bedarf korrigieren. Danach kann man übrigens die “Automatische Korrektur” auch wieder anschalten. Der Spell Checker merkt sich diese Einstellung für die aktuelle Mail.

Es gibt jedoch ein vereinfachtes Vorgehen: Im Kopf der zu verfassenden Mails kann man sich eine Combox anzeigen lassen, die einem eine Combox “Wörterbuch” zur Sprachauswahl für die zu erstellende Mail anbietet. Diese Anzeige steuert man im E-Mail-Editor über den Menüpunkt “Ansicht” und die dort verfügbaren Optionen.

rechtschreib_KDE_Kmail

Das vereinfacht den Einsatz des Spell Checkings pro Mail natürlich kolossal: Im Gegensatz zum oben beschriebenen “Umweg” über die Menüpunkte legt man die für die neue E-Mail geltende Sprache gleich nach dem Öffnen des Mail-Editors fest. Die automatische Korrektur kann dann immer aktiviert bleiben.

rechtschreib_KDE_Kmail_2

Die Combobox ist vor allem dann wirklich sehr nützlich, wenn man abwechselnd Mails in unterschiedlichen Sprachen erstellt und dabei fortlaufend den Spell Checker einsetzen will.

Maßnahmen für Openoffice (OO) 3.x

Zunächst prüft man mit Hilfe des Paketmanagers seines Vertrauens, dass “hunspell” installiert ist. Bei dieser Gelegenheit das Paket für den Openoffice-Thesaurus für “Norwegeisch-Bokmaal” installieren (Paket “OpenOffice_org-thesaurus-nb”), falls das Paket angeboten wird.

Danach ein aktuelles “Add-on” für die norwegische Sprache aus dem Fundus der OO 3 Extensions installieren. Fündig wird man auf der Webseite

http://extensions.services.openoffice.org/en/dictionaries

Von dort lädt man für das Norwegische das oxt-File

“dictionary-no-NO-1.0.oxt”

herunter und installiert es in OO 3.0 über den Menüpunkt “Extras >> Extension Manager”. Danach OO neu starten. (oxt steht für Openoffice extension).

Die Rechtschreibungprüfung steht unter OO 3 ggf. bereits über ein Symbol in der Haupt-Toolbar-Leiste zur Verfügung. Wenn nicht kann man sich die Leiste um das entsprechende Icon erweitern. Ansonsten benutzt man “F7” und/oder die Sub-Menüpunkte unter dem Menüpunt “Extras” :

“Rechtschreibung und Grammatik, Sprache, Language Tool”

Im Dialogfenster zur “Rechtschreibung und Grammatik” kann man schließlich die Sprache für die Analyse des Dokumentes oder eines markierten Abschnittes auswählen. In unserem Fall stehen nach Installation des oben genannten oxt-Files die zwei norwegischen Sprachen “bokmaal” und “nynorsk” zur verfügung. Die Anwendung der Rechtschreibhilfe im Rahmen des Dialog ist intuitiv möglich. Auch die (begrenzte) Prüfung der Grammatik kann
man aktivieren.

Für das Anschalten einer automatischen Prüfung ist ein Punkt unter “Optionen” im Dialog-Fenster zuständig. (Oder alternativ ein Icon in der Toolbar).

Erstellt man Dokumente mit Abschnitten, die in unterschiedlichen Sprachen verfasst sind, legt man die Sprache pro Abschnitt über den Menüpunkt

“Extras >> Sprache >> Für den Absatz ”

fest. Das ist aus meiner Sicht eine wirklich nützliche Funktion! OO merkt sich die Sprach- und damit auch die einzusetzenden Prüf-/Korrektur-Module für die jeweilige Sprache abschnittsweise.

Natürlich kann man aber auch die Sprache für das gesamte Dokument festlegen. Diese Einstellung oder noch globalere sind auch über

“Extras >> Optionen >> Spracheinstellungen >> Sprachen ”

und

“Extras >> Optionen >> Spracheinstellungen >> Linguistik”

möglich. Der letztere Menüpunkt gibt zudem einen interessanten Einblick in die verwendeten Sprach- und Hyphenation-Module – es lohnt sich, da mal reinzuschauen.

Maßnahmen für Thunderbird und Firefox 3.x

Der Entwickler Håvar Henriksen hat für Bokmaal und Nynorsk schon im Jahr 2008 geeignete Wörterbücher als Add-Ons zu den Mozilla-Applikationen zur Verfügung gestellt. Leider liefen diese eine Weile nicht mit den neuesten Versionen von FF und Thunderbird zusammen. In der aktuellen Form der Bereitstellung gibt es aber keine Probleme mehr. Die folgenden Schritte sind praktisch identisch für FF und Thunderbird:

Zunächst den Menüpunkt “Extras >> Add-ons ” anklicken.

Im sich öffnenden Dialog den Menüpunkt “Alle Add-ons ansehen” wählen . Auf der sich öffnenden Webseite in der rechten oberen Combobox den Punkt “Wörterbücher” für die Suche auswählen. Dann die Suche starten und in der Liste blättern. Ca. auf Seite 3 findet man dann die “Norsk Bokmaal ordliste”. Das entsprechende xpi-File

“norsk_bokm__l_ordliste-2.0.10.0-fx+tb+sm.xpi”

lädt man sich am besten auf seinen Rechner herunter (für den Fall späterer Neuinstallationen).

Danach wechselt man wieder zum immer noch offenen “Add-On”-Dialog-Fenster der Mozilla-Applikation (das Fenster hatte man mit “Extras >> Add-ons” geöffnet). Dort findet man links unten einen Button “Installieren …”, den man anklickt. Der Rest der Installation wird über Dialogboxen geführt; man sucht die eben heruntergeladene Datei und startet den Installationsvorgang.

In Thunderbird 3..0.2 bedient man sich des installierten Wörterbuchs nun über einen entsprechenden Punkt in der Toolbar. Hier verbirgt sich rechts neben dem Schalter übrigens (ähnlich wie bei Kmail) auch eine Combobox; diese erlaubt einem, das einzusetzende Wörterbuch für die jeweilige Sprache auf einfache Weise auszuwählen.

Ansonsten kommt man auch über den in diesem Zshg. missverständlich lautenden Menüpunkt “Einstellungen” zum Ziel. Dort findet man den Submenü-Punkt “Rechtschreibprüfung”, den man anklickt. Die sich öffnende Dialogbox ist einfach zu bedienen. Eine automatische Prüfung während der Texteingabe aktiviert man in Thunderbird über “Einstellungen >> Sofort-Rechtschreibprüfung”.

Fazit

Das Einstellen der Rechtschreibprüfung auf der Basis passender Wörterbücher zeichnet sich unter
Linux noch durch eine wenig anwenderfreundliche Heterogenität aus, ist aber durchaus möglich. Selbst meien Anne war nach getaner Arbeit zufrieden.

In diesem Sinne wünsche ich den Linux-Usern also viel Spass in Zukunft beim Einsatz des “Spell Checkings” für unterschiedliche Sprachen unter KDE, Kontact/Kmail, Openoffice und Firefox/Thunderbird !

Von den Entwicklern wünsche ich mir dagegen eine Strategie zur Vereinigung der “Spell Checking”-Verfahren.

Anhang 1 – Tastaturlayouts nicht vergessen!

Unter KDE ist es natürlich flankierend wichtig, Tastatur-Layouts einzurichten. Das Norwegische kennt wie vele andere Sprachen auch Sonderzeichen, die auf bestimmte Tasten gelegt sind. Die Anne will beim Tippen in norwegischer Sprache natürlich so arbeiten wie auf einer norwegischen Tastatur.

Zu den Tastatur-Layout-Einstellungen gelangt amn unter KDE 4 über die “Systemeinstellungen >> Land/Region und Sprache >> Tastaturlayout”. Im Dialogfenster aktiviert man die gewünschten Tastaturbelegungen für unterschiedliche Sprachen und das Anzeigesymbol in der KDE Kontroll-Leiste. Da Leute wie die Anne mit unterschiedlichen Anwendungen in unterschiedlichen Sprachen arbeiten, habe ich ihr unter dem Reiter “Umschalt-Einstellungen” das Umschaltverfahren auf die jeweilige “Anwendung” bezogen eingestellt – statt der Einstellung “Global”, die die Sprache für die gesamte Oberfläche und alle Anwendungen umschaltet.

Anhang 2 – KDE-Koffice-Frust

In den aktuellen Koffice2-Programmen funktioniert das Spell Checking unter Opensuse 11.2 und KDE 4.4 überhaupt nicht.

Aber das ist eh’ egal, weil die Koffice-Entwickler nicht willens sind oder zu wenig Ressourcen haben, um das grauenvolle Font-Rendering unter Koffice 2 abzustellen. Die wiederholten Hinweise im Web, doch für KOffice2 bitte das Subpixel-Hinting bei der Font-Glättung abzustellen, ist einfach indiskutabel. Hier wedelt aus Anwendersicht der Schwanz mit dem Hund. KOffice2 soll sich bitte in KDE einfügen und seinen Einsatz nicht von einer Maßnahme abhängig machen, die zur Verschlechterung der Schriftendarstellung auf der gesamten Oberfläche führen würde. Tja, der User hat’s mit einigen KDE-Entwicklern nicht immer leicht. Sorry ….

Links

http://en.wikipedia.org/wiki/MySpell
http://en.wikipedia.org/wiki/Hunspell
http://en.wikipedia.org/wiki/GNU_Aspell

KDE 4, Sortierung, Groß-Klein-Schreibung, Bash

Posted on by

Hier wieder mal eine Geschichte aus dem Linux-Alltag. Gestern kam meine Frau zu mir und wollte unbedingt und kurzfristig ein kleines “KDE 4 -Problem” auf ihrem Opensuse 11.2-System gelöst bekommen.

Auftakt: Reihenfolge-Problem bei Bild-Dateien mit Gross- und Kleinbuchstaben unter Dolphin und Gwenview (KDE 4)

Mein Frau hatte diverse Bilder, die mit 2 verschiedenen Kameras und verschiedenen Chips gemacht worden waren, in einem Verzeichnis zusammengeführt. Im Nachhinein stellte sich dann heraus, dass es Dateibezeichnungen der Form “IMG_xxx.jpg” und der Form “img_xxx” gab. Insgesamt führte dies bei einer Betrachtung der Bilder über “dolphin” und “gwenview” unter KDE zu einer heillosen Verwirrung und “falschen” Reihenfolge der Bilder. Und das in der Gegenwart von Gästen, die natürlich alle Windows benutzen …

In meiner Naivität habe ich meiner lieben Frau in einem ersten Anlauf süffisant empfohlen, doch bitte unter Dolphin eine Sortierung nach dem Dateinamen durchzuführen und dann die großgeschriebenen Files, die alle an erster Stelle erscheinen würden, zu markieren und in einen separaten Ordner zu transportieren. Ganz so einfach gestaltete sich die Angelegenheit dann aber leider nicht – und die dann folgende Schelte hatte ich auch wirklich verdient.

Akt 1: Seltsame Sortierreihenfolge unter Dolphin und Konqueror

Was war das Problem? Der Punkt aus Sicht meiner Frau war der, dass bei der Sortierung in den genannten Programmen die Gross- und Kleinschreibung (scheinbar) nicht beachtet wurde. Dies führte im Fall der Bilder zu einer Vermischung von JPGs aus unterschiedlichen Aufnahme-Situationen. So führte eine Sortierung unter Dolphin nach dem Dateinamen zu einer Reihenfolge wie

img_010.jpg
IMG_010.jpg
IMG_011.jpg
img_012.jpg

wobei die “IMG_xxx” -Dateien eben zu einer anderen Aufnahme-Session gehörten als die “img_xxx”-Dateien.

Nun hatte meine bessere Hälfte natürlich selbst schon ein wenig eigene Recherche betrieben und auch alle ihr zugänglichen Einstellungsoptionen unter KDE durchgekämmt. Am Schluss beklagte sie sich dann vehement darüber, dass Dolphin, Konqueror und Gwenview unter KDE 4 zwar die Option zum Sortieren der angezeigten Dateien nach dem Dateinamen anböten, dass dabei aber eben die Groß/Klein-Schreibung vollständig ignoriert würde. Im Gegensatz zur Suche gäbe es auch keine Option, über die man die Beachtung der Groß/Kleinschreibung hätte aktivieren können. Noch schlimmer: Unter Dolphin reagierten auch Filterkriterien, die man in die zuschaltbare Filterleiste eingeben kann, nicht auf Unterschiede in der Groß/Klein-Schreibung.

Der normale User könne zudem auch unter den Systemeinstellungen keine Option finden, die einer Beachtung der Groß/Kleinschreibung bei Sortiervorgängen unter KDE geichkäme. Und nun wäre sie mit ihrem Latein am Ende und ich sei an der Reihe, was zu tun und zwar schnell – wegen der Gäste. Mein Vorschlag, die Bilder halt “händisch” umzusortieren, wurde mit ungläubigen Blicken und einem Hinweis auf die Anzahl der Bilder abgelehnt – und dann die obligatorische Frage nach dem Leistungsvermögen von Linux und dessen Administratoren, die ein zu diesem System überredet hätten ……

Intermezzo: Problembehebung über die Shell

Um das akute Problem zu beheben griff ich erstmal zu Hausmitteln: Terminalfenster, “cd” in das betroffene Verzeichnis, “mkdir gross” und “mkdir klein” abgesetzt und dann

find . -maxdepth 1 -name “img*” -exec cp -pv {} ./klein \;

sowie

find . -maxdepth 1 -name “IMG*” -exec cp -pv {} ./gross \;

und die Vorführung der Bilder war gerettet.

Akt 2: Ursachenforschung

Aber was war eigentlich mit Sortierung unter KDE los? War das Ganze überhaupt ein KDE-Problem?

Ich musste und muss zu meiner Schande gestehen, dass mir das von meiner Frau präsentierte Verhalten unter KDE
noch nie bewusst aufgefallen war. Ich konnte das erst auch nicht so recht glauben. (Im Kopf hatte ich natürlich die klassische ASCII-Reihenfolge und typische Wildcardgeschichten wie “[a-z]”, etc.)

Ich wurde jedoch eines Besseren belehrt, als ich folgenden Test mit “ls” und “sort” in einem Verzeichnis mit 4 Dateien “test_1.txt, test_2.txt, TEST_1.txt, TEST_2.txt” unternahm:

… > ls
test_1.txt TEST_1.txt test_2.txt TEST_2.txt

Das gleiche Ergebnis erschien auch mit

…> ls | sort
test_1.txt TEST_1.txt test_2.txt TEST_2.txt

– und das Durchprobieren diverser Optionen von “sort” änderte rein gar nichts. Das konnte doch nicht wahr sein ! Zur Sicherheit habe ich dann das Gleiche mal mit dem Root-Account ausprobiert – und siehe da, die Reihenfolge war nun wie erwartet:

… # ls
.directory TEST_1.odt TEST_2.odt test_1.odt test_2.odt

Nun wirklich misstrauisch geworden, sehe ich mir die “profile”-Einstellungen der Bash genauer an. Unter SUSE werden dabei Festlegungen unter “/etc/sysconfig” gezogen – interessant ist hier die Datei

/etc/sysconfig/language

mit dem Eintrag

RC_LANG=”de_DE.UTF-8″

Das Kommando “env | grep LANG” brachte denn unter einem normalen Useraccount auch konsistenterweise

LANG=de_DE.UTF-8

als Ergebnis. Hm, das wirkt ja eigentlich nicht so ungewöhnlich. Dann fällt einem ein, dass die LANG-Variable alle anderen “LC_….”-Variablen ersetzt also auch “LC_COLLATE”. Also Quercheck bei root:

… # env | grep LANG
LANG=POSIX

Aha – offenbar war das “Problem” an die Locale-Einstellungen gebunden. Ein Test mit “export LC_ALL=C” (C entspricht hier den Posix-Default-Einstellungen) bestätigte die Vermutung: Ab jetzt erschien auch unter dem normalen User-Acccount die gewünschte Reihenfolge.

…> export LC_ALL=C
…> echo $LC_ALL
C
…> ls | sort
TEST_1.odt TEST_2.odt test_1.odt test_2.odt

Was also war die Konsequenz? Die Sortier-Reihenfolge der “de_DE.UTF-8”- Collation entspricht nicht der gewohnten POSIX- bzw. ASCII-Reihenfolge, die man in jedem Linux-Anfängerkurs eingebläut bekommt.

de_DE.UTF-8 entspricht der Sortierung
“aAbB …. zZ”.

POSIX entspricht dagegen der Sortierung
“AB …Zab … z”

Akt 3: Nachdenken über potentielle Gefahren ?

Nun kam ich richtig ins Grübeln – was würde z.B. beim Löschen von Dateien und gleichzeitiger Verwendung der Wildcardsequenz [a-z] unter der Collation “de_DE.UTF-8” geschehen?

…> echo $LANG
de_DE.UTF-8
…> rm [a-z]*
…> ls

Tatsächlich ! Alle (!) Dateien – auch die mit großem Anfangsbuchstaben – waren gelöscht worden ! Oh, oh, … Das muss man sich wirklich merken !

Akt 4: Nachlesen unter den GNU-Definition zur Bash und LC_COLLATE

Unter folgender Quelle
http://www.gnu.org/software/bash/manual/bashref.html

liest man dementsprechend Folgendes:

“LC_COLLATE
This variable determines the collation order used when sorting the results of filename expansion, and determines the behavior of range expressions, equivalence classes, and collating sequences within filename expansion and pattern matching (see Filename Expansion). ”

Und bei “filename expansion” findet man:

“The sorting order of characters in range expressions is determined by the current locale and the value of the LC_COLLATE shell variable, if set.

For example, in the default C locale, ‘[a-dx-z]’ is equivalent to ‘[abcdxyz]’. Many locales sort characters in dictionary order, and in these locales ‘[a-dx-z]’ is typically not equivalent to ‘[abcdxyz]’; it might be equivalent to ‘[aBbCcDdxXyYz]’, for example. To obtain the traditional interpretation of ranges in bracket expressions, you can force the use of the C locale by setting the LC_COLLATE or LC_ALL environment variable to the value ‘C’. ”

Fazit und Nachspiel

Auf neueren Linux-Systemen (wie etwa SUSE 11.2) mit deutscher Lokalisierung wird für normale User meist eine “de_DE.UTF8”-Collation verwendet. Deshalb entspricht die Sortierung und die Abhandlung von Shell-Wildcards wie [a-z] nicht mehr den erwarteten Posix-Verhältnissen ! Das schlägt natürlich auch auf die KDE-Programme durch. (Das Gleiche gilt übrigens auch für Kollationen anderer Sprachbereiche).

Das sollte und muss man natürlich im Kopf behalten!

Die eigentliche potentielle Gefahr liegt aber im Einsatz von Wildcards der Form “[a-z]” bei Dateioperationen, da dadurch keineswegs – wie eigentlich erwartet – immer nur Kleinbuchstaben erfasst werden. Tja, eigentlich weiss man das ja …. theoretisch …. aber denkt man im Alltag wirklich immer drüber nach?

Wenn nicht, lohnt es sich jedenfalls, alte Shellscripts auf eventuelle Probleme, die durch den Einsatz von collation-abhängigen Wildcards verursacht werden könnten, durchzusehen.

KDE 4.4, Kontact, Kmail und das Adressbuch

Posted on by

In einem Beitrag am 25.12.2009 hatte ich nach einer ersten Entäuschung geschrieben, dass man den Weg zu KDE 4.4 noch nicht im produktiven Umfeld beschreiten sollte. Inzwischen habe ich diese Zurückhaltung aufgegeben – ich setze KDE 4.4 nun produktiv ein und fühle mich in dieser Desktop-Umgebung in der täglichen Arbeit gut unterstützt.

Entsprechend habe vor kurzem einem Kollegen empfohlen, doch mal KDE 4.4 auszuprobieren. Er fand das auch gut, kam aber nicht mir der Einrichtung von Kontact/Kmail klar. Sein Kontact Adressbuch funktionierte zwar irgendwie, aber er konnte die Adressen nicht unter Kmail nutzen. Das verstehe ich gut, weil ich selber große Schwierigkeiten hatte, die aktuelle Philosophie für Kontacts Adressbuch nachzuvollziehen.

Daher auch an andere Interessierte oder Betroffene zwei Hinweise:

1) Das “Default Adress Book” unter “Kontakte” ist nicht das “Default Adressbook” unter “Kmail” !

Ich habe das aktuelle Vorgehen der KDE-Entwicklung aus einem Forum-Dialog wie folgt verstanden: Offenbar gibt es den Plan, in der Zukunft diverse Ressourcen des KDE-Desktops über einen lokalen Akonadi-Server bereitzustellen. Um sich systematisch an das Thema heranzutasten, wurde Kontacts Adressbuch als erste Applikation auf Akonadi umgestellt. Das, was man als Unbedarfter dann erwartet, ist natürlich, dass das “neue” Akonadi-basierte Adressbuch auch unter Kmail genutzt werden kann.

Nun, da irrt man. Das Akonadi-basierte “Default Adressbook” im Adressbereich von Kontact ist im Moment (!) keineswegs ein Adressbuch, welches von anderen Kontact-Applikationen genutzt werden würde oder könnte – auch wenn unter Kmail in diversen Dialogfenstern ein “Default Adress Book” aufgeführt wird.

Wenn ich das richtig sehe, so ist das Akonadi-basierte Adressbuch zur Zeit das Ergebnis eines ersten Test- und Übungsbeispiels für die KDE-Entwickler – das verwirrende Resultat für den normalen Anwender ist bislang eine “stand alone”-Lösung, die im Kontakte-Bereich von Kontact als (sinnentleerte?) Zugabe herumgeistert. Dieses Adressbuch wird im PIM nicht von anderen Applikationen benutzt !

So ist es auch kein Wunder, dass mein Freund und ich verzweifelt, aber vergeblich Testeinträge im Adressbuch anlegten, um dann herauszufinden, dass diese unter Kmail (z.B. im Rahmen der automatischen Adress-Vervollständigung) nicht angezeigt werden – obwohl sie natürlich in voller Schönheit im Adressbuch-Bereich such-, sicht- und editierbar sind. Da half und hilft kein Rumprobieren an den Einstellungen des Kmail-Editors oder das Verändern der Adressbuch-Reihenfolge – das unter diversen Kmail erwähnte “Default Adress Book” hat halt leider rein gar nix mehr mit dem im Adressbuch-Bereich angelegte “Default Adress Book” zu tun.

Liebe KDE-Truppe, der/die dafür Verantwortliche sollte wissen, dass sich das einem Anwender wahrlich nicht erschließt. Mit einer solchen Idee rechnet man schlicht nicht – ich selbst konnte es nach Jahren KDE-Verwendung auch überhaupt nicht glauben und habe das Ganze erst nach mehrmaligem Lesen eines Dialogs zwischen einem frustrierten Anwender mit einem KDE-Entwickler begriffen. Wenn man die User beim Umstieg auf KDE 4.4 verwirren wollte – dann wurde dieses Ziel in preisverdächtiger Weise erreicht.

Als fehlersuchender KDE-Anwender experimentiert ja man nicht nur mit Kontact-Einstellungen herum – nein, man wirft natürlich auch einen Blick auf den Akonadi-Server und die dort erscheinenden Ressourcen. Dieser Ausflug in eine bislang unerforschte Welt war natürlich hochinteressant – aber er nutzt einem bzgl. des Kmail-Problems nichts. Unter Akonadi erschien bei mir alles fehlerfrei – sprich der Akonadi-Server lief anstandslos und die Adressbuch-Ressource wurde auch angezeigt. Nur unter Kmail ließen sich die Adressen halt nicht verwenden.

Übrigens: Falls man bei der Einrichtung von Akonadi Probleme
haben sollte, hilft vielleicht Folgendes:

a) Virtuoso installieren

b) Bzgl. der Desktop-Suchmaschine Nepomuk folgenden Eintrag in der Datei “~/.kde4/share/config/nepomukserverrc” prüfen:

[main Settings]
Maximum memory=50
Storage Dir[$e]=$HOME/.kde4/share/apps/nepomuk/repository/main/
Used Soprano Backend=virtuosobackend

c) Ggf. “~/.config/akonadi/akonadiserverrc” löschen und den Akonadiserver über die Akonadi-Einrichtung neu starten

2) Lösung: Ignoriere im Moment das Akonadi-basierte Adressbuch und richte ein konventionelles Adressbuch unter Kontakt und ggf. auch unter KDE ein!

Hat man die obige “Philosophie” erst einmal verdaut, ist natürlich der Weg zur Lösung nicht weit. Man muss in Kontacts Adressbuch-Bereich (und ggf. unter den KDE-Ressourcen; s.u. den Hinweis vom 25.06.2010) einfach ein weiteres “Standard”-Adressbuch einrichten.

Zum Einrichtungs-Dialog für ein neues Adressbuch kommt man durch einen Klick mit der rechten Maustaste in den Seitenbereich “Adressbücher” unter “Kontakte”. Im erscheinenden Kontextmenü wählt man dann “Adressbuch hinzufügen”. In der nachfolgenden Auswahl schließlich “KDE-Adressbuch (herkömmlich)”. Es erscheint erneut ein Auswahldialog – hier muss man die für sich richtige Ressource anklicken. In meinem Fall ist das ein Adressbuch eines Open-Xchange-Servers, für das man dann die Verbindungsdaten wie in früheren Kontact-Versionen auch einträgt:

Adresse: http://my-OX-Server
User: my_user_name
Passwort: my_password

Danach Auswahl des OX-Adressbuch-Verzeichnisses – z.B. des globalen Adressbuches unter den OX-Systemordnern. Dieses so angelegte Adressbuch erscheint dann übrigens auch als Akonadi-Ressource – was einem unter Kmail aber leider nichts nutzt. ..

*******Wichtige Ergänzung vom 25.06.2010: *******
In der bei mir aktuellen Version (Kontact 4.4.5 und KMail 1.13.5) aus dem Factory-Repository von SUSE reicht der eben beschriebene Schritt unter “Kontakte” leider nicht (mehr?) aus, um die Ressource auch im KMail-Bereich verfügbar zu machen (z.B. für die automatische Adressvervollständigung). Vielmehr muss man die Adressbuch-Ressource nochmals manuell anlegen – und zwar in den KDE- “Systemeinstellungen” als allgemeine KDE-Ressource:

Entweder im KDE-Menü “Systemeinstellungen” starten oder in einem Terminalfenster “system-settings &” eingeben. Dort den Reiter “Erweitert” betätigen und dann den Eintrag “KDE-Ressourcen” wählen. Mit Hilfe der Auswahl-Combobox die Kategorie “Kontakte” einstellen. Prüfen, ob die gewünschte Adressbuch-Ressource schon als Eintrag vorhanden ist. Wenn – wie bei mir – nicht: “Hinzufügen” anklicken und in den folgenden Dialogen zum Hinzufügen einer Ressource die gleichen Schritte vornehmen, die oben für den “Kontakte”-Bereich von “Kontact” beschrieben wurden.

Im aktuellen Zustand von Kontact führt das Anlegen einer (herkömmlichen) Adressbuch-Ressource unter “Kontakte” offenbar nicht mehr zu den notwendigen KDE-Einträgen für die Ressourcen, die dann von KMail aufgegriffen werden. Was denkt der normale Anwender: Schade eigentlich … und regt sich am besten nicht auf ….
****** Ende Ergänzung 25.06.2010 *******

Hinweis: Für ein lokales Adressbuch sollte die zugehörige Datei übrigens auf

/home/user_xyz/.kde4/share/apps/kabc/std.vcf

verweisen, wenn das vcf-Format gewählt wurde.

Die so angelegten (herkömmlichen) Adressbücher werden schließlich auch unter Kmail erkannt und an den gewohnten Stellen aufgelistet. Der Adressbuch-Inhalt wird auch wie gewohnt in der automatischen Adress-Suche und -Vervollständigung beim Verfassen von Mails herangezogen. Die Reihenfolge, in der die “herkömmlichen” Adressbücher dabei verwendet werden sollen, legt man mit den üblichen Dialogen, z.B.
“Einstellungen – Kmail einrichten – E-Mail-Editor –
Vervollständigungsreihenfolge einstellen ….”,
fest. Alles wie gehabt. Ich kann seitdem wieder normal arbeiten.

Links

Einen Sinn hatte das ganze Theater aber doch: Man fängt an, sich für Akonadi zu interessieren. Als Einstieg hier ein paar Links:

http://de.wikipedia.org/wiki/Akonadi
http://pim.kde.org/akonadi/
http://userbase.kde.org/Akonadi

Schön ist übrigens die Einleitung zur UserBase (mit Hinweisen zur Fehlerbehebung):

“This page is mainly concerned with troubleshooting Akonadi, as there are inevitable glitches in early stages of migration. For many people the first signs of Akonadi activity will be in KDE SC 4.4, and many will be confused by it. ”

Oh, yes !