Mir ist nicht abschließend klar, was nun genau gefordert ist. Was muss ein
player denn (visuell) groß können? Eine
playlist anzeigen können wäre schon gut. Diese Anzeige soll außerdem drag & drop (XDND) verstehen. Mehr ist nicht gefragt, das Titel-Display ist ja üblicherweise ohnehin als OSD realisiert (oder liegt auf dem Desktop, oder im gkrellm, oder Firefox, oder...); ähnliches gilt für die Bedienung (Multimediatasten, Firefox, gkrellm, was Ihr wollt). Da gibt es außer einer Liste also gar nicht viel anzuzeigen. Wenn man meint, unbedingt statt eines
players eine monolithische Anwendung mit Identitätskrise, die gleichzeitig auch noch
file-manager, Datenbank und
AudioScrobbler sein will, bauen zu müssen, von mir aus. Aber diese ganzen Wunderoptionen sind (hoffentlich) ohnehin nicht permanent sichtbar (und dürfen daher
toolkitten, wie's ihnen beliebt) -- selbst amaroK unterstützt ja für den "sichtbaren Teil"
skins -- und selbst xmms unterstützt in allen transienten Anzeigen
widgets, nämlich GTK+.
Mehr noch, der Anspruch, daß gleichartige
widgets gleich aussehen mögen, ist durchaus nicht in Stein gehauen. Es erhöht den Wiedererkennungswert des jeweiligen
widgets statt den der Anwendung, was durchaus kein universeller Wert ist. Wichtiger aber ist, daß es die Augen ermüdet, wenn sich in unterschiedlichen Fenstern auch unterschiedliche Dinge befinden: bei einem
terminal (helle Schrift auf schwarzem Grund) kann es nicht sinnvoll sein, gleißend weiße widgets um die schwarze Fläche zu gruppieren; ein
web-browser (üblicherweise dunkle Schrift auf hellem, oft weißem Grund) hingegen verlangt eher nach hellen
widgets.
Und um schließlich die Schreibtischmetapher zu bemühen: wenn alle Dokumente auf meinem Schreibtisch sich in Briefpapier/CI und Papierfarbe gleichen, wird es schwieriger, ein Dokument wieder zu finden. Ungefähr jeder
usability guide der Welt empfiehlt Farbkodierung (
"rot Fehler, grün OK"
,
"Finland rot, Ägypten weiß"
, ...) -- dieses Prinzip lässt sich durchaus auch auf Anwendungsklassen anwenden.
Dieses letztgenannte Problem lässt sich zwar ggf. auch anders angehen (engage, kasbar, komposé, ...). Dennoch darf eine playlist, soll sie ständig "offen" sein, nicht eine gleißende Oase im Dunkel eines von Terminals oder Editoren bevölkeren Bildschirms sein; ebenso wenig soll sie neben Browsern unlesbar werden oder den Farbeindruck eines im GIMP bearbeiteten Bilds verfälschen. Eine Applikation die man regelmäßig, aber jeweils nur kurz benutzt, darf daher sehr gern mit
screen estate geizen und kleine Schriften benutzen; sinnvollerweise stellt sie ihren Inhalt in Grautönen dar.
player die ein Standard-
toolkit benutzen sind also nur unter bestimmten Umständen sinnvoll -- es muß einerseits überhaupt
widgets darzustellen geben, andererseits ist ein durchgängiges
theme angezeigt, was ja bedingt, daß man u.U. nicht die geeignetesten Anwendungen benutzt, sondern nur die geeignetesten KDE-Anwendungen (oder GNOME, oder ...). Voraussetzung für letzteres scheint zudem zu sein, daß man "invertierte Terminals" mit dunkler Schrift auf hellem Grund nutzt. Viele Bedingungen also.
Hier wären klar
themes gefragt, bei denen sich das
colour scheme per Applikation einstellen lässt -- das
theme gibt z.B. die Form eines
button vor sowie daß herinnen ein vertikaler Verlauf wohnen soll; die Farben hängen dann von der Applikation(sklasse) ab -- "weiß nach hellgrau" für den Web-browser, "dunkelgrau nach schwarz" für das Terminal. Globale Farbschemata unterstützt KDE bereits,
legacy themes könnten also ohne Änderung weiter benutzt werden.
