Schlagwort-Archive: Tutorial

Da ich bekennender Fan der Programmiersprache Java bin (aber nicht ausschließlich), möchte ich den Zeitpunkt der Veröffentlichung des JDK7 nutzen und ankündigen, dass wohl in Zukunft auch ein paar Beiträge über Java-Entwicklung folgen werden. Ich bin noch nicht wirklich sicher worüber genau, aber mir wird da schon was einfallen.

Themen, die ich mir vorstellen könnte, wären meine Erfahrungen mit dem JDK7, außerdem diverse Tricks und Techniken, die ich bei meinen zahlreichen kleineren Gamedev-Versuchen (z.B. Spacola Eclipse) gelernt habe. Womöglich profitiert nochmal jemand davon, dann hätte es sich schon gelohnt, darüber zu schreiben. Wenn alles gut läuft, werden sich die Tutorials nicht auf Java beschränken, sondern auch andere Programmiersprachen umfassen, mit denen ich mich befasse. Auch mathematische Probleme, denen man früher oder später zwangsläufig begegnet, könnte ich dabei ansprechen und einen Lösungsansatz aufzeigen.

Was Spacola Eclipse angeht: Die Entwicklung steht nicht still, aber das Spiel ist derzeit nicht meine Top-Priorität, daher geht es verständlicherweise nur langsam voran. Ich habe definitiv neue Ideen, die ich demnächst umsetzen werde. Zunächst will ich eben einige private und berufliche Dinge geklärt wissen, bevor ich mich wieder mit vollem Eifer meinem Hobbyprojekt widmen kann.

Heute habe ich ein paar Tipps/Tweaks für meinen favorisierten Videoplayer im Angebot. Der freie KMPlayer eignet sich meiner Erfahrung nach am besten für hochauflösende (1080p-)Videos und schlägt auch den beliebten VLC Player bei der Kompatibilität. Zu oft habe ich den VLC Player bei Dateien versagen gesehen, die der KMPlayer ohne Schwierigkeiten abgespielt hat. Zu Unrecht ist der KMPlayer eher unbekannt, da er sehr leistungsfähig ist, eine beeindruckende Funktionsvielfalt bietet und eine ansehnliche GUI hat. Kürzlich habe ich im Forum zum KMPlayer nach Lösungen für zwei Makel gesucht, die mich schon länger gestört haben. Ich glaube es schadet nicht, wenn ich die Ergebnisse meiner Suche hier zusammenfasse.

Mein erster Tipp gilt all denen, die beispielsweise 720p-Videos im KMPlayer auf Vollbild strecken (mit einer entsprechend größeren Desktopauflösung) und sich wundern, warum man plötzlich im Bild abknickende Kanten und Streifen an Konturen sieht. Die ausgefransten Kanten sind nicht zu sehen, wenn man das Video in Originalgröße betrachtet. Das Problem ist der voreingestellte Video-Renderer. „VMR7 mit Fenster“ und „VMR9 mit Fenster“ erzeugen diese hässlichen Artefakte beim Strecken. Ein Wechsel auf einen anderen Renderer, z.B. die Entsprechungen „VMR7 renderlos (HQ-Untertitel)“ und „VMR9 renderlos (HQ-Untertitel)“, behebt das Problem und verbessert das Filmerlebnis erheblich.

Erreichbar ist das Menü über einen Rechtsklick ins Bild -> Video (erweitert) -> Video-Renderer.

Der zweite Tipp bezieht sich auf zwei Probleme im Zusammenhang mit Videodateien mit mehreren Tonspuren: Bei bestimmten Videodateien kann es beim Wechseln der Tonspur zu einem stark verzerrten Bild kommen, auf dem nichts mehr erkennbar ist. Ungefähr so wie wenn man einen analogen verschlüsselten Fernsehsender ohne den benötigten Decoder betrachten wollte. Ein Wechsel zurück zur alten Tonspur ändert dann auch nichts mehr. Der KMPlayer muss neu gestartet werden. Das Problem ist mit derselben Videodatei jederzeit reproduzierbar und führt dazu, dass sich die Datei nur mit der voreingestellten Tonspur betrachten lässt. Auch kommt es manchmal vor, dass ein Video sich nicht weiter abspielen lässt, wenn die Tonspur gewechselt wird. Hier muss der Player ebenfalls neu gestartet werden.

