muggle: alternatives GUI

Hallo,

ich will muggle ein anderes GUI verpassen.

Dazu musste ich erstmal die Datenbankabfrage neu schreiben, weil das einfacher war als den vorhandenen Code zu verwenden.

Das ist soweit fertig, nur noch nicht in muggle integriert, sondern 2 neue Klassen in einem Testprogramm.

Frage: GENRE1 und GENRE2. Bevor ich Funktionalität nachbilde, die ich nicht verstehe: Warum 2 Felder? Wie werden die verwendet?

Wenn es jemanden interessiert: Das neue GUI soll so aussehen:

Muggle - Suchschema

Genre
Künstler
Album
Titel

das ersetzt die jetzige Maske mit "Album nach Interpret" etc.

auf jeder Zeile kann man mit Rechts - und Linkstasten eine andere Sortierung wählen. Da kann der Programmierer sehr einfach alles implementieren, was die Datenbank zu bieten hat. Ich habe Jahr, Ranking, Sprache etc. vorgesehen. Die Anzahl Zeilen ist dynamisch, muggle soll wird Zeilen anhängen, um den Key eingermassen eindeutig zu machen (entweder Titel oder Album/Track muss vorkommen).

Bei OK kommt man in die Liste des obersten Suchbegriffs. Bei Anwahl von Muggle auch, unter Verwendung des zuletzt definierten Suchschemas. Per Untermenu kommt man in die Suchschema - Definition.

Playlisten: Nenne ich nur noch Liste und biete das auch als Sortierung an, die im Suchschema überall auftreten kann. Es gibt zu Beginn 10 vordefinierte Listen namens "Liste 1" bis Liste 10", kann man umbenennen. Wenn muggle merkt, dass nur noch wenige leer sind, legt es automatisch weitere an. In der Listenselektion erscheinen ja sowieso nur nichtleere, also stören ein paar zuviel nicht.

Dann denke ich, dass der gelbe Knopf, mit dem man zwischen Browser etc umschaltet, frei wird. Das schien mir ein Problem für Einsteiger zu sein.

Und Filter - die werden dann wohl nur noch sehr selten gebraucht. Die fehlen in meinen Klassen auch noch, aber einfach zu ergänzen, denke ich.

Was haltet Ihr davon?

Ab morgen bin ich für 6 Tage offline.

Wolfgang

Zitat

Original von LarsAC
Hi,

das klingt ja mal interessant... Verstehe das aber noch nicht so richtig, fürchte ich. Hast mal ein paar Screenshots?

Der code würde mich zu gegebener zeit auch mal interessieren, wollte an den Datenbankklassen eh nochmal rumschrauben.

Lars

Alles anzeigen

Screenshots habe ich noch nicht, nur mein Testprogramm. Darum meine ASCII - Darstellung, wie ich mir das mit dem Suchschema vorstelle. Das will ich dann nächste Woche, wenn ich wieder da bin, implementieren. Wohl auch erstmal als separaten Plugin, bis alles funktioniert (man will ja trotzdem noch Musik hören...), und dann kann man sich ja mal überlegen, ob und wie das in muggle integriert werden könnte. Z.B. das SQL - Interface fest, und das GUI umschaltbar. Dein GUI sollte mit dem neuen SQL - Inteface auch einfach zu machen sein. Nur eben - Filter fehlen noch.

Die Source hänge ich mal an, ist aber noch im Rohformat, wenig Kommentar, entspricht nicht den muggle - Codingregeln (Indent etc). Aber sie zeigt, wie ich mir das Interface zum Rest von muggle vorstelle. Einfach mal kompilieren und ausführen. Am einfachsten siehst Du Dir zuerst main() an.

Die SQL - Statements sind nur gegen meine Daten getestet. Da sie z.T. deutlich anders sind als Deine, würde mich schon interessieren, ob sie auch gegen andere Datenbanken korrekte Resultate erzeugen. Ich weiss nicht, ob und wie MySQL die Abfragen optimiert, also habe ich versucht, einfache Abfragen zu erzeugen. Hoffentlich trotzdem korrekte.

Wolfgang

Zitat

Original von LarsAC
Achso: die zwei Genres sind von GD übernommen. Ich nutze derzeit nur das erste. Man könnte halt Pop im ersten und 80s im zweiten haben oder so.

Dazu habe ich mir nun beim Quittengelieren (25kg Gelee :]) überlegt: Auf dem OSD erscheint Pop/80s, also nur ein Feld. D.h. meine SQL - Abfragen liefern dem muggle wie immer 2 Werte pro Zeile - also "Pop/80s" und "id1/id2". Die Datenbank - Klassen sollten das hin- und zurückübersetzen. Auf den Hinweg wäre das z.B.

