it-swarm.com.de

Warum ist es schwierig, ein Java Programm 'nativ erscheinen zu lassen)?

Die meisten Java -Anwendungen sehen nicht so aus wie C/C++ - Anwendungen. Swing wurde möglicherweise absichtlich so entworfen, dass es ein unverwechselbares Aussehen hat, aber basierend auf dem, was ich gelesen habe, hat SWT es beispielsweise versucht "native aussehen", und nicht vollständig erfolgreich.

Meine Frage ist:

Warum fällt es den Entwicklern der Sprache Java) schwer, ein GUI-System zu entwerfen, das gena das Aussehen nativer GUIs kopiert? Was ist bei nativen GUIs anders? Es geht nur darum, Schaltflächen zu entwerfen, die wie "native" Schaltflächen aussehen. Oder geht es tiefer?

99
user3150201

Geht es nicht nur darum, Schaltflächen zu entwerfen, die wie "native" Schaltflächen aussehen?

Na ja, irgendwie für Knöpfe. Aber das könnte schwieriger sein, als Sie sich vorstellen. Heutzutage sind die Grafiken, die zur Darstellung von GUI-Komponenten verwendet werden, nicht so einfach wie zufällige Bitmaps, die gestreckt werden (da diese überhaupt nicht sehr gut skaliert werden) - es handelt sich häufig um vektorbasierte Grafiken, in die viele Eckfälle programmiert sind ( Wenn die Schaltfläche den Bildschirmrand erreicht, sieht sie beispielsweise möglicherweise etwas anders aus.) Und natürlich benötigen Sie unterschiedliche Grafiken, wenn Sie auf eine Schaltfläche klicken. Aus urheberrechtlichen Gründen können Entwickler diese vorhandenen Grafiken oft nicht direkt verwenden, sondern müssen neu erstellt werden - und obwohl sie größtenteils gute Arbeit leisten, werden angesichts der Vielzahl an grafischen Komponenten zwangsläufig einige Dinge übersehen. Dies ist viel weniger schwerwiegend als früher - wenn ich heutzutage das Standard-Erscheinungsbild der Plattform in Swing einstelle, bemerke ich sehr wenig, was seltsam aussieht.

Ich sage alles oben Genannte basierend auf Swing, einem leichten, nicht nativen GUI-Toolkit. Sie erwähnen ausdrücklich, dass SWT nicht nativ aussieht, was etwas seltsam ist, weil SWT nativ ist. Es ist ein Toolkit, das JNI verwendet, um native Komponenten aufzurufen. Wenn also etwas dort nicht richtig aussieht, ist es nicht wird wegen des Aussehens und der Haptik sein.

57
berry120

Es gibt buchstäblich ein halbes Dutzend Toolkits, die auf einem System als "nativ" angesehen werden können. Einige davon haben ziemlich einzigartige Konzepte oder Funktionen, und das Replizieren in einem plattformübergreifenden Toolkit ist mühsam. Das Erscheinungsbild einer Anwendung wird nicht nur von einem „Skin“ bestimmt, sondern auch vom Layout und dessen Verhalten. Einige Überlegungen:

  • Auf welche Seite gehört in einem Dialog die Schaltfläche „OK“ - links oder rechts? Fairerweise erstellen wir für jedes System einen eigenen Dialog.
  • Wie markieren wir die Standardschaltfläche auf einem Bildschirm? Farbtönung, fette Schrift, Vergrößerung der Schaltfläche? Fair genug, lassen Sie uns das in ein Stylesheet einfügen.
  • Unter Windows ist das Ribbon-Konzept eher nativ. Wie würde dies auf einen Mac übersetzt, auf dem das Menüband nicht üblich ist? Vergessen wir das pixelgenaue Layout und stellen für jedes System eine andere Symbolleistenimplementierung bereit.
  • Ist die Menüleiste Teil des Fensters (Windows, optional KDE) oder befindet sie sich oben auf dem Bildschirm (Mac, Unity)? Lassen Sie uns fairerweise für jedes System eine andere Implementierung schreiben, da wir das pixelgenaue Layout bereits weggeworfen haben
  • Wie werden die Schriftarten gerendert? So knackig wie möglich oder glatt und antialiasiert? Und welche Schriftart sollte verwendet werden? Beachten Sie, dass unterschiedliche Schriftarten unterschiedliche Metriken haben, sodass der gleiche Absatz, der auf dieselbe Breite gerendert wird, je nach Schriftart eine unterschiedliche Anzahl von Zeilen haben kann.
  • Ist der Hintergrund eines Fensters eine einzelne Farbe, ein Bild oder ein Farbverlauf? Lassen Sie uns das auch einfach in ein Stylesheet einfügen.
  • Wie sehen Bildlaufleisten aus? Wo sind die Tasten - wenn sie welche haben? Wie breit sind sie oder werden sie nur angezeigt, wenn sich der Zeiger in eine bestimmte Region bewegt?
  • Wie integrieren wir andere Farbschemata?
  • Was soll schleppbar sein? Wo werden Kontextmenüs erwartet?

