?
Artchi schrieb:
Beispiel einer nicht-nativen-GUI, die eben doch nicht native sein kann? gtk. Wenn ich in GIMP eine Combobox aufmachen will, muß ich lange die Maus gedrückt halten, damit sie auf bleibt. Hem... also das Feel ist nicht nativ und verwirrend für einen Windows-User.
Also bei mir nicht (Linux, GTK+ 2.8.20, GIMP 2.2.13).
Artchi schrieb:
Aber ich finde es persönlich doch schon besser, wenn die Standard-GUI-Elemente nativ sind. Es geht mir dabei hauptsächlich um das Feeling! Wenn ein Button vielleicht eine Schattierung hat, an drei Ecken eckig und vierte Ecke rund ist... stört es nicht. Aber es stört, wenn ich ihn anders benutzen muß oder er sich anders verhält.
Das ist die eine Seite. Wenn du nur für Windows programmierst, ist das ja okay. Allerdings forderst du quasi, dass für jede Plattform eine neue GUI geschrieben werden sollte. Denn irgendwo sind immer die Unterschiede, und wenn es darum geht, dass die Icons einen bestimmten Zeichenstiel haben. Wenn du wirklich "native"-Anwendungen haben willst, dann kannst du nichts anderes machen, als die Anwendung 100% auf eine Plattform zuzuschneiden.
Als Beispiel wäre da FileZilla zu nennen. Das funktioniert super unter Windows, ist aber für mich unter Linux nicht benutzbar, obwohl es unter Linux GTK+ (wxWidgets) verwendet. Der Grund ist einfach der, dass unter Windows die Standardschriftart kleiner ist. Die GUI von Filezilla ist daran ausgerichtet, mit dem Erfolg, dass ich unter Linux in sämtliche Richtungen scrollen muss. Die GUI ist, meinem empfinden nach, außerdem einfach nur hässlich (unter Linux). Und das, obwohl fast sämtliche meiner Anwendungen GTK+ Anwendungen sind, so sind wxWidgets-Anwendungen auf meinem Desktop totale Fremdkörper.
Das Feel erreicht man ja nicht einfach dadurch, indem man "native"-Controls verwendet. Es gibt auch noch gewisse Gepflogenheiten, die die Nutzer bei einer Desktopumgebung gewohnt sind.
Ich fände eine allgemeine Ausrichtung an Benutzbarkeit wünschensweter, als ein Pseudo-Nativer-Look.
Artchi schrieb:
Extra-GUI-Elemente (die nativ nicht vorhanden oder zu realisieren sind), können ja trotzdem extra implementiert werden. Mit dem richtigen Klassendesign ist das auch kein Ding.
Das ist ja genau der Punkt. Es gibt Gründe, warum es ein bestimmtes Control auf einer Plattform nicht gibt. Aber es gibt dafür sicherlich genügend alternativen, die die Nutzer dieser Plattform gewohnt sind. Implementiert man sein eigenes Control, damit die Schnittstellen stimmen, so geht man wieder gegen die Gewohnheit der Benutzer. Nativ und Plattform unabhängig ist einfach ein Widerspruch. Dafür gibt es dann doch zu große Unterschiede in den Konzepten an sich.
Man sollte sich wirklich besser an allgemeiner Benutzbarkeit orientieren, denn die Praxis zeigt eigentlich, dass (selbst bei nativen Toolkits) man sich eigentlich an einer Plattform orientiert.