Author Archives: Ralph Mönchmeyer

Flackern beim Seitenwechsel im MS IE – Nachtrag

Posted on by

In einem der letzten Blog-Beiträge ging es um das Flackern des MS IE beim Seitenwechsel. Dort hatte ich zwei Tricks aufgeführt, mit denen man ohne Serveränderungen in manchen Fällen – leider nicht immer – eine Verbesserung herbeiführen kann.

In diesem Beitrag möchte ich kurz auf die Behandlung von MS IE-Flackern bei der Integration von Hintergrundsbildern für die gesamte Webseite eingehen. Da gibt es eine Geschichte, die es sehr verständlich macht, warum viele Webseiten-Entwickler den MS IE verfluchen.

Also – wie lädt man typischerweise Hintergrundsbilder für die gesamte HTML-Seite? Im -Tag per css-Anweisung. Typischerweise haben dann viele Seiten einer Domain dasselbe Hintergrundsbild und einen im wesentlichen gleichen Aufbau – es ändern sich beim Seitenwechsel nur ganz bestimmte BEreiche der Seite. Dann will man natürlich, dass ein Seitenwechsel sanft vor sich geht und der Hintergrund nicht flackert. Das Hintergrundsbild und alle anderen unveränderten Seitenelemente sollen beim Seitenwechsel statisch angezeigt, nicht neu aufgebaut oder neu geladen werden. Wozu gibt es schließlich den Browser-Cache …

Leider wird man aber beim MS IE in Abhängigkeit von der MS IE-Version feststellen, dass es dort bei Seitenwechseln, bei denen sich das Hintergrundsbild und wesentliche Anteile der Webseite (Grundaufbau) nicht ändern, dennoch zu Flackern kommt. Der Hintergrund wird kurz weiß, das Bild wird neu geladen. Das passiert ggf. nicht immer aber, doch sehr häufig. Wenn man genauer forscht, wird man feststellen, dass das Flackern besonders häufig oder immer bei Seiten auftaucht, bei denen zusätzlich zu den Hintergrundsbildern Flash-Elementen oder Javascript-Anteile vorkommen.

Deshalb sind ggf. zwei Tricks zu kombinieren, um das Flackern weg zu bekommen:

Fall 1) Es wird kein Javascript in der Webseite benutzt

Dann hilft es, das Hintergrundsbild nochmals (also zusätzlich zum Hintergrund im <BODY>) in einem DIV zu laden, das man per z-Index unter den gesamten übrigen Inhalt der Webseite legt. Hierzu benötigt man natürlich einen übergeordneten DIV-Container, in dem man das DIV für das Hintergrundsbild und ein DIV für den gesamten übrigen Inhalt absolut positioniert und übereinander legt.

Fall 2) Es wird Javascript benutzt, z.B. um Flash-Objekte in die Seite zu integrieren

Wir verwenden z.B. SWFObject und entsprechendes Javascript, um Flash zu integrieren. Es hat mich viele Tests gekostet, bis ich herausfand, dass allein schon das Einfügen eines Tags

<script type=”text/javascript”></script>

(also ohne jeden Code !) oder gar eines Tags

<script language=”JavaScript” src=”script/swfobject2.js” type=”text/JavaScript”></script>

im Header der HTML-Datei bereits ein Flackern beim Seitenwechsel zwischen Seiten mit Hintergrundsbildern auslöst. Für den Bruchteil einer Sekunde wird der Hintergrund weiß, das Bild wird neu geladen. Selbst wenn in der HTML-Seite keinerlei Javascript-Code ausgeführt wird. Unglaublich nicht ? Noch unglaublicher ist aber der Trick, der beim MS IE hilft:

Man kopiere den gesamten Script-Kram, soweit es die Logik der Seite zulässt, an das Ende des HTML-Codes und zwar unmittelbar vor das Ende des abschließenden </BODY>-Tags. Das ist zwar ungewöhnlich, aber kein Browser meckert einen formalen Fehler an. Und siehe da, auf einmal hört auch im MS IE das Flackern auf.

