Infos

Sie befinden sich in den Archiven der Kategorie Web - Browser und Co..

Calendar
Mai 2012
M D M D F S S
« Apr    
 123456
78910111213
14151617181920
21222324252627
28293031  

Archiv der Kategorie Web - Browser und Co.

KDE 4.2, Firefox, Checkboxen und Radiobuttons

Ein paar Bekannte haben beim Einsatz von Firefox unter KDE 4.2 das gleiche Problem mit Web-Formularen, das auch ich nach dem Umstieg auf KDE 4 hatte:

Die Checkboxen und Radiobuttons funktionieren optisch im Firefox 3 nicht richtig - zumindest nicht auf einer Default-Opensuse-11.1-Installation, die um KDE 4.2 ergänzt wurde. Man kann Checkboxen z.B. zwar anklicken - danach sieht man aber keinen Haken. Dieser taucht erst wieder auf, wenn man im Formular an anderer Stelle mit der Maus klickt. Ziemlich irritierend, weil man nicht direkt sieht, ob eine Checkbox/Radiobutton nun aktiv ist oder nicht.

Das ist aber kein Firefox-Problem, wie man meinen könnte, sondern ein GTK-Thema. In etlichen Kubuntu-Blogs wird zum gleichen Thema empfohlen, einen vernünftigen GTK-Style über die KDE 4 “Systemeinstellung” zu wählen. Das reicht nach meiner Erfahrung unter Opensuse leider nicht - man benötigt nämlich noch ein paar notwendige Bibliotheken, die nicht in ihrer Gesamtheit installiert sind.

Essentiell bei SUSE sind grundsätzlich die Pakete gtk und gtk-qt-engine - letzteres für KDE. Das korrekte Anzeigen der Checkboxen hängt aber an zusätzlich benötigten GTK2 Bibliotheken. Man benötigt deshalb auch die Pakete “gtk2″, “gtk2-engines”, “gtkhtml2″, “libgtkhtml”, “qtcurve-gtk2″, “qtcurve-kde4” und ggf. für die Einstellung von GTK-Themen “gtk2-themes”, “kde4-kcm_gtk”.

Als GTK-Theme oder Stil habe ich über das KDE 4.2-Konfigurationszentrum
“Systemeinstellungen (system-settings)-> Erscheinungsbild->GTK-Stile und Schriftarten”
übrigens “QtCurve” gewählt. Das ist auch eine notwendige Bedingung für das Beseitigen der Probleme mit den Checkboxen!

Ferner habe ich “KDE-Schriftarten in GTK-Anwendungen verwenden” aktiviert. Das zwar für das Checkboxen-Thema unerheblich, trägt aber zu einem besseren Aussehen bei.

Danach sieht der Firefox ganz ordentlich aus und die Checkboxen in Formularen funktionieren anstandslos.

P.S.: Liste an GTK-relevanten Paketen
Der Vollständigkeit halber hier eine vollständigere Liste von gtk-relevanten Paketen, die bei mir (aus verschiedenen Gründen u.a. Entwickung) auf einer Workstation installiert sind:
glib, gtk, gtk-32bit, gtk2, gtk2-32bit, gtk2-branding-openSUSE, gtk2-devel, gtk2-engines, gtk2-engines-32bit, gtk2-lang, gtk2-theme-openSUSE, gtk2-themes, gtkglext, gtkglext-32bit, gtkhtml2, gtkhtml2-devel, gtkhtml2-lang, gtkmm2, gtkmm2-devel, gtk-qt-engine, gtk-gt-engine-32bit, gtk-sharp2, gtk-sharp2-32bit, gtk-sharp2-32bit, gtksourceview18, gtkspell, gtkstyle, gxine, kde4-kcm_gtk, libgtkhtml, libgtkhtml-32bit, libgtkimageview0, libsexy, libwebkit-1_0-1, perl-Gtk2, phat, python-gtk, python-qt, qtc, qtcurve-gtk2, qtcurve-gtk2-32bit, qtcurve-kde4

———————————————————

Eigene Ergänzung II vom 22.02.2009:
*********
Muss mich nochmal entschuldigen für die Verwirrung, die ich mir selber und evtl. anderen heute durch meine erste heutige Ergänzung (s.u.) bereitet habe. Nach ein wenig Nachdenken und weiteren Checks lässt sich das Checkbox-Problem von Firefox 3.0.6 unter KDE 4.2 (Factory-Repository von Opensuse 11.1) doch beheben:

