Seite 1 von 1

Probleme bei Mimetype-basiertem Icon-Lookup

Verfasst: Samstag 11. Februar 2012, 16:32
von snafu
Wie würdet ihr vorgehen, wenn ihr euch ein passendes Theme-Icon raussuchen wollt, dessen Benennung nicht exakt dem Mimetype einer Datei entspricht? Beispiel:

Code: Alles auswählen

>>> import mimetypes
>>> mimetypes.guess_type('__init__.py')[0].replace('/', '-')
'text-x-python'
Eine Suche nach diesem Namen zeigt nun, dass es `text-x-python` offenbar nicht in jedem Icon-Theme gibt. Insbesondere das Theme `gnome` hat bei mir nur `gnome-mime-text-x-python` als einzige infrage kommende Icondatei für den Namen. Ich brauche also eine Art unscharfes Matching dafür.

Das Problem ist, dass ich den Algo zum Auffinden eines konkreten Dateinamens für einen Iconnamen nicht selbst geschrieben habe. Ich lasse dies durch `QIcon.fromTheme()` bzw für den Fall, dass Qt nicht fündig wird, alternativ von PyXDG mittels `xdg.IconTheme.getIconPath()` (welcher dann an `QIcon` übergeben wird) erledigen. Die geben beide vor, die "XDG Icon Theme Specification" zu implementieren, welche bekanntlich mindestens mit den 4 großen DEs (Gnome, KDE, XFCE, LXDE) harmonieren müsste - offenbar tun sie es aber trotzdem auf unterschiedliche Weise (daher die Fallback-Lösung).

Worum es mir aber jetzt konkret geht: Gibt es irgendeine Spezifikation, die o.g. Abweichungen bei der Benennung behandelt oder muss ich Trial-And-Error mäßig vorgehen (also z.B. `gnome-mime-` vorne dranhängen, wenn beim ersten Versuch nichts gefunden wird)? Die Lösung klingt für mich nicht gerade sauber, aber irgendwie fällt mir auch nichts besseres ein. :(

Re: Probleme bei Mimetype-basiertem Icon-Lookup

Verfasst: Samstag 11. Februar 2012, 17:20
von lunar
@snafu: Du musst Dich an die XDG Shared Mime Info Spec halten, wenn Du Mime-Typen mit anderen XDG-Spezifikationen verwenden willst, und den Mime-Typen mit "xdg-mime" (oder etwas vergleichbarem) abfragen. "mimetypes" ist von der Mime-Konfiguration der Desktop-Umgebungen vollkommen unabhängig und kann für eine bestimmte Datei ganz andere Mime-Typen zurückgeben als die Desktop-Umgebung.

Ferner sind Symbole für bestimmte Mime-Typen nicht weiter standardisiert. Jenseits der in der Icon Naming Spec aufgeführten Symbole für Mime-Typen steht es jedem Theme frei, bestimmte Symbole auszuliefern oder nicht. Du kannst Dich mithin nicht darauf verlassen, dass es ein Symbol für Python-Dateien gibt. Wenn Du keines findest, dann musst Du auf das Standardsymbol für diese Mime-Gruppe zurückgreifen (beispielsweise "text-x-generic" für alle "text/*" Typen).

Re: Probleme bei Mimetype-basiertem Icon-Lookup

Verfasst: Montag 13. Februar 2012, 13:59
von snafu
lunar hat geschrieben:@snafu: Du musst Dich an die XDG Shared Mime Info Spec halten, wenn Du Mime-Typen mit anderen XDG-Spezifikationen verwenden willst, und den Mime-Typen mit "xdg-mime" (oder etwas vergleichbarem) abfragen. "mimetypes" ist von der Mime-Konfiguration der Desktop-Umgebungen vollkommen unabhängig und kann für eine bestimmte Datei ganz andere Mime-Typen zurückgeben als die Desktop-Umgebung.
Jepp. Der Vollständigkeit halber:

Code: Alles auswählen

$ xdg-mime query filetype __init__.py
text/x-python
Eine vergleichbare Funktion aus PyXDG ist offenbar xdg.Mime.get_type().
lunar hat geschrieben:Ferner sind Symbole für bestimmte Mime-Typen nicht weiter standardisiert. Jenseits der in der Icon Naming Spec aufgeführten Symbole für Mime-Typen steht es jedem Theme frei, bestimmte Symbole auszuliefern oder nicht. Du kannst Dich mithin nicht darauf verlassen, dass es ein Symbol für Python-Dateien gibt. Wenn Du keines findest, dann musst Du auf das Standardsymbol für diese Mime-Gruppe zurückgreifen (beispielsweise "text-x-generic" für alle "text/*" Typen).
Heißt im Klartext also, dass ich die Finger von irgendwelchen "Anhängsel-Versuchen" lassen sollte und bei nicht auffindbarem Icon für einen Mimetype einfach den allgemeineren Namen für den Dateitypen liefern sollte, richtig? Ist ja prinzipiell nicht so schwierig zu implementieren, da der "Obertyp" immer links vom Slash beim Mimetype steht, wie du ja auch schon beispielhaft genannt hattest. Das kriegt man wohl hin... :)