Das läßt tief blicken, in welcher Weise die Javascript-Engine in den MS IE integriert ist – Entschuldigung bei MS ist das ja eh eine Extrawurscht und nix Normales (JSCRIPT).

Leider kann es in einigen Fällen so sein, dass Javascript-Code zwingend vor dem Laden der übrigen HTML-Elemente ausgeführt werden muss. Dafür habe ich auch keine echte Lösung parat. Aber in vielen Fällen hilft der beschriebene Trick.

Überflüssig anzumerken, dass man den ganzen Quatsch so nicht braucht , wenn
man Firefox benutzt. Gott sei Dank hat ja nun Firefox zumindest in Deutschland dem MS IE den Rang abgelaufen.

Opensuse 11.2, Audio, Encoding, K3b

Posted on by

Nachdem mich

  • Schwierigkeiten mit der generellen Audio-Einrichtung unter Opensuse 11.2 (x86_64) mit einem Mix aus KDE3 und KDE4-Programmen
  • und zusätzliche Schwierigkeiten mit der “Ogg Vorbis”- und “MP3”-Kodierung unter K3b

auf einem Opensuse 11.2-System eines Bekannten kurzzeitig an den Rand einer Krise getrieben haben, hier ein paar Hinweise, die u.U. auch anderen helfen können:

1) Reagieren die diversen Audio-Programme überhaupt auf das richtige Laufwerk ?

Der Betreffende hatte 2 Laufwerke – einen DVD-Writer und ein normales DVD-Laufwerk. Blöderweise war der Writer unter “/dev/sr0” und das normale DVD-Laufwerk, das er regelmäßig zum CD- und DVD-Abspielen verwendet, unter “/dev/sr1” ansprechbar. Natürlich legt Opensuse bei der Installation “/dev/cdrom” und “/dev/dvd” aber auf “sr0” !

Und da – also bei /dev/sr0 – suchen dann fast alle KDE-Programme die Audio-CD – idiotischerweise auch dann, wenn man z.B. KSCD nach dem Einlegen einer CD in “/dev/sr1” über das Kontextmenü des Gerätemanagers startet. Na ja, es gibt ja intelligentere Programme, die da mehr checken – aber wenn man KDE verwenden will, dann muss man halt vorsorgen.

In Fall des Bekannten half im Rahmen der Tests zunächst ein Softlink

ln -s -f /dev/sr1 /dev/cdrom

Dann stellt man aber (erwartungsgemäß) fest, dass diese Linkzuordnung den nächsten Reboot nicht überlebt. Statt dessen ziehen Udev-Regeln bzgl. der Block-Devices. Um also die Zuordnungen permanent zu machen, muss man Dateien in “/etc/udev/rules.d” editieren. Im vorliegenden Fall ist die Datei

“70-persistent-cd.rules”

die richtige. Die Einträge für das fragliche System sehen z.B. wie folgt aus:

# CDDVDW_SH-S223F (pci-0000:00:1f.2-scsi-0:0:0:0)
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:1f.2-scsi-0:0:0:0″, SYMLINK+=”cdrom1″, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:1f.2-scsi-0:0:0:0″, SYMLINK+=”cdrw”, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:1f.2-scsi-0:0:0:0″, SYMLINK+=”dvd1″, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:1f.2-scsi-0:0:0:0″, SYMLINK+=”dvdrw”, ENV{GENERATED}=”1″

# DVD-ROM_SH-D163B (pci-0000:00:1f.2-scsi-1:0:0:0)
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:1f.2-scsi-1:0:0:0″, SYMLINK+=”cdrom”, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:1f.2-scsi-1:0:0:0″, SYMLINK+=”dvd”, ENV{GENERATED}=”1″