select concat(genre1.genre,'/',genre2.genre), concat(genre1.id,'/',genre2.id) from genre as genre1, genre as genre2 where blabla ;

Der Rückweg ist noch einfacher (ohne SQL), da übergibt muggle ja einfach die richtigen Werte für id1/id2, die ich für die nächste Selektion verwende.

Mit dem Hintergedanken, es möglichst einfach zu machen, das GUI umzubauen.
Also Sonderfälle, die sich aus den Datenstrukturen ergeben (bisher Liste(Playlist) und Genre) in den Datenbank - Klassen zu kapseln.

Hört sich das sinnvoll an?

Wolfgang

Zitat

Original von wolfgang61
Auf dem OSD erscheint Pop/80s, also nur ein Feld.
...

Hört sich das sinnvoll an?

um mir selber zu antworten: NEIN, da haben mich wohl die Quitten zu sehr umnebelt. Sobald man die NULL Werte mit einbezieht, wird das endgültig zu komplex.

Mit meinem GUI geht das aber sehr einfach zu lösen: Ich behandle genre1 und genre2 als völlig unabhängige Sortierfelder und habe null zusätzlichen Programmieraufwand. Der Anwender kann sich dann z.B. so ein Suchschema zusammenklicken:

Genre 1 (per Pfeiltasten auf dieser Zeile rechts/links einstellen)
Genre 2 (dito auf allen Zeilen im Suchschema)
Artist
Album
Track

Oder in Deiner OSD - Sprache "Album nach Genre1, Genre2 und Artist"

nach OK bekommt er dann erstmal die Liste aller Genre 1. Nach OK in dieser Liste alle dazu existierenden Genre 2, nach weiterem OK alle passenden Artisten etc.

Und wenn jemand genre2 nicht nutzt, lässt er es eben im Suchschema weg:

Genre 1
Artist
Album
Track

Nochmal zur Definition vom Suchschema: Genau so, wie man im OSD - Setup die Sprache mit den Pfeiltasten rechts/links wählt, soll man die Sortierung wählen können. Auf der ersten Zeile z.B. kann man damit wählen zwischen Genre1, Genre2, Artist, Album etc. Auf der zweiten Zeile werden nur diejenigen angeboten, zu denen es unter Berücksichtigung von Zeile 1 Werte gibt, und der Wert der ersten Zeile wird natürlich auch nicht angeboten. Entsprechend für die Folgezeilen.

Wolfgang

Zitat

Original von goll
Hi,

Ein ganz wichtiger Grund kommt bei GiantDisc hinzu. Da werden Genres ja hierarchisch verwaltet. Und wenn ich eine generelle Suche nach Jazz Stücken mache, dann will ich auch, dass die Soul-Jazz Stücke mit einbezogen werden. Diese Stücke sollen aber auch unter der R&B/Soul Kategorie zu finden sein. Dies lässt sich am besten bewerkstelligen, indem ein Stück mehr als einer Kategorie angehören kann.

Ich müsste also, wenn ich nach Tracks mit Genre eaa suche, das so tun:
select id from tracks where genre1='eaa' or genre2='eaa';

Richtig?

Und die Hierarchien fehlen in muggle auch noch, aber ich sehe nun den Sinn.
Das will ich noch so einbauen.

Vor kurzem hat jemand eine überarbeitete Tabelle für das Mapping von Deinen genres zu id3 - Tags gepostet. Hast Du da auch etwas aktuelleres? Wie ist das mit id3v2?

Natürlich sollen nur Genres gezeigt werden, zu denen es auch Tracks gibt. Das freq - Feld würde da nichts nützen, wenn z.B. erst nach Sprache und dann nach Genre gesucht wird. Insofern vermute ich, das freq uns gar nichts hilft. Es wird auch von muggle bisher nicht nachgeführt. genre.freq sagt mir ja nicht, wieviele italienische Soul - Stücke es gibt.

Wolfgang

Zitat

Original von LarsAC

Ich dachte immer, das wäre generell festgelegt, und nicht nur für GD?
Lars

Die Werte für das Feld genre.id3genre schon. Aber nicht die für Feld genre.id, dieses Feld hat Rolf wohl selber definiert. Mit seiner eigenen Hierarchie. Also braucht es ein Mapping, das kommt für muggle aus scripts/genres.txt
Siehe http://www.giantdisc.org/man/man8.php#table_genre

Am 9.1. im Thread zu muggle-0.1.0 hatte hulk dazu eine Erweiterung gepostet mit diversen neuen Mappings. Ich denke mir halt, dass es sinnvoll wäre, diese Liste zentral zu führen. Im Moment ist sie wohl für GiantDisc und muggle identisch.

Wolfgang