Eine simple Einstellung korrigiert beide Erscheinungen: Rechtsklick ins Bild -> Optionen -> Einstellungen -> Video-Verarbeitung -> Tab „Allgemein“ -> KMP Video-Transform-Filter -> Bedingung: „Immer verwenden (wärmstens empfohlen)“.

Anschließend sollten die Bildfehler verschwinden und auch der Wechsel der Tonspur sollte schneller gehen. Bei beiden Einstellungen frage ich mich, wieso sie nach der Installation nicht voreingestellt sind. Insbesondere bei der letzten, die doch schon vom Entwickler „wärmstens empfohlen“ wird. Ich kann nur Kompatibilitätsgründe dahinter vermuten.

Schon seit Beginn meines Studiums bin ich großer Fan von OpenOffice.org (und neuerdings entsprechend LibreOffice). Ich finde den Gedanken toll, dass man ein vollständiges Office-Paket, das praktisch den gleichen Leistungsumfang wie Microsoft Office hat, kostenlos im Internet bekommen kann. Manches mag MS Office etwas besser können, anderes kann dafür nur OOo. Aber wer das bessere Preis-Leistungs-Verhältnis hat, muss ich hier wohl nicht extra betonen. Da ein Student sowieso an jeder Ecke sparen muss, war es nur naheliegend, dass ich umgestiegen bin.

In den letzten fünf Jahren hat sich bei mir einiges an Erfahrung im Umgang mit dem freien Office-Paket angesammelt, allem voran deshalb, weil ich sämtliche Ausarbeitungen, Dokumentationen, Diagramme, Präsentationen und meine Diplomarbeit damit verfasst habe. Ich weiß daher, dass sich die Bedienung der Programme gerade für Neulinge, wenn es um komplexere Dinge wie Dokumentenstrukturierung geht, zuerst schwierig gestalten kann. Man hat zwar einen großen Vorteil, wenn man schon mit MS Office umgehen kann, aber es bleibt einem nicht erspart, sich viele Dinge neu anzueignen.

Ich bin ganz gewiss kein Profi im Umgang mit OOo und LibreOffice, eher eine Art fortgeschrittener Anfänger, aber inzwischen kann ich auch anspruchsvollere und längere Dokumente flüssig anfertigen, ohne nach Tutorials zu suchen. Gerade was Dinge wie doppelte Seitennummerierung, aufwändige Kapitelnummerierung, verschiedene Seitenlayouts etc. angeht, habe ich oft Stunden damit zugebracht, mir aus dem Internet herauszusuchen, wie ich das bewerkstelligen kann.

Als sich LibreOffice kürzlich von OpenOffice.org abgespalten hat, war ich zunächst ratlos, welche Office-Lösung ich künftig weiterverwenden sollte. Inzwischen habe ich mich für LibreOffice entschieden. Im Moment macht diese Entscheidung noch keinen merklichen Unterschied, da die Pakete beinahe identisch sind, aber das wird sich rasch ändern. Meine Artikel über LibreOffice werden sich daher fast immer 1:1 auf OOo anwenden lassen. Persönlich ziehe ich die Lösung der Document Foundation vor, da Oracle offenbar nicht unbedingt den besten Ruf in Entwicklerkreisen hat. Ich glaube, dass es sich positiv auswirkt, dass man nicht unter der Fuchtel eines Softwaregiganten steht. Die neugewonnene Freiheit der Entwickler wird LibreOffice dauerhaft zugute kommen, so wie das einst bei der Entstehung von OOo der Fall war.

Da ich mein Wissen in irgendeiner Form mit Neulingen teilen möchte, werde ich voraussichtlich in Zukunft mehrere kleine Tutorials schreiben, die sich mit alltäglichen Problemen im Umgang mit LibreOffice befassen. Am wichtigsten ist mir dabei der LibreOffice Writer, da dieser erfahrungsgemäß am häufigsten gebraucht wird.