Diese Probleme können nicht durch ein einfaches Stylesheet gelöst werden, wenn sie das Verhalten oder das allgemeine Layout der Anwendung berühren. Die einzige wirkliche Lösung besteht darin, die Anwendung für jedes System neu zu schreiben (wobei die plattformübergreifenden Vorteile von Java ignoriert werden). Die einzig realistische Lösung besteht darin, das pixelgenaue Layout zu vergessen und auf eine gemeinsame Oberfläche zu schreiben, die über systemspezifische Toolkits abstrahiert. Die Lösung von Swing besteht darin, verschiedene Systeme zu emulieren, was spektakulär versagt.

Und dann gibt es plattformübergreifende Konsistenz, die Idee, dass Ihre App auf allen Systemen genau gleich aussehen kann (oft von Spielen ausgewählt, wo dies das Eintauchen erhöht). Bei Desktop-Anwendungen ist dies nur ärgerlich und bricht die Erwartungen der Benutzer.

71
amon

Ja, es geht tiefer.

Das Erstellen einer Schaltfläche, die wie eine Windows- oder OS X-Schaltfläche aussieht, ist einfach, wenn Sie nur diese Schaltfläche erstellen. Die Schaltfläche muss sich jedoch wie die Originalschaltfläche "verhalten", was möglicherweise nicht einfach ist: Möglicherweise ist in einer Version mehr Platz verfügbar, in der anderen jedoch nicht. Vielleicht passt die Farbe besser zu Ihrem Design in der Windows-Version usw.

Dies ist besonders wichtig, wenn Sie über eine vollständige Benutzeroberfläche verfügen: Ein OS X-Programm präsentiert seinen Inhalt anders als ein Windows-Programm. Dies ist so gut wie unmöglich in einer GUI zu erfassen - Sie würden zwei GUIs benötigen, aber nicht viele Anwendungen machen so viel Aufhebens. Stattdessen zielen sie darauf ab, "auf den meisten Systemen gut auszusehen" - dies sieht immer noch etwas fremd aus, ist aber verwendbar und viel einfacher zu entwickeln.

13
Christian Sauer

Es ist nicht schwer, eine Schaltfläche zu erstellen, die einer OSX-Schaltfläche, einer Windows-Schaltfläche oder einem anderen Toolkit ähnelt. Die UI-Richtlinien für die meisten Umgebungen sind jedoch nicht so einfach wie die Grundlagen von "So sieht eine Schaltfläche aus". Es gibt viele subtilere Unterschiede, vom Abstand zwischen den UI-Elementen über die Reihenfolge, in der bestimmte bekannte Aktionen in einer Liste angezeigt werden sollen, bis zur genauen Position des Dialogfelds "Einstellungen/Optionen" im Menüsystem. Man kann die häufigsten Fälle für sehr einfache Benutzeroberflächen automatisieren, aber viele, wenn nicht die meisten UI-Aufgaben erfordern eine viel feinere Berührung.

SWT hat versucht, dies bis zu einem gewissen Grad zu automatisieren, und es ist wieder einmal richtig für einfache UI-Aufgaben. Es gibt jedoch keine einheitliche Lösung. Wenn die Benutzeroberflächen komplexer werden, fallen die grundlegenden Methoden auseinander. Es ist im Allgemeinen möglich, es wieder mit der sorgfältigen manuellen UI-Arbeit in Einklang zu bringen, aber dies ist nicht etwas, was die meisten Programmierer für alle Plattformen tun können oder wollen.