Ferner gibt es andere Programme (wie z.B. xine), die ihre eigenen (nicht über KDE zentralisierten) Einstellungen für das Audio- oder Video-Laufwerk etc. haben wollen. Ggf. dort direkt das richtige Laufwerk einstellen.

Auch in den KDE 4 “System Settings” gilt es, unter “Erweitert-> Audio CD” die richtigen Einstellungen zu treffen.

2) Umstellung auf Pakete aus dem Packman-Repository

Wenn man mit MP3 arbeiten will, müssen Lame und zugehörige Bibliotheken installiert sein. Ferner lohnt es sich, viele der Audio-Programme vom Packman-Repository zu installieren. Mehr sage ich nicht – wegen der Rechte muss jeder selber wissen, was er tut und wie er zu einer entsprechenden Lizenz kommt.

Ich selbst nehme eh’ immer “Ogg Vorbis” und fahre sehr gut damit. Aber wenn es denn halt MP3 sein soll, dann ist die Installation der Packman-Programme angesagt !

Wenn man gleich alles Wesentliche auf einen Streich umstellen will,
dann zeige man sich in Yast das Repository an – und zwar über den Reiter “Anzeigen” und dort unter “Installationsquellen”. Nach einem Klick auf das Packman Repository Icon in der Liste findet man im oberen rechten Yast-Bereich eine gelb markierte Option “Switch system packages to the version in this repository”. Ein Klick auf diese Option vereinfacht die Paket-Umstellung erheblich und markiert alle relevanten Programme für ein Update aus dem Packman Repository. In gewisser Weise stellt dieses Vorgehen dann auch eine Konsistenz der Packman Pakete untereinander her!

Essentiell sind in jedem Fall die libxine1-Bibliotheken, im Besonderen die “libxine1-codecs”.

3) Ist der User den richtigen Gruppen zugeordnet?

Als nächstes sollte man untersuchen, ob der betreffende User den richtigen Gruppen zugeordnet ist. Unter Opensuse 11.2 fehlt ggf. die Zuordnung zu den Gruppen “audio” und “cdrom”. Dies war im vorliegenden Fall eine Mindestvoraussetzung, um ältere KDE3-Programme wie KSCD unter Opensuse 11.2 zum Arbeiten – sprich zum Abspielen von Audio-CDs zu bewegen.

Natürlich müssen in solchen Programmen – soweit einstellbar – auch die Optionen für “Digitale Extraction” und das richtige Soundsystem gesetzt sein.

Gerüchten zufolge soll bei einem Einsatz anderer älterer KDE3-Programme auch die Zuordnung zur Gruppe “disk” helfen. (Ich glaube das aber nicht – außerdem wären mir bei Letzterem auf einem Mehrbenutzersystem die Risiken zu groß).

Das ganze Thema mit fehlenden Rechten gab es beim ersten Release von Opensuse 11.1 schon mal. Nach meiner Erfahrung lohnt es sich jedenfalls, bei Problemen im Audio-Bereich mal versuchsweise die Rechte umzusetzen und danach systematisch das Minimum der notwendigen Rechten zu identifizieren. Wer weiss, was alles in Opensuse 11.2 so passiert – ich habe bei Paket-Updates aus dem Opensuse Update-Repository jedenfalls schon ein paar Mal die Meldung gesehen, dass Verzeichnis-Rechte umgesetzt wurden.

Achtung: Nach dem Umsetzen userspezifischer Rechte für Systemgruppen zur Sicherheit neu booten.

Zwischenergebnis

So, hat man an diesen drei Fronten alles in Ordnung, dann laufen normalerweise die üblichen Audio-Progrämmchen KSCD (KDE3 und KDE 4), amarok 1.4 (Packman), amarok (2.x für KDE 4 – ab KDE 4.4 auch mit Equalizer !), xmms, asunder, sound juicer, MPlayer, Kaffeine (KDE 3), KAudioCreator (KDE 3), Audex, etc. und werkeln so vor sich hin – sowohl beim Abspielen der Audio CDs als auch bei der Extraktion mit anschließender Enkodierung in “Ogg Vorbis”, MP3 und anderen Formaten.