1) Ich habe bei den letzten Updates einen Fehler begangen und das Paket “qtcurve-kde4″ leider aus dem Unstable-Zweig und nicht aus dem Factory-Zweig installiert. Das war eine der Ursachen dafür, dass die oben vorgeschlagene Problemlösung zwischenzeitlich nicht lief (s. meinen Einschub unten). Mit der aktuellen Version von KDE 4.2 aus dem SUSE Factory-Repository und der zugehörigen Version 0.60-2.2 von “qtcurve-kde4″ ist alles wieder OK.

2) Ich habe zu meiner Schande zudem vergessen, das Paket “qtcurve-kde4″ in den Listen der erforderlichen Pakete oben mit einzufügen. Ohne dieses Paket geht aber gar nichts. Diesen Fehler habe ich nun korrigiert und das Paket oben in fetter Schrift hervorgehoben.

Ich hoffe, dass ihr das Problem nun unter Berücksichtigung der übrigen Hinweise des originalen Beitrags in den Griff bekommt ! Sorry nochmal - ich hätte gleich sorgfältiger arbeiten müssen.

[
Inzwischen irrelevante Ergänzung I vom 22.02.2009:
*********
Sorry, liebe Leute:
Der obige Artikel zur Lösung des Checkbox-Problems in Firefox stimmt leider nicht mehr. Nach einer weiteren Update Runde mit Firefox (3.0.6) und KDE 4.2 aus dem Factory Repository von SuSE ist das Problem mit den Checkboxen und Radiobuttons von Firefox wieder da - auch wenn man die oben empfohlenen Bibliotheken installiert hat und QtCurve als GTK-Scheme eingestellt hat.
]

Kurztest: 64 Bit Version des Adobe Flash-Plugins

Wegen aktueller Probleme mit dem Flash-Plugin im Konqueror unter KDE 4.2 rc1, habe ich etwas neugierig im Internet gestöbert und dabei gemerkt, dass es inzwischen so etwas wie das 2-te Alpha-Release eines 64 Bit-Plugins für Linux von Adobe gibt. Man höre und staune - es gibt sogar ein verbales Commitment bzgl. Linux und Solaris auf den entsprechenden Info-Seiten von Adobe.

Das ich das noch erleben darf - jahrelang beschwert man sich, nix passiert und plötzlich ein 64 Bit Plugin! Da konnte ich einem Minitest nicht widerstehen. Getrieben wurde ich ja auch von der Hoffnung, dass vielleicht sogar Konqueror unter KDE 4.2 damit etwas anfangen könnte. Also habe ich mir die 64Bit-Library (libflashplayer.so) von der Seite http://labs.adobe.com/downloads/flashplayer10.html heruntergeladen. Die Installation ist denkbar einfach:

1) Deinstallation des bisherigen Flashplayer-Plugin RPMs unter Opensuse (z.B. mit Yast) / Es würde vermutlich auch ein reines Umbenennen der bisherigen 32 bit “libflashplayer.so” und/oder ein Eliminieren zugehöriger Softlinks in diversen Lib-Verzeichnissen helfen.

2) Deinstallation des Pakets nspluginwrapper (aber nicht kdebase4-nsplugin oder kdebase3-nsplugin !!!)

3) Kopieren der 64 bit “libflashplayer.so” - Datei in das Verzeichnis /usr/lib64/browser-plugins.

Dieses Verzeichnis wird unter Opensuse sowohl von Firefox als auch Opera herangezogen. In Konqueror kann man die Suchverzeichnisse für Plugins explizit einstellen.

Ergebnisse:
Ich wurde bei Firefox und Opera angenehm überrascht. Webseiten mit normalen Flashelementen funktionieren mit dem Plugin offenbar ganz gut - sowohl in puncto Audio als auch Video. Auch von mir selbst entwickelte Flash-Animationen auf Basis von Actionscript 2 liefen einwandfrei - wenn auch nicht performanter als mit dem Standard 32 bit Plugin. Richtig komplexe Sachen habe ich noch nicht getestet.

Es lohnt sich also, die Anstrengungen der Fa. Adobe weiter zu verfolgen. Ich persönlich hielte es für einen großen Vorteil, wenn man den nswrapper-Mechanismus (zumindest an dieser Baustelle) nicht mehr benötigen würde.

