In unseren vorangegangenen Beiträgen haben wir das Projekt und die erste Version der App auf Basis von Tkinter vorgestellt.
Für die Benutzeroberfläche von Version 2 haben wir wegen der besseren Barrierefreiheit das Qt-Framework PySide6 gewählt.
Den Programmcode finden Sie auf GitHub:
https://github.com/henrietteBaum/MusicSearch-v2
Blog-Beitrag: Installationsanleitung
Version 2.0
In Version 2 implementieren wir zusätzlich die API von MusicBrainz für die Suche. Wie bereits in Version 1 starten wir mit einer CLI-Version als technischer Basis der App. Es kommt noch keine grafische Benutzeroberfläche zum Einsatz. Aber wir verwenden bereits eine Projektstruktur.
.
├── app
│ ├── core
│ │ ├── models.py
│ │ ├── __pycache__
│ │ │ ├── models.cpython-312.pyc
│ │ │ └── search.cpython-312.pyc
│ │ └── search.py
│ ├── services
│ │ ├── itunes.py
│ │ ├── musicbrainz.py
│ │ └── __pycache__
│ │ ├── itunes.cpython-312.pyc
│ │ └── musicbrainz.cpython-312.pyc
│ └── ui
│ ├── cli.py
│ ├── __init__.py
│ └── __pycache__
│ ├── cli.cpython-312.pyc
│ └── __init__.cpython-312.pyc
├── Documentation
├── main.py
├── README.md
└── requirements.txt
Der Suchbegriff wird einfach über die Python-Funktion input() im Terminal abgefragt. Und auch die Suchergebnisse werden in Textform im Terminal ausgegeben. Sie sind mit limit auf 5 begrenzt. Das Abrufen der Gesamt-Treffer funktioniert noch nicht. Gestartet wird die App über die Datei main.py.
Version 2.1.0
Erste Gehversuche mit dem Qt-Framework PySide6: Wir bauen eine einfache grafische Benutzeroberfläche (GUI). Es gibt noch kein Menü und keine Toolbar. Die Anzeige der Gesamtergebnisse funktioniert nicht
Die Suchergebnisse aus den beiden APIs, iTunes und MusicBrainz werden technisch getrennt in zwei QFrames angezeigt
Version 2.1.1
Ein erster Test mit anderem Fenster-Layout:
- Menübar
- Toolbar
- Sidebar
- Statusbar
Für die Suchergebnisse werden, getrennt nach API, Tabs verwendet, für die Suchergebnisse ein QTextEditor.
Ein dritter Tab dient für die spätere Implementierung einer Literatursuche. Mit einem Suchvorgang kann dann neben Musiktiteln oder Interpreten auch eine Such nach Sekundärliteratur angestoßen werden.
Alle Tabs werden durch eine central_widget.py koordiniert.
Zusätzlich enthält die Seitenleiste ein Feld für die Anzeige einer Such-Historie.
Version 2.1.2
Eine erste Formatierung für die Suchergebnisse, die Datensätze werden optisch getrennt voneinander gezeigt.
Jeder Tab erhält eine eigene Formatierung durch eine separate Datei formatter.py. In der Datei werden Python-Anweisungen mit HTML-Elementen kombiniert.
Version 2.1.3
Für die Darstellung der Suchergebnisse wurde eine Zoom-Funktion implementiert. Sie kann über die gewohnte Tastenkombination (Strg + Plustaste), per Mausrad bei gedrückt gehaltener Strg-Taste oder über das View-Menü bedient werden.
Version 2.1.4
Statt der Ausgabe der Suchergebnisse in einem QTextEdit Widget, verwenden wir nun einen QTextBrowser. In diesem Widget ist der Text beireits read-only , es gibt eine Scroll-Leiste und die Ausgabe lässt sich gut per HTML semantisch strukturieren. Der Text kann per Tastatur markiert und kopiert werden. Später können auch über Links in den Suchergebnissen die Quellen unmittelbar angesteuert werden.
Zudem haben wir die Benutzerführung optimiert: Der Fokus startet im Eingabefeld und wandert beim Betätigen der Tabulator-Taste nach unten durch die Filter zu den Suchergebnissen. Zwischen den Tabs wechselt man mit den Pfeiltasten.
Damit wird die Navigation und der Bedienkomfort für Screenreader-Nutzer deutlich erhöht.
Versionen 2.1.5 – 2.1.7: File-Dialog
Für den bereits zuvor angelegten Menüpunkt „Save“ implementieren wir eine entsprechende Funktion (v2.1.5). Der Benutzer kann seine Suchergebnisse als Textdatei speichern. Die Funktion öffnet den system-typischen Filedialog, schlägt aber schon als Speicherort den Dokumenten-Ordner im User-Verzeichnis und einen Dateinamen mit Quelle und Zeitstempel vor
iTunes_2026-01-24_12-22_export.txtVersion 2.1.6 fügt eine Print-Funktion hinzu. Damit kann der Nutzer entweder Drucken oder den Text als PDF-Datei exportieren.
Version 2.1.7 ergänzt das Menü um den Punkt „Export to PDF“. Dazu haben wir eine erste CSS-Formatierung hinzugefügt, um das Erscheinungsbild der Ergebnisse zu verbessern. Auch hier schlagen wir dem Nutzer einen Pfad vor, der auf dem zuletzt verwendeten Pfad basiert. Zudem wird ein Dateiname mit Zeitstempel und Tab-Titel generiert, um Überschreibungen zu vermeiden.
Literatur_2026-01-24_12-32_export.pdfEine MessageBox informeirt, wenn keine Suchergebnisse zum Export vorhanden sind. Das ist für sehende Nutzer nicht nötig, für Screenreader aber hilfreich.
Zusätzlich zeigen wir Informationen in der StatusBar. Die Anzeigedauer haben wir von den sonst für kürzere Texte üblichen 2000 (ms, 2 Sek.) auf 8000 erhöht. Nutzer mit eingeschränktem Sehvermögen benötigen oftmals ein wenig mehr Zeit zum Erfassen aller Informationen.
Nachrichten in der Statuszeile lassen sich sogar mit HTML ein wenig hervorheben (z. B. fett ), damit sie noch besser lesbar sind:
self.statusBar().showMessage("<b>Datei wurde erfolgreich gespeichert!</b>", 8000)
Wie sich hier bereits zeigt, ist die oftmals anzutreffende Formatierung von Text mit grauer Schrift oder grauer Schrift auf grauem Hintergrund, schlecht zu lesen. Das werden wir in einer der folgenden Version ändern.
Version 2.2
Die App wird um eine API erweitert: OpenLibrary. Das ermöglicht die gleichzeitige Suche nach Literatur und Musik zum eingegebenen Suchbegriff. Die Ergebnisse werden in dem bereits vorbereitetem, separaten Tab angezeigt. Für die Suchlogik ist die Datei openlibrary.py zuständig, die ähnlich wie die itunes.py aufgebaut ist. Die Datei models.py haben wir um eine Dataclass Book erweitert.
Version 2.2.1
Wir haben die Toolbar-Schaltfläche für die OpenLibrary-Suche hinzugefügt. Diese Schaltfläche ermöglicht es Benutzern, die Suche auf OpenLibrary zu begrenzen, indem dieses Icon ausgewählt wird. Der Start der Suche erfolgt über den neuen Suchbutton in der Seitenleiste oder per Enter-Taste im Suchfeld.
Die Icons in der Toolbar dienen nur noch zur Auswahl der Suchquelle (API, iTunes, MusicBrainz, OpenLibrary) und nicht mehr zum Starten der Suche.
- Lupen-Icon: alle APIs
- Music-Notes: iTunes und MusicBrainz
- Library-Icon: OpenLibrary
- Lyrics-Icon: hat noch keine Funktion
- Clean-Icon: löscht den Inhalt der Tabs
Version 2.2.2
Die Formatierung der Suchergebnisse wurde geändert, es werden der besseren Lesbarkeit wegen keine grauen Schriftfarben auf grauem Hintergrund mehr verwendet. Die Überschriften innerhalb der Tabs passen sich nun automatisch der vom Nutzer für sein Betriebssystem gewählten Akzentfarbe an. Graue Schriften und Hintergründe sind entfernt.
Version 2.2.3
Über das Menü „Help“ öffnet sich nun ein separates Fenster für die Dokumentation, der Menüpunkt „About“ zeigt ein Info-Fenster mit Versionsnummer und Autoreninformationen an. Das Fenster für die Dokumentation lässt sich verschieben und in der Größe anpassen. Es kann neben dem Hauptfenster geöffnet bleiben, um während der Nutzung der Anwendung schnell auf die Hilfe zugreifen zu können.
Zusätzlich haben wir die Anzeige der Suchergebnisse optimiert. Eine horizontale Linie und etwas mehr Abstand sorgen für eine deutlichere Trennung der einzelnen Datensätze im Ergebnisfenster.
Version 2.2.4
Wir mussten die close-Funktion korrigieren um einen Thread-Fehler beim Schliessen des Fensters, bei gleichzeitigem Verlassen des limit-Eingabefeldes zu beheben.
Verbesserung der Lesbarkeit der Suchergebnisse durch Anpassung von Schriftgrößen und Abständen im Ergebnis-Browser, Die Trenner zwischen den Ergebnissen werden nun ebenfalls in der Akzentfarbe dargestellt.
Version 2.2.5
Diese Version fügt eine weitere ComboBox hinzu, über die der Nutzer auswählen kann, welchen Medientyp er suchen möchte (Album, Track, Künstler). Die Suche bei MusicBrainz zeigt nun auch das Album zum Suchbegriff an.
Hier kommt ein wichtiges Prinzip im Software-Design zum Tragen: Das Model bestimmt die einheitliche Sprache der App, nicht die API.
- Für den User ist es ein „Album“.
- iTunes nennt es technisch collectionName.
- MusicBrainz nennt es technisch releases.
- Spotify nennt es wieder anders.
Die Aufgabe der Service-Dateien (musicbrainz.py, itunes.py) ist es, diese fremden Begriffe in die Sprache des Nutzers bzw. der App (album) zu übersetzen. Würde man stattdessen für jede API ein eigenes Feld einrichten (itunes_album, mb_release, spotify_context), würde das Model riesig und dein Code für die Anzeige (Formatter) ein Chaos aus if/else.
Version 2.2.6
Weitere Anpassungen der Benutzeroberfläche zur Verbesserung der Lesbarkeit und Benutzerfreundlichkeit.
- ein App-Icon wurde hinzugefügt
- der Search-Button wurde vergrößert und wird farblich hervorgehoben, sobald der Mauszeiger darüber schwebt (hover-Effekt)
- die Tab-Leiste wurde optisch überarbeitet, um die aktive Registerkarte besser hervorzuheben. Hier wurde ebenfalls ein hover-Effekt hinzugefügt. Die Schriftgröße der Tab-Titel wurde leicht erhöht
- für die Icons der Toolbar wurden Fallback-Icons hinzugefügt, falls die Standard-Icons des Betriebssystems nicht verfügbar sind.
Die Anpassungen mithilfe der Datei ui_styles.py verändern zum Teil die Vorgaben von Qt für die Darstellung der Benutzeroberfläche.
Die App funktioniert mit diesen Änderungen insbesondere unter KDE-Plasma weiterhin wie gewohnt. Auf anderen Betriebssystemen und Desktops kann es vorkommen, dass die Icons der Toolbar nicht korrekt angezeigt werden, vor allem, wenn das Betriebssystem unter dem Namen des Standard-Icons ein anderes Icon vorsieht. Sobald ein zum vorgegebenen Namen passendes Icon gefunden wird, kommt das vorgesehene Fallback-Icon nicht zum Einsatz.
Bei unseren Tests funktionierte die App gut unter LinuxMint, Fedora-KDE, MacOS und Windows 11. Die vom Nutzer gewählte System-Farbgebung wird respektiert und der Dark-Mode wird übernommen.
Um die App unter LinuxMint starten zu können, muss die Bibliothek libxcb-cursor0 auf dem Betriebssystem vorhanden sein. Sie installieren die Bibliothek im Terminal mit dem Befehl:
sudo apt update && sudo apt install libxcb-cursor0Unter Ubuntu 25.10 und Fedora-Workstation 43 gab es jedoch Probleme mit der Farbgebung, die App wurde im Hellen Modus dargestellt, wodurch zum Teil die Schrift nicht mehr lesbar war.
Um solche Probleme zu beheben, können Sie in der Datei ui_styles.py die Farbwerte für die verschiedenen Elemente der Benutzeroberfläche anpassen. Die Datei ist gut kommentiert, sodass man leicht erkennen kann, welche Farben für welche Elemente zuständig sind.
Version 2.2.7
Um die Probleme mit den Icons der Toolbar zu beheben, haben wir die Fallback-Icons als Standard gesetzt. Dadurch wird sichergestellt, dass die Toolbar-Icons immer korrekt angezeigt werden, unabhängig von der Verfügbarkeit der System-Icons. Verwendet werden Icons der Material-Design Icons Sammlung, die eine breite Palette von Symbolen bietet und gut mit verschiedenen Themes harmoniert. Die Icons wurden in das Projektverzeichnis unter assets/toolbar_icons/ hinzugefügt und werden nun standardmäßig geladen.
Das Fundament für Barrierefreiheit
Die App ermöglicht die vollständige Navigation per Tastatur durch alle Bereiche der Benutzeroberfläche. Beim Start der App steht der Fokus im Eingabefeld. Die Navigation mit der Tabulator-Taste folgt dem nativen Handlungsablauf: Suchbegriff eingeben – Suchkriterien wählen – den Button oder einfach nur „Enter“ betätigen, weiter zu den Tabs und dort mit den Pfeiltasten von Tab zu Tab wechseln.
Durch den Einsatz von semantischem HTML können Screenreader die Struktur der Suchergebnisse „verstehen“. Überschriften, Listen und Absätze werden als solche erkannt. Für blinde oder sehbehinderte Nutzer bedeutet dies, dass sie nicht in einer Datenwüste verloren gehen, sondern gezielt durch die Ergebnisse navigieren können.
Sehr wichtig ist es, dem Nutzer eine Zoom-Funktion für die Suchergebnisse zur Verfügung zu stellen und diese auch nicht zu limitieren. Was für manchen Entwickler fast riesig wirkt, kann für manchen Nutzer schon zur unüberwindlichen Hürde – zum Beispiel bei Zahlenreihen, ISBN – werden.
Mit schmalerer Strichdicke (font-weight), blasserer Farbgebung, oder Italic, kann man einen Text zwar ansprechend abwechslungsreich, aber eben nicht gut lesbar gestalten.
Überschriften müssen nicht riesig sein, sie kann man auch etwas kleiner noch gut lesen, nehmen aber ansonsten viel zu viel Platz im Fenster ein, der für den eigentlichen Inhalt benötigt würde.
Gern! Hier ein überarbeiteter Vorschlag, der klarer und stilistisch flüssiger klingt:
Ausblick
Wer sicherstellen möchte, dass die App auf möglichst vielen Betriebssystemen läuft, sollte auf hart codierte Style-Elemente, insbesondere bei der Farbgebung, verzichten. Dies entspricht hier der App in Version 2.2.5. Ansonsten ist das aber eine gute Möglichkeit, eine bessere Lesbarkeit der Benutzeroberfläche mit größeren und nicht zu blassen Schrifttypen zu erzielen.
Was uns beim Entwickeln der App besonders beeindruckt hat, ist die hervorragende Tastaturunterstützung von PySide6. Wir mussten lediglich als Vorgabe den Fokus auf das Eingabefeld setzen – die Navigationsreihenfolge passt sich anschließend automatisch an die Struktur der Benutzeroberfläche an.
Die Entwicklung der App endet nicht mit Version 2.2.7. Wir planen weitere Schritte, wie einen globalen App-Zoom, der die gesamte Oberfläche skaliert, um die Bedienung noch komfortabler zu gestalten. Auch die Implementierung weiterer APIs ist möglich.
Barrierefreiheit sollte kein „Nachgedanke“ sein. Wer sicherstellt, dass eine Software für Menschen mit Sehbeeinträchtigungen oder motorischen Einschränkungen funktioniert, baut am Ende eine bessere Software für uns alle. Gutes Design ist nicht das, was am modernsten aussieht, sondern das, was am wenigsten Barrieren im Kopf und auf dem Bildschirm hinterlässt.