4) Enkodierung mit Kb3

K3b stellt eine sehr einheitliche und praktische Oberfläche nicht für das Brennen von CDs sondern auch zum Auslesen derselben und der Umwandlung der Tonspuren in digitale Audioformate zur Verfügung. Unter diesem dach kann man zudem auf einfache Weise die wichtigsten Einstellungen der Enkoder in sehr übersichtlicher Weise vornehmen.

Ein erster Test mit K3b aus dem Packman Repository zeigt denn auch, dass ein Auslesen und ein Enkodieren unter Ogg Vorbis anstandslos funktionieren. Ganz anders sieht es aus, wenn man eine MP3-Enkodierung vornhmen will. Hier erschien auf dem System meines Bekannten eine Meldung der Art

“command failed: lame -h –tt %t –ta %a –tl %m –ty –tc – %f”

Bei anderen Einstellungen des Enkoders und der sonstigen Ausleseparameter (z.B. Ziel-Verzeichnisse) können die lame-Optionen auch anders aussehen. Also das Problem trieb mich bald zum Wahnsinn, nachdem händische Kodierungsversuche per Kommandozeile, aber auch KAudioCreator, Audex
und Asunder problemlos arbeiteten. Allein konnte ich das Problem auch nicht lösen; die Lösung fand ich dann in einem Forum unter der Adresse

http://www.linuxquestions.org/questions/slackware-14/having-some-trouble-w-k3b-and-encoding-with-lame-640386/

Ich gebe einfach die Hinweise des Forumteilnehmers “lennoni” wieder, die unter K3b für Opensuse 11.2 (x86_64) auch zum Erfolg führten. Allerdings muss man gegenüber dem Vorschlag des Forums eine Modifikation vornehmen :

a) Start k3b and insert audio CD (allow cddb lookup)
b) click “Start Ripping”
c) select MP3 (lame) as filetype
d) Click the config cog beside this
e) highlight the Mp3 (lame) and click edit
f) check your command line (mine is lame -h -V2 –tt %t –tn %n –ta %a –tl %m –ty %y –tc %c – %f )

[ Original suggestion of lennoni: g)check both “swap byte order” and “write wave header”, then OK, OK]

g) Suggestion of RM [03.01.2010]: check “write wave header”, only, then OK, OK !
(Hint: MP3-files with “swapped byte order” will not be playable in most MP3 players ! My K3b worked, i.e. extracted and encoded without a checked “swap byte order”. )

h) Save settings!! (RM-Hinweis: Über ein kleines Icon links unten in K3b !)
i) Start ripping

Yeah, great lennoni ! Thx, thx !

Dann geht’s auch mit MP3. Auch, wenn man das als normaler Linux-Sterblicher gar nicht braucht ! Blöd allerdings, wenn der mobile Player für die Hosentasche oder das neue Handy mit Gigabytes an Audiospeicher kein “Ogg Vorbis” versteht. Aber sowas kauft ein Linuxer ja gar nicht …..

Nachtrag 04.01.2010

Musste mir heute nochmal genauer angesehen, wie Amarok die MP3-Dateien verarbeitet, die mit den obigen Einstellungen von K3b (“write wave header”) erzeugt wurden. Dabei musste ich leider feststellen, dass die Tracknr. nicht richtig erkannt wurde. Das kann man zwar über die Metadaten der erfassten Dateien manuell korrigieren. Grundsätzlich ist die Reaktion von Amarok aber ein Hinweis darauf, dass K3b offenbar Probleme damit hat die CDDB-Daten bzw. CD-Daten korrekt zu verarbeiten und weiterzureichen. Möglicherweise hängt damit auch der Fehler zusammen, der nach dem Lame-Aufruf durch K3b auftritt. Das ist jedenfalls eine Fehlermeldung an die K3b-Entwickler wert.

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.