MediathekView 3.0 und Wbar 2.3.4 auf dem Weg nach Debian!?

Bevor es hier gleich mit einem anderen Zwischenfazit weitergeht, wie steht es um MediathekView und Wbar?

Entwicklung braucht Zeit. Einen Sponsor zu finden, der die Sache ins Archiv hochlädt, ist ein Geduldsspiel. Es gibt an die 30000 Pakete in Debian aber nur ca. 1000 Debian-Entwickler, die die Berechtigung besitzen Pakete überhaupt in das Archiv zu befördern, wo die FTP-Master mit Argusaugen über jeden Neuzugang wachen.

Tausend Leute, das klingt eigentlich gar nicht so schlecht. Manche davon kümmern sich jedoch um 100 verschiedene Pakete gleichzeitig und Debian ist nicht nur Softwareentwicklung. Es gibt Teams, die sich um die Übersetzung der Software und die Gestaltung und Aufrechterhaltung der Webpräsenz und von Mailinglisten kümmern. Und dann soll man auch noch die Verantwortung für unbekannte Neuentwickler übernehmen, sie anleiten und deren Pakete auf Korrektheit überprüfen? Wenn so ein Neuer Schaden anrichtet und man hat es vorher nicht gesehen…

Klingt nicht nach der dankbarsten Aufgabe, aber es gibt Freiwillige, die sich darum kümmern. Vor wenigen Tagen habe ich nach genau so einem Sponsor oder Mentor für Wbar gesucht (#688310). Mittlerweile ist sogar Version 2.3.4. erschienen und meine eingesandten Patches wurden freundlicherweise berücksichtigt. Etwas überrascht war ich dann doch als Bart Martens, seines Zeichens Debian-Entwickler und sehr aktiv bei den Mentoren Bug #575087 auf Schweregrad „Grave“ hochgesetzt hat und mich gebeten hat diesen für Wheezy zu fixen.

Nun würde Version 2.3.4 von Wbar das Problem lösen, aber aus der kurzen Nachricht von Bart konnte ich nur entnehmen, dass ich wohl einen gezielten Fix für das aktuelle Paket in Wheezy einspielen soll. Wer sich nun fragt, warum Wbar plötzlich unbrauchbar wurde, der findet die Lösung vielleicht, wenn er versucht Wbar ohne empfohlene Pakete zu installieren. Die Schnellstartleiste verweigert ihren Dienst, weil der Pfad zu den Icons und/oder der Schrift dann den Rückgabewert NULL liefert. Kurzum das Ding startet nicht.

Also meine bescheidene Meinung ist: Wer Schellstartleisten ohne den korrekten Pfad zu den Symbolen startet, muss mindestens zweimal von e^(i*pi)+1 bis Unendlich zählen. Jedoch ganz abwegig ist der Fehlerbericht natürlich nicht und ja in Version 2.3.4. darf man auch den falschen Pfad zu seinen Symbolen und der Schrift angeben und das (transparente) Hintergrundbild von Wbar ist trotzdem zu sehen. 🙂

Ich denke jedoch, dass das kein veröffentlichungskritischer Fehler ist und werde das so auch noch einmal in den Fehlerbericht schreiben. Ist natürlich ein doofer Einstieg in Debian, wenn man erst einmal anderer Meinung als der Debianentwickler ist. 😐

MediathekView ist meiner Meinung nach in einem vorzeigbaren Zustand und wartet darauf einmal gründlich analysiert zu werden. Mittlerweile haben sogar zwei DDs Interesse daran bekundet. Der Witz daran ist, dass es bisher dabei geblieben ist. Die ganze Geschichte lässt sich in Fehlerbericht #681680 nachlesen. Ich bin aber weiterhin guter Hoffnung und ja 2.6.1 wurde aufgegeben, entweder schafft es 3.0.0 nach Wheezy oder gar nichts.

Ich habe die Downloadlinks von Mediathekview und Wbar aktualisiert. Wer also die Zeit verkürzen möchte, findet dort die entsprechenden Debianpakete. Danke auch an das bisherige Feedback zu MediathekView. Ich habe den Pfad zum flv.sh-Skript angepasst. Auch die Idee mit dem Shellskript halte ich weiterhin für gut. Vielleicht lässt sich damit in der Zukunft tatsächlich die Mediathek komplett ohne den Umweg über Java auf die Konsole holen. 😉

5 Replies to “MediathekView 3.0 und Wbar 2.3.4 auf dem Weg nach Debian!?”

  1. Stimmt, danke für den Hinweis! Die c’t liegt hier bei mir, aber den Artikel hatte ich noch nicht erspäht. Man muss natürlich dazu sagen, dass ich nur das Paket für Debian packe. Aber schön, dass die c’t Wbar in den Test aufgenommen hat, das hilft der Anwendung bestimmt. 🙂

  2. Habs auch nur beim durchblättern gesehen. Und da dachte ich mir: „Das Wbar hast Du doch gerade in Deinen RSS Feeds gelesen.“ Und siehe da es war das selbe Programm. Wird ja auch Zeit das die c’t mal wieder zu Ihren Ursprüngen und damit weg von dem ganzen iZeugs kommt.

  3. Hi,

    finde wbar ist eine feine Sache. Ich hätte aber da eine oder zwei Fragen. Hoffentlich stempelt man mich nicht als noob ab 🙂 Wie bekomme ich es hin, daß wbar immer im Vordergrund bleibt, auch wenn ich ein anderes Fenster drüber lege. Oder das es sich wie ein Panel verhält. Also Platz für sich reserviert, so daß es nicht überdeckt werden kann. Finde da keine Option. Meine zweite Frage wäre warum ist in der wbar-conf kein Drag und Drop vorhanden? Wäre es nicht sinnvoll wbar,wbar-conf und wbarconfig zu einem Programm zu verbinden? So daß ich mit einem Rechtsklick die Konfiguration starten kann und mit Linksklick die Buttons drücke. Wäre mal so eine Anregung.

    P.S.: Läuft auch auf Arch-Linux sauber.

  4. Hallo,

    Danke für deine berechtigten Fragen! Es gibt leider keine Funktion, die Wbar immer über allen Fenstern erscheinen lassen würde. Dieses Feature steht seit 2008 auf der Wunschliste http://code.google.com/p/wbar/issues/detail?id=14.

    Bei wbar-conf gilt das gleiche. Die GUI ist einfach gehalten und unterstützt kein Drag&Drop von Symbolen. Wbarconf ist nicht Bestandteil des offiziellen Projekts und wird es vermutlich auch nie werden, da wbar-config die gleiche Funktion bietet.

    Wbar selbst kann auch in Sachen Funktionalität nicht mit anderen Projekten wie dem AWN-Dock mithalten. Es ist dafür aber klein und schlank gehalten und es hat kaum Abhängigkeiten. Eine Kombination von Wbar-config mit Wbar in einer Binärdatei würde dazu führen, dass man dann für die Leiste auch GTK als Abhängigkeit brauchen würde und schon wäre ein Vorteil von Wbar dahin.

    Ich denke, man sollte das erste Problem mit der Leiste im Vordergrund angehen und dass Wbar sich automatisch erneuert, wenn das Hintergrundbild gewechselt wird. Dann wäre ich total zufrieden.

    Wie immer sind Patches sehr willkommen. 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.