Seit dem Release vom Febr. 2009 funktioniert das 64-Bit Plugin nun übrigens auch mit Konqueror:
Man gehe dazu in den Konqueror Menüpunkt “Einstellungen -> Konqueror einrichten -> Erweiterungen” und lasse dort im Pfad “/usr/lib64/browser-plugins” nach neuen Plugins suchen. Die “libflashplayer.so” wird dann erkannt und funktioniert. Es lebe KDE 4.2 !

Firefox 3 - bikubisch schlechte Performance

Vor kurzem noch habe ich mich darüber geärgert, dass die Mozilla-Entwickler der Linux-Variante des Firefox 3.0 keine bikubische Bildinterpolation bei der Skalierung der Seiten verpasst hatten. Dies erschien mir doch als gravierender Nachteil gegenüber der Windows-Variante. Nun nach weiteren Erfahrungen - insbesondere von Kunden - sehe ich das etwas differenzierter.

Warum ?

1) Die Mozilla-Entwickler haben lt. einer Forums-Diskussion unter MS Windows auf Interpolations-Methoden (Routinen) der Microsoft GUI zurückgegriffen. Das ist insofern bedenkenswert, als hier zeitintensiver externer Code mit internen Darstellungsroutinen des Browsers verkoppelt werden muss.

2) Der Preis der unheiligen Allianz mit der Windows-GUI entpuppt sich als extrem hoch:

Man erhält nach dem Zoomen der Webseiten zwar schöne glatte Bilder - aber die Performance beim Scrollen von Bildern und IFRAMES in einer vergrößerten Zoomstufe des Browsers ist im FF 3.0 unter aller Sau und erheblich schlechter als im FF 2.X oder im MS IE 7. Die Scroll-Performance ist bereits auch ohne vergrößernden Zoom schlechter als im FF 2.0 - aber so richtig übel wird es nach dem Vergrößern (Zoomen) der Seiten: horizontales und vertikales Scrollen von Iframes mit größeren Bildern führt zu abenteuerlichen Schlingerbewegungen des Bildes, das offenbar in mehrere Bereiche unterteilt wird, die unterschiedlich schnell transportiert werden.

Hier wird deutlich erkennbar, dass die Bilder zerlegt (gekachelt) werden und dass die (vermutlich laufend) stattfindende Interpolation der Kacheln zu erheblichen Zeitverlusten während des Scrollings führt. Der MS IE 7 hat dieses Problem offenbar viel besser gelöst. Hier muss man sich wirklich fragen, wie die Mozilla-Entwickler die Loops für das Darstellen des Scrolling der IFRAMES und der enthaltenen Bilder (bzw. deren Kacheln) mit der externen Interpolationsroutine von MS verknüpft haben. Die Verlangsamung des Scrollens ist in mir bekannten Fällen gegenüber dem FF 2.0 jedenfalls nachweislich haarsträubend.

Dass es sich um ein reines Problem des FF 3.0 unter MS Windows handelt, zeigt sich denn auch an der Linux-Variante des FF 3.0: Hier funktioniert das Scrollen auch großer Bilder in IFRAMES in hohen Zoomstufen glatt und verzerrungs- bzw. ruckelfrei. Und um Mißverständnissen vorzubeugen: das liegt nicht an Parameter-Einstellungen zum “sanften Bildlauf” !

Fazit:
Wer sich mit den Teufel einlässt, muss wissen, was er tut, oder er bezahlt einen hohen Preis. Ich habe bereits den ersten Kunden, der unter Windows wieder von FF 3.0 auf MS IE umgestiegen ist.

Mir ist im Übrigen völlig unverständlich, warum die Mozilla-Entwickler nicht ein eigenes bikubisches Interpolationsverfahren in den Browser integrieren und sich diesbzgl. von der MS GUI unabhängig machen. Wie man solche Routinen aufsetzen muss, kann man an der GLIB-Komponente von PHP lernen. Es ist eine alte Erfahrung, dass man selbst entwickelten Code letztlich viel besser in performance-relevante Abläufe einbinden oder an solche Abläufe anpassen kann als externen Code.

Aber was reg ich mich auf?

Unter Linux geht das Scrollen ja immer noch performant ! Und das ist mir - ehrlich gesagt - fast lieber als glatte Bilder …