Swings Ansatz bestand darin, native Toolkits nach Möglichkeit zu vermeiden. Es ist nicht nativ und versucht es auch nicht zu sein. Stattdessen versucht es, etwas zu erstellen, das (fast) gleich aussieht, egal wo es ausgeführt wird. Anstatt (vergeblich) zu versuchen, alle zufrieden zu stellen, versuchte es, sich selbst zu gefallen, und obwohl dies erfolgreich war, kann man sich fragen, wie effektiv das Ergebnis für die breitere Benutzergemeinschaft ist.

9
The Spooniest

Es gibt einen Kompromiss zwischen der Erwartung, dass Ihre Anwendung auf jedem System so natürlich wie möglich aussieht, und der Erwartung, dass Ihre Anwendung auf jedem System auf die gleiche Weise funktioniert. Es gibt keine "richtige" Wahl.

Selbst wenn Sie sich für die "natürlich aussehende" Seite entscheiden, möchten Sie die Benutzer Ihres Grafik-Toolkits möglicherweise vor "Verbesserungen" der zugrunde liegenden nativen Komponenten und der API schützen, die ihre Anwendung möglicherweise unerwartet beschädigen.

Aus diesem Grund bevorzugen einige Entwickler von GUI-Toolkits die Bereitstellung eigener Komponenten, die native Komponenten imitieren, jedoch ihre eigene Implementierung. Auf der anderen Seite ist die Entwicklung eines funktional vollständigen GUI-Toolkits ein erheblicher Aufwand, und wirtschaftliche Überlegungen können dazu führen, dass einige Kanten gekürzt werden.

Beachten Sie, dass dieses Problem nicht Java spezifisch) ist, sondern bei jedem Unternehmen auftritt, das plattformunabhängige Toolkits herstellt.

7
Nicola Musatti

Es ist alles auf die Geschichte zurückzuführen.

Sun wünschte, dass alle Java Software auf allen Computern gleich funktioniert.

Damit Software "nativ" erscheint, muss sie genauso funktionieren wie andere Software auf dem jeweiligen Betriebssystem.

Sun hat alles in seiner Macht stehende getan, um es schwierig zu machen, Java Software zu schreiben, die in ein Betriebssystem integriert ist, da bei jeder Integration in ein Betriebssystem die Software auf jedem Betriebssystem anders funktioniert.

Heutzutage kümmern sich nur sehr wenige Java Programmierer um etwas anderes als um Webserver-basierte Software.

Sun hat Java auf dem Desktop getötet, indem alle Programmierer, die die Microsoft Java -basierten Systeme verwendeten, in den Hintergrund gedrängt wurden, sodass jeder Programmierer, der sich in den frühen Tagen für Java entschieden hat, schlecht aussieht.

Jeder, der Desktop-Software schreibt, die sich für "native erscheinen" interessiert, hat vor langer Zeit gelernt, Java nicht zu verwenden, und seine Ansichten werden jedes Mal verstärkt, wenn er Oracle-Software verwendet.

Daher besteht heutzutage keine Nachfrage nach "nativ erscheinen" auf Desktop-Software von Java Programmierern.

4
Ian

Was Sie denken, ist native, dass native Apps ihr eigenes Ding machen, während Toolkits wie SWT den veröffentlichten Standards für die Benutzeroberfläche dieses Betriebssystems folgen. Das Problem ist, dass niemand Apps nach diesen Standards erstellt. Wenn Sie also eine Java App) starten, scheint diese nicht nativ zu sein. Beispielsweise sind fast alle Microsoft-Projekte (Office, Outlook, usw.) können mit Windows-Standardsteuerelementen nicht visuell reproduziert werden.

Es wird noch schlimmer, wenn sowohl Microsoft als auch Apple) dynamische Betriebssystemfunktionen zu ihren Betriebssystemplattformen hinzufügen. Entwickler können ihre Apps ähnlich wie Webdesigns Stile für Websites erstellen.

Java auf der Android Plattform folgt diesem Pfad. Erstellen der UI-Elemente für Android in XML mit skinnbaren Stilen definiert.

Java war als Desktop-Plattform noch nie sehr beliebt. Infolgedessen werden diese Änderungen in der Branche nicht auf die Desktop-Laufzeiten übertragen. Es gibt einfach nicht genug Entwickler, die bereit sind, Zeit für die Behebung des Problems aufzuwenden.

3
Reactgular