Monthly Archives: December 2009

KDE 4.3.8x – Vorsicht !

Posted on by

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

Posted on by

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.

Reihenfolge relativ und absolut positionierter DIVs

Posted on by

Anne kam vor kurzem mit einem typischen Problem im Zusammenhang mit der Positionierung von relativ und absolut positionierten DIVs in einem Container-DIV.

Fast wie immer klappte alles im Firefox oder in Opera unter Linux (und Windows) – nur nicht im MS IE (7,8).

Worum ging es?

Das Container-DIV hatte nur die Aufgabe,  einen definierten Bereich innerhalb der Webseite vorzugeben und bei Bedarf Scrollbedarf zuzuschalten. Das DIV war in seiner Umgebung relativ positioniert.

Innerhalb des Containers hatte Anne eine Reihe aufeinanderfolgender, relativ positionierter  DIVs undefinierter Höhe.  Die Elemente der DIVs wurden durch Datenbankinhalte gefüllt. Insgesamt ergaben die relativ positionierten DIVs  einen Hintergrundsbereich innerhalb des Containers. Alle befanden sich in der gleichen Ebene, die durch eine z-Index festgelegt wurden.

Zusätzlich gab es ein weiteres DIV, das absolut positioniert wurde und für das ein höherer Wert im z-Index gewählt wurde. Dieses DIV sollte also immer vor den relativ positionierten DIVs angezeigt werden.

Also:

<div id=”container” …. >
 
<!– das absolut positionierte DIV –>
<div id=”abs” style=”position:absolute; …. z-index:10; “>
…..
</div>
 
<!– die relativ positionierten DIVs –>
<div id= “rel_1 ” style= “…; z_index:1; ” ….. > …. </div>
<div id= “rel_2 ” style= “…; z_index:1; ” ….. > ….  </div>
…..
…..
   
</div>

Im Firefox wurde das abslout positionierte DIV auch brav über allen anderen DIVs angezeigt; im MS IE7 dagegen nicht und im MS IE 8 nur, wenn der Seitenaufruf mit geänderten PHP-Parametern geschah. Ein reiner Seiten-Refresh führte immer zu einem Ausblenden des absolut positionierten DIVs.

Die Lösung 

Was hatte Anne falsch gemacht ? Aus meiner Sicht gar nichts. Außer, dass sie hätte davon ausgehen müssen, dass der MS IE ein wenig Hilfe benötigt:

Der MS IE kriegt die obige Reihenfolge nämlich nicht auf die Reihe – im wahrsten Sinne des Wortes !

Hätte Anne die Reihenfolge von vornherein wie folgt gewählt, wäre nichts passiert:

<div id=”container” …. >
 
<!– die relativ positionierten DIVs –>
<div id=”rel_1″ style=”…; z_index:1;” ….. > ….  </div>
<div id=”rel_2″ style=”…; z_index:1;” …..> ….  </div>
…..
…..
 
<!– das absolut positionierte DIV –>

<div id=”abs” style=”position:absolute; …. z-index:10; “>
…..
</div>
 
</div>
n
Merke:

Im MS IE ist es zwingen, die relativ positionierten DIVs vor den absolut definierten DIVs zu definieren. Sonst bekommt der MS IE den Ebenenaufbau nicht hin.

Arme Web-Designer ! Das ist kein Spass mit dem MS IE.