KDE 4.3.8x – Vorsicht !

Seit KDE 4.1. habe ich mich auf meiner Linux-Kiste regelmäßig über das Opensuse Factory Repository auf dem Laufenden gehalten. Das hatte sich bis zur Version 4.3.4 eigentlich auch bewährt.

Aber im Moment rate ich jedem, der 4.3.80-er-Versionen ausprobieren will, dazu, dies nur auf einer separaten “Spiel2-Partition” zu tun und nicht in einem Umfeld, in dem produktive Arbeit gefragt ist. Der Grund ist einfach die doch noch sehr experimentell wirkende Arbeit, mit der die Entwickler jetzt (krampfhaft ?) Akonadi in KDE einbauen wollen.

Eigentlich dachte ich aufgrund früherere Ankündigungen, dass das aus guten Gründen auf die Version 4.5 verschoben sei. Nun läßt man dem Anwender plötzlich keine Wahl mehr – Kontact 4.3.8X setzt zwingend die Installation und Lauffähigkeit von Akonadi voraus.

Persönlich finde ich als KDE-Anwender ja, dass es noch genug andere Probleme mit KDE 4 (vor allem mit Konqueror) gibt, die man beheben sollte, bevor man erneut eine Großbaustelle im PIM-Bereich eröffnet. Meine ersten Erfahrungen jedenfalls waren leider abschreckend:

Kmail wird extrem langsam, die Behandlung der Adressbücher ist gewöhnungsbedürftig, die automatische Anzeige von E-Mail-Adressen funktoniert nicht, etc..

Fazit:

Das dauert wohl noch ein Weilchen bis Kontact und seine Komponenten wirklich gut mit Akonadi zusammenarbeiten. Bis dahin gilt es, sich für produktive Desktops unter KDE 4 und Opensuse auf den Stable-Zweig der Repositories zurückzuziehen.

Nachtrag im Januar 2010:

Ich setze KDE 4.4 inzwischen erfolgreich und im Arbeits-Alltag ein. Inzwischen habe ich auch begriffen, wie man mit Akonadi und den Adressbüchern unter Kontact umgehen muss. Sehen Sie dazu aber andere kommende Beiträge in diesem Blog. Inzwischen bin ich mit KDE 4 trotz einiger Kinderkrankheiten auch ganz zufrieden ….

WordPress verunstaltet HTML-Code

Die vor einigen Monaten erfolgte Implementierung von TinyMCE in WordPress mag mancher ja als nett empfinden – aber dieser “Fortschritt” hat ungewünschte Nebenwirkungen für die Autoren:

Ich bin nicht der Erste, der feststellen muss, dass bei Benutzung des WYSIWYG-Editors der eigene HTML-Code, den man ggf. im HTML-Fenster des Editors einfügt, nicht mehr akzeptiert wird. Eigentlich würde man gern zwischen dem visuellen Editor und dem HTML-Code hin und her wechseln und bei Bedarf den generierten HTML-Code durch eigene Tags und CSS-Vorgaben modifizieren.

Aber nein – das ist seit der WordPress spezifischen Implementierung von TinyMCE nicht mehr möglich – der HTML-Code des Autors wird automatisch verändert und zwar massiv.

DIVs werden z.B. in P-Tags umgewandelt – natürlich bei erheblichen Verlusten im Layout. Generell wird alles auf das Niveau von P-Tag-Formatierung heruntergebrochen. Und das Schlimmste ist, dass der Code von alten, mühsam erstellten Artikel ebenfalls verändert wird, sobald man sie ein einziges Mal zum Bearbeiten öffnet.

Liebe WordPress-Entwickler, ich finde das total unakzeptabel ! Das ist eine grundsätzlich falsche Entwicklung:

Wenn ich in einem Editor eigenen Code einarbeite, muss der unangetastet bleiben. Modifikationen sind höchstens nach Bestätigung eines entsprechenden Vorschlags in einem Dialog akzeptabel, aber nicht als Automatik. Gegen Warnungen bei HTML-Fehlern, bei nicht geschlossenen Tags etc. hat auch keiner was einzuwenden – aber bitte kein automatisches Überschreiben von Code ohne ausdrückliche Erlaubnis des Autors.

Ich lehne diese Bevormundung ohne Vorwarnung total ab ! (Das Gleiche gilt übrigens für den HTML-Editor von Kmail – dort findet dieselbe Art der Code-Manipulation statt – auch dann, wenn man über einen externen Editor geht).

Für WordPress gibt es eine einfache Lösung:

Abschaltung des WYSIWYG-Editors im eigenen Profil, bis sich die WordPress-Entwickler was Vernünfigeres ausgedacht haben!

Nach der Abschaltung hat man zwar TinyMCE nicht mehr zur Verfügung – das ist im Vergleich zum Gewinn der HTML-Freiheit aber nur ein kleines Übel. Sorry, ich finde Tiny MCE toll – aber so sollte man es nicht zum Einsatz bringen.