Die grossen Anwendungen sind beständig und werden gut gepflegt, weil dahinter im besten Fall ein grosses Team steht. Ich meine Anwendungen wie Gimp, LibreOffice, VLC, Thunderbird usw. Selbstverständlich ist mir bekannt, dass auch solche Anwendungen unter dem Nebraska-Problem leiden können. Doch darum geht es mir in diesem Artikel nicht.
Mir geht es um die kleinen oder mittelgrossen Anwendungen, also solche, die kommen und gehen. Insbesondere sehe ich eine Flüchtigkeit bei Desktop-Erweiterungen. Bis vor ein paar Tagen habe ich die GNOME-Shell-Erweiterung YetAnotherRadio verwendet, um Internetradiosender sehr bequem aus dem Panel auswählen und abspielen zu können.
Vergangene Woche streckte diese Erweiterung die Hufe in den Himmel. Das ist nicht neu und nicht das erste Mal, dass GNOME-Shell-Erweiterungen bei einer neuen Version der Desktop-Umgebung ihren Dienst versagen. Manchmal muss man geduldig sein, bis der Entwickler seinen Code auf die aktuelle Desktop-Version angepasst hat. Ich bin eher der ungeduldige Typ. Was nicht läuft, wird entfernt. Meistens gibt es eine Alternative, die ähnliche Funktionen bietet. Sucht man im Verzeichnis der GNOME-Shell-Erweiterungen nach "Radio" findet man Ausweichmöglichkeiten.
Ob diese Erweiterungen funktionieren, ist eine andere Frage. Doch man kann auf der offiziellen Seite der Erweiterungen nachsehen, für welche Desktop-Version die Erweiterung angeboten wird.
Doch das heisst gar nichts. Obwohl die Shell-Version 49 als unterstützt angezeigt wird, läuft der Internet-Radio-Player bei mir nicht mehr. Er stürzt mit einer Fehlermeldung ab.
Und kommt mir jetzt nicht mit: "Dann mache doch ein Issue auf oder schreibe einen PR." Hätte ich machen können; mache ich auch häufig, doch dann würde es diesen Artikel nicht geben. Ich kann mich zwischen Issues schreiben oder Artikel schreiben entscheiden. Für beides reicht meine Zeit nicht.
In diesem Fall habe ich mich für eine andere Option entschieden. Ich habe eine eigene Anwendung ausgegraben, die ich vor vielen Jahren geschrieben habe: Station. Es gibt einem ein warmes Gefühl im Bauch, wenn man auf eine eigene Anwendung zurückgreifen kann. Etwas, was man für sich selbst geschrieben und der Community zur Verfügung gestellt hat.
Da ich auf Social Media über dieses Thema berichtet habe, dauerte es nicht lange, bis sich Prof. P. aus der GNU/Linux.ch-Community mit Pull Requests meldete. Dank seiner Arbeit konnten gestern Abend ein paar XML-Char-Escape-Probleme gelöst werden. Ich habe den Stream-Recording Teil neu geschrieben und die Suche nach Sendern verbessert.
But wait, there is more. Nachdem Prof. P. entdeckte, dass ich irgendwann einmal den GUI-Teil (Gtk3) entfernt hatte, fühlte er sich berufen, ein TUI für Station mit ncurses zu schreiben. Seine Arbeit ist noch nicht fertig, sieht aber schon ziemlich gut aus:
ncStation - Funktionsmenü
ncStation - Play
Was mich immer wieder beeindruckt, ist die Kraft der Community. In der Welt der goldenen Wände ist so etwas nicht möglich. Doch bei uns geht das:
- Eine Anwendung funktioniert nicht mehr
- Du holst deine eigene Lösung aus der Schublade
- Du berichtest darüber
- Die Community reagiert
- Jemand aus der Community zeigt Interesse und fixt das Problem
- Dieser Jemand zeigt noch mehr Interesse und verbessert die Anwendung für alle
Fazit
Dieser Artikel ist spontan entstanden und beruht auf einer aktuellen Begebenheit. Den Titel hatte ich mir schon vor ein paar Tagen überlegt, als sich YetAnotherRadio verabschiedet hatte. Eigentlich sollte es darum gehen, dass CLI-Anwendungen häufig die einfacheren und besseren Lösungen sind, als GNOME-Shell-Erweiterungen oder Electron-Monster. Als sich Prof. P. gestern Abend mit der Verbesserung von Station einbrachte, bekam der Artikel einen anderen Dreh.
Habt ihr auch Erfahrungen mit flüchtigen Anwendungen gemacht?
Titelbild: https://pixabay.com/photos/dandelion-heaven-flower-nature-463928/
Quellen:
https://github.com/BuddySirJava/YetAnotherRadio
https://extensions.gnome.org/extension/8843/yet-another-radio/







Ohne überkritisch sein zu wollen: Anwendungen zu programmieren und dabei Hilfe zu bekommen geht auch im goldenen Käfig. Evtl nicht ganz so einfach, aber völlig blockiert wären sie kaum irgendwo.
Ich habe ebenfalls eine Erfahrung mit einer Anwendung, die nicht mehr weiterentwickelt wurde: Simdock. Statt da aber auf meine eigene zurückzugreifen (die ich nicht hatte) habe ich stattdessen einen interessant aussehende Entwicklerbranch genommen, der damals auf Sourceforge noch rumlag, und den fertigentwickelt, zumindest soweit ich das konnte. Seitdem ist es "mein" Projekt, Software die ich unter https://github.com/onli/simdock am Leben halte. Nett war dabei Unterstützung bei der Paketierung. Leider kam bei der eigentlichen Entwicklung kein Entwickler dazu und ich glaube, die Pakete sind auch nicht mehr am Leben. Falls jemand sich berufen fühlt, ich würde mich freuen... :)
Das sieht ja richtig gut aus. Könnte vielleicht eine Alternative zu pyradio sein, was ich nutze.
Das hier ist ein GNOME-spezifisches Phänomen, kann aber jedem kleinen Open Source Projekt (insbesondere bei API-Änderungen) passieren. Die Problembeschreibung habe ich soweit verstanden. Was mich interessiert ist wieso man "Internetradiosender sehr bequem aus dem Panel auswählen und abspielen" muss, wenn es für die gleiche Funktionalität gefühlt mehr als 200 Webdienste gibt. Als gutes Beispiel: https://radio.garden/ Hast Du außer Sender auswählen und Musik hören etwa weitere persönliche Spezial-Anforderungen die du uns verheimlicht hast oder was sind die Gründe für das GNOME Panel?
Klar, es gibt x Möglichkeiten, Internetradio abzuspielen. Mir hat die Schlichtheit des Players im Systray gefallen.
Sehr gut, bravo! 👍️
Tatsächlich kann ich mich dunkel erinnern, mal das Paket radiotray im Einsatz gehabt zu haben, dass unter LXDE/Qt irgendwann nicht mehr "wollte". Aktuell verwende ich stattdessen 'goodvibes'. Mit den Stationen in Playlist(s) ginge vmtl. "jeder" Audioplayer.
Nicht verschweigen will ich ferner das Verzeichnis radio-browser und 'radiodroid' von 'segler-alex' als Client für Android.
In den letzten Jahren ist mir auch aufgefallen, dass speziell Plugins eine besonders hohe Sterblichkeit haben. Deine Gnome Erfahrung kann man 1:1 auf KDE übertragen.
Inzwischen suche ich auch eher gezielt nach CLI oder TUI Lösungen. Die funktionieren immer, Fernwartung ist damit auch super machbar und ich muss mir um Gtk oder Qt keine Gedanken machen.
Hallo Ralf, es gibt eine einfache Lösung für die YetAnotherRadio GNOME-Shell-Erweiterung. Siehe hier: https://github.com/BuddySirJava/YetAnotherRadio/issues/27
Danke Werner. Ich warte lieber ab, bis der PR angenommen ist. Bis dahin langt mir meine eigene Lösung: Station.