Ich bin kein klassischer Desktop-Entwickler. Ich komme aus der Infrastruktur-Ecke, baue Netzwerke, verwalte Server und hänge 90 % meiner Zeit im Terminal ab. Wenn ich da sitze und Kernel debugge oder YAMLs durch die Gegend schiebe, brauche ich Lärm im Hintergrund. Kein Spotify-Algorithmus, der mir die neuste Pop-Playlist reindrückt, sondern einfach gutes, altes Internetradio.
Das Problem: Die Radio-Player unter Linux nerven mich massiv.
Entweder sind es gewaltige Mediensuiten, die sofort anfangen, meine lokalen Musikordner zu indizieren (nein, danke!). Oder es sind aufgeblasene Electron-Apps, die einen kompletten Chromium-Browser hochfahren, 400 MB RAM schlucken und sich dann als "leichtgewichtig" bezeichnen, nur um einen simplen Audiostream abzuspielen. Das ist kompletter Wahnsinn.
Ich wollte etwas Natives. Etwas, das sich anfühlt, als gehöre es ins Betriebssystem. Ein Programm, das in Millisekunden startet, den Stream abspielt und dann aus dem Weg geht. Keine Podcasts. Kein lokaler MP3-Player. Nur Radio.
Native Code statt Electron-Wahnsinn
Wenn man heute eine App baut, raten einem alle zu Web-Technologien. "Schreib es einmal in Electron, lass es überall laufen!" – Ja, und überall sieht es scheiße aus, frisst RAM ohne Ende und verhält sich wie ein Fremdkörper.
Als überzeugter Arch Linux-Nutzer mit KDE Plasma war für mich die Entscheidung klar: Ich schreibe das Ding nativ in C++ und Qt 6 / QML. Wer ein Linux-Tool nutzt, der soll auch spüren, dass es für sein System gemacht ist. Es soll das System-Theme respektieren, die nativen Benachrichtigungen nutzen, sauber ins System-Tray flutschen und auf die Medientasten der Tastatur reagieren, ohne dass man einen halben Dämonen beschwören muss.
Das gilt übrigens nicht nur für den Desktop. Als es darum ging, BearWave auch aufs Smartphone zu bringen, habe ich den exakt gleichen Maßstab angelegt. Anstatt die Desktop-App irgendwie krampfhaft in einen mobilen Container zu pressen, habe ich für Android einen sauberen, eigenständigen Rewrite in Flutter/Dart gebaut. Wieder mit dem exakt gleichen Ziel: Pfeilschnell, ressourcenschonend und diesmal voll ins mobile System (inklusive Android Auto und Google Cast) integriert.
Backend und Frontend strikt trennen
Als Infrastrukturmensch kann ich keinen Code sehen, in dem UI und Logik ein großer, klebriger Klumpen sind. BearWave ist strikt getrennt: Das C++ Backend kümmert sich um das Audio-Streaming (über QtMultimedia), verwaltet Zustände, cached Senderlisten (damit ich nicht bei jedem Start die API von Radio-Browser belästige) und liefert saubere Daten. Das QML-Frontend ist wirklich nur die dumme Anzeige-Schicht.
Ganz ehrlich: QML war am Anfang echt gewöhnungsbedürftig. Wenn man aus einer Welt kommt, in der alles deterministisch hintereinander abläuft, ist dieses reaktive UI-Gefummel eine echte Umstellung. Aber es lohnt sich extrem für die Wartbarkeit.
Datenbanken? Nein, danke.
Ich hatte auch null Bock, für so ein lächerlich simples Tool direkt eine SQLite-Datenbank reinzuzimmern. Favoriten und Einstellungen liegen als simple JSON-Dateien im Config-Verzeichnis des Nutzers. Wenn was kaputt ist: Texteditor auf, fertig. Keine Migrationen, kein Overhead.
Flathub hat nein gesagt – Plan B lief
Als Nächstes wollte ich BearWave sauber als Flatpak verpacken und über Flathub ausliefern. Der Review endete ohne Freigabe — aus meiner Sicht zu pauschal und zu wenig am Produkt orientiert. Den genauen Wortlaut kann ich heute nicht mehr verlinken; der Antrag ist inzwischen gelöscht. In meinen Projektnotizen steht die Einordnung noch nach, für den Blog reicht mir: Das war kein Showstopper.
Statt mich in eine öffentliche Fehde zu verheddern, hab ich's wie ein Infrastrukturproblem behandelt. Flathub passt nicht? Dann bau ich mir die Pipeline selbst.
Ich hab mich am Wochenende hingesetzt und mein eigenes, GPG-signiertes Flatpak-Repo unter flatpak.bearwave.app hochgezogen. Jetzt läuft der Build-Prozess via GitHub Actions völlig automatisiert, signiert die Pakete und schiebt sie auf meinen eigenen Server. Für die echte Arch-Fraktion (zu der ich mich natürlich zähle) gibt's mein Tool als AUR-Paket (bearwave-git) – der Weg, über den ich es auf meinen eigenen Maschinen installiere.
Release und Stabilität
BearWave ist gerade in einer sehr stabilen Phase: Es startet sofort, spielt Musik und stürzt nicht ab. Ich werde sicher hier und da noch Code aufräumen (die Lizenz ist übrigens mittlerweile auf GPL-3.0-or-later gewechselt), aber ich habe nicht vor, das Ding mit tausend Features zu überladen.
Wer unter Linux ebenfalls keine Lust auf überladene Mediaplayer hat und stattdessen ein natives, schlankes Tool für Radio unter KDE sucht – BearWave lohnt einen Blick. Quellcode und Issues liegen auf GitHub und GitLab.