Eine neue Version der NextGEN Gallery – eine neue Runde für meinen Kampf gegen Windmühlen. Ein kurzer Blick auf den Quellcode der neuen Version zeigt: Die betroffene Zeile wurde zwar von 1.7.3 auf 1.7.4 modifiziert, aber der alte Fehler ist noch drin. Der Code ist weiterhin nicht valide wenn zwei oder mehr Galerien auf derselben Seite angezeigt werden. Ich frage mich, wie lange es noch dauert, bis das behoben wird.

Also hier die aktualisierte Fassung meiner kleinen Korrektur. Geöffnet werden muss die Datei /wp-content/plugins/nextgen-gallery/lib/navigation.php. Folgender Abschnitt muss gefunden werden:

In der vierten Zeile alles ab (einschließlich) id= bis vor href= entfernen. Also folgendermaßen:

Mann, was freu ich mich schon auf die nächste Version in drei Wochen, wenn ich den Fehler wieder fixen darf…

OK, jetzt reicht es. Gerade vor ein paar Tagen habe ich darüber geschrieben, dass ich endlich auch die NextGEN Gallery für WordPress dahingehend korrigiert habe, dass sie jetzt XHTML 1.1-valide ist. Heute gab es das Update auf Version 1.7.3, das ich selbstverständlich sogleich installiert habe – und meine Befürchtung bewahrheitete sich: Der alte Fehler ist wieder da. Der W3C-Validator sagt folgendes:

Line 1395, Column 407: ID „ngg-next-2″ already defined
…nggpage=10″>10<a id=“ngg-next-2″ href=“/fotos/?nggpage=2“>&#9…

An „id“ is a unique identifier. Each time this attribute is used in a document it must have a different value. If you are using this attribute as a hook for style sheets it may be more appropriate to use classes (which group elements) than id (which are used to identify exactly one element).

Dazu passend die Ursache für den Fehler:

Line 746, Column 405: ID „ngg-next-2″ first defined here
…/?nggpage=9″>9</a><a id=“ngg-next-2″ href=“/fotos/?nggpage=2“>&#9…

Da in einem validen HTML-Dokument jede ID höchstens einmal vorkommen darf, wird ein Fehler für jede weitere Galerie erkannt, die sich auf derselben Seite befindet wie die erste Galerie. In meinem Fall derzeit acht Galerien, ergo sieben Fehler. Das Problem ist: Für mehrere Galerien pro Seite liefert die NextGEN-Gallery von Herrn Alex Rabe (die ansonsten eigentlich makellos ist) keinen validen Code.

Wie ich bereits erwähnte, ist dem Autor bekannt, dass ein Fehler vorliegt. Er scheint nur zu faul zu sein, das zu fixen. Oder vergesslich. Ich dachte mir, wenn ich den Fehler schon wieder sporadisch flicken muss, dann kann ich ja eigentlich auch andere daran teilhaben lassen. Vielleicht stört sich ja außer mir noch jemand daran.

Geöffnet werden muss die Datei /wp-content/plugins/nextgen-gallery/lib/navigation.php. Sucht in der Datei nach folgendem Abschnitt:

if ( ( $page ) * $maxElement < $total || -1 == $total ) {
    $args[’nggpage‘] = $page + 1;
    $this->next = $nggRewrite->get_permalink ( $args );
    $r .= ‚<a id=“ngg-next-‚ . $args[’nggpage‘] . ‚“ href=“‚ . $this->next . ‚“>&#9658;</a>‘;
}

Entfernt werden muss in der vierten Zeile alles ab (einschließlich) id= bis vor href=. Also folgendermaßen:

    $r .= ‚<a href=“‚ . $this->next . ‚“>&#9658;</a>‘;

Speichern, hochladen, fertig. Diese Lösung ist nicht besonders intelligent, aber sie funktioniert und stellt den Validator zufrieden.