Warum ist es schwierig, ein Java-Programm "nativ" erscheinen zu lassen?

98

Die meisten Java-Anwendungen sehen anders aus als C / C ++ - Anwendungen. Swing wurde mit Absicht entwickelt, um ein unverwechselbares Erscheinungsbild zu erhalten, aber SWT hat zum Beispiel versucht, wie ich gelesen habe, "nativ" auszusehen, was jedoch nicht vollständig gelingt.

Meine Frage ist:

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

user3150201
quelle
31
weil swing seine eigenen GUI-Komponenten schreibt, die versuchen, die native zu imitieren, anstatt eine Bindung zu den tatsächlichen nativen Komponenten zu erstellen, in der Idee der Portabilität
Ratschenfreak
5
Ich bin kein Experte in diesem Thema, aber ich denke, es ist nur eine Frage des Aufwands, den GUI-Toolkit-Anbieter investieren, um alle wichtigen Details richtig zu machen. Siehe zum Beispiel das C ++ - Framework "Qt" und diese SO-Frage: stackoverflow.com/questions/7298441/…
Doc Brown
4
Es gibt viele, viele Details, um die man sich kümmern muss. Die Art und Weise, wie die automatische Vervollständigung in einem Dialogfeld zum Öffnen von Dateien funktioniert, ist beispielsweise ein Punkt, an dem eine Java-Anwendung mit systemeigenem Erscheinungsbild ausfällt.
CodesInChaos
4
Swing hat ein "natives Lookalike" -Look-and-Feel, das Sie anstelle der Standardeinstellung einstecken können. Außerdem hat Java zuerst versucht, verfügbares natives Material mit AWT zu verwenden, aber es hat aufgrund der inhärenten Unterschiede zwischen den Plattformen nicht sehr gut funktioniert, AFAIK. Deshalb haben sie Swing entwickelt, damit eine Java-App überall gleich funktioniert.
Marczellm
5
Übersehen Sie JavaFX nicht. Es handelt sich um den SWING-Ersatz und ist ab Java 8 standardmäßig im JDK / JRE enthalten. Es ist viel moderner als SWING und AWT und sieht auf nahezu allen Plattformen wesentlich nativer aus (es hängt viel mit dem nativen UI-Toolkit zusammen) Plattform). Nachdem dies gesagt wurde, müssen Sie, wie andere bereits erwähnt haben, einige Arbeiten ausführen, um eine genau native aussehende Anwendung aus einer "One-Size-Fits-All" -Sprache wie Java herauszuholen. Die Benutzeroberfläche von Java war / waren / sind so konzipiert, dass sie "für alle Plattformen am besten geeignet" ist.
SnakeDoc

Antworten:

56

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

Na ja, 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 mehr so ​​einfach wie zufällige Bitmaps, die gestreckt werden (da diese überhaupt nicht gut skaliert werden). Wenn die Schaltfläche den Rand des Bildschirms erreicht, sieht sie beispielsweise möglicherweise etwas anders aus.) Wenn Sie auf eine Schaltfläche klicken, benötigen Sie natürlich andere Grafiken. Aus urheberrechtlichen Gründen können Entwickler diese vorhandenen Grafiken oft nicht direkt verwenden, sondern müssen neu erstellt werden - und obwohl sie zum größten Teil gute Arbeit leisten, werden aufgrund der Vielzahl grafischer Komponenten zwangsläufig einige Dinge übersehen.

Ich sage das alles basierend auf Swing, das natürlich ein leichtes, nicht-natives GUI-Toolkit ist. Sie erwähnen ausdrücklich, dass SWT nicht nativ aussieht, was etwas seltsam ist, da SWT nativ ist. Es handelt sich um ein Toolkit, das JNI verwendet, um native Komponenten aufzurufen. Wenn also etwas dort nicht richtig aussieht, liegt es nicht am Erscheinungsbild.

berry120
quelle
1
Vielen Dank. Was bedeutet "leicht" genau? Und was heißt eigentlich "heimisch"? Ich gehe davon aus, dass es etwas bedeutet, das Ressourcen aus dem Betriebssystem des Computers verwendet oder direkt damit interagiert. Ist das wahr?
user3150201
1
@ user3150201 Sicher, das zugrunde liegende Betriebssystem verfügt über eine festgelegte Anzahl von Schaltflächen und Widgets, die nativ platziert werden können, aber diese Schaltflächen unterscheiden sich offensichtlich zwischen Betriebssystemen und Plattformen - dies sind die schwergewichtigen nativen Komponenten. Leichte Komponenten sind nicht die Komponenten, die vom Betriebssystem vorgegeben werden. Sie werden von Java (in diesem Fall) so gezeichnet, dass sie wie GUI-Komponenten aussehen und sich so verhalten. Sie können also so aussehen, wie Sie möchten, wenn Sie die Arbeit aufnehmen (aber Sie müssen emulieren) Das Aussehen und
Verhalten
14
Die Platzierung der Schaltflächen, die exakten Größen und die bevorzugten GUI-Stile variieren je nach Plattform, und es ist arbeitsaufwendig, Java zu veranlassen, sie nachzuahmen. Swing kann Ihnen die native Schaltfläche geben, aber wenn es 10 Pixel zu groß ist, wird der Benutzer immer noch denken, dass etwas nicht stimmt. Apple hat die Richtlinien für die Benutzeroberfläche und Microsoft die Richtlinien für die Benutzeroberfläche , damit Sie das richtige native Erscheinungsbild erhalten. Sie müssen die Benutzeroberfläche zwischen den Plattformen etwas ändern.
Michael Shopsin
4
JavaFX erscheint wesentlich "nativer" als SWING und AWT. Es hat native transparente Fenster usw. Viel moderner aussehende Out-of-the-Box.
SnakeDoc
2
@SnakeDoc Es scheint zwar moderner zu sein, aber ich würde nicht sagen, dass es "nativ" aussieht - es verwendet mit Sicherheit nicht die zugrunde liegenden GUI-Komponenten der Plattform, es ist alles in CSS gehäutet.
Berry120
71

Es gibt buchstäblich ein halbes Dutzend Toolkits, die auf manchen Systemen als „nativ“ angesehen werden könnten. Einige von ihnen haben ziemlich einzigartige Konzepte oder Fähigkeiten, und ihre Replikation in einem plattformübergreifenden Toolkit ist mühsam. Das Look & Feel einer Anwendung wird nicht nur von einem „Skin“ bestimmt, sondern auch vom Layout und dessen Verhalten. Einige Überlegungen:

  • Zu welcher Seite gehört in einem Dialog die Schaltfläche „OK“ - links oder rechts? Fair genug, lassen Sie uns für jedes System einen eigenen Dialog erstellen.
  • 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 schreiben.
  • Unter Windows ist das Konzept der Multifunktionsleiste eher nativ. Wie würde dies auf einen Mac übertragen, bei 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)? Fairerweise, lassen Sie uns für jedes System eine andere Implementierung schreiben, da wir bereits pixelgenaues Layout weggeworfen haben
  • Wie werden die Schriften gerendert? Möglichst knackig oder geschmeidig und antialias? Und welche Schriftart soll verwendet werden? Beachten Sie, dass unterschiedliche Schriftarten unterschiedliche Metriken haben, sodass der gleiche Absatz, der mit derselben Breite gerendert wird, je nach Schriftart eine unterschiedliche Anzahl von Zeilen aufweisen kann.
  • Ist der Hintergrund eines Fensters eine einzelne Farbe, ein Bild oder ein Farbverlauf? Lassen Sie uns das auch in ein Stylesheet schreiben.
  • Wie sehen Bildlaufleisten aus? Wo sind die Knöpfe - wenn sie welche haben? Wie breit sind sie oder werden sie nur angezeigt, wenn sich der Zeiger in einer bestimmten Region befindet?
  • Wie integrieren wir andere Farbschemata?
  • Was soll ziehbar sein? Wo werden Kontextmenüs erwartet?

Diese Probleme können nicht durch ein einfaches Stylesheet gelöst werden, wenn sie sich auf das Verhalten oder das allgemeine Layout der Anwendung auswirken. Die einzige echte 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 ausfällt.

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

amon
quelle
1
+1. Nur eines möchte ich hinzufügen: Wie sieht es mit Dingen aus, die der Benutzer vom System aus konfigurieren kann, beginnend mit „einfachen“ Details wie dem Öffnen von Kontextmenüs? (Und ich würde Windows-Programme lieber mit Bändern und Mac-Apps verwenden als, danke. Ja, gute GUIs müssen für jedes Betriebssystem entworfen werden.)
Christopher Creutzig
@ChristopherCreutzig Daraus ergibt sich meine Erfahrung: Auf meinem Hauptdesktop verwende ich KDE unter Linux (beide sind sehr konfigurierbar) und passe mit QtCurve das Erscheinungsbild von Anwendungen an. Diese speziellen Stile funktionieren in den wichtigsten KDE-Anwendungen einwandfrei. Gut geschriebene GTK-Apps können eine Kompatibilitätsebene verwenden, aber Hintergrundverläufe fehlen, die Menüleiste bleibt im Fenster usw. Dann verschlechtert sie sich jedoch schnell, da Programme einige Widgets aus dem Systemstil übernehmen (z. B. Bildlaufleisten). , aber andere ignorieren (wie Schriftart-Rendering oder Schatten um Menüs)
amon
+1, weil diese Antwort einige Stärken aufweist, aber auch einige Schwächen. Jedes Problem "Wie zeichnet dieser Fenstermanager X?" Wird mithilfe der nativen API behandelt. Zum Beispiel kann X11 unter OS X native OS X-Fenster, Schaltflächen, Bildlaufleisten, Dialogfelder usw. zeichnen. Viele dieser Probleme verschwinden also. Die wirkliche Antwort ist, was @TheSpooniest unten sagte: UX ist so viel mehr als nur das Zeichnen von Widgets. Abstand, Timing, Animation, Mausbeschleunigung, Berührungseingaben ... es gibt eine Welt subtiler Details, deren Reproduktion mit einem plattformübergreifenden Toolkit sehr teuer ist.
Mark E. Haase
13

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 der einen Version mehr Platz verfügbar, in der anderen nicht. Möglicherweise passt die Farbe besser zu Ihrem Design in der Windows-Version usw.

Dies ist besonders dann wichtig, wenn Sie eine vollständige Benutzeroberfläche haben: Ein OS X-Programm präsentiert seinen Inhalt anders als ein Windows-Programm. Dies ist nahezu 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 in Ordnung zu sein" - dies sieht immer noch etwas fremd aus, ist aber brauchbar und viel einfacher zu entwickeln.

Christian Sauer
quelle
9

Es ist nicht schwer, eine Schaltfläche zu erstellen, die aussieht wie eine OSX-Schaltfläche, eine Windows-Schaltfläche oder die eines anderen Toolkits. Die Richtlinien für die Benutzeroberfläche in den meisten Umgebungen sind jedoch nicht so einfach wie die Grundlagen von "So sieht eine Schaltfläche aus". Es gibt viele subtilere Unterschiede, angefangen vom Abstand zwischen den Elementen der Benutzeroberfläche bis hin zur Reihenfolge, in der bestimmte bekannte Aktionen in einer Liste angezeigt werden sollen, bis hin 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 macht es 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 mit der sorgfältigen manuellen Benutzeroberflächenarbeit in Einklang zu bringen, aber dies ist nicht etwas, was die meisten Programmierer für alle Plattformen können oder wollen.

Swings Ansatz bestand darin, native Toolkits zu vermeiden, wann immer dies möglich war. Es ist nicht einheimisch und versucht 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, hat es versucht, sich selbst zufrieden zu stellen, und obwohl dies gelungen ist, kann man sich fragen, wie effektiv das Ergebnis für die breitere Benutzergemeinschaft ist.

Der Löffeligste
quelle
7

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 API schützen, die ihre Anwendung möglicherweise unerwartet beschädigen.

Aus diesem Grund bevorzugen es einige Entwickler von GUI-Toolkits, ihre eigenen Komponenten bereitzustellen, die native Komponenten imitieren, aber ihre eigene Implementierung bereitstellen. 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 sich nur wenige Vorteile ergeben.

Beachten Sie, dass dieses Problem nicht Java-spezifisch ist, sondern von jedem Unternehmen verursacht wird, das plattformunabhängige Toolkits herstellt.

Nicola Musatti
quelle
Anstatt stillschweigend abzustimmen, würden Sie der Community einen größeren Dienst erweisen, indem Sie erklären, was Sie mit einer Antwort für falsch halten. Es sei denn, es ist nur ein persönliches Problem ...
Nicola Musatti
4

Das liegt alles an der Geschichte.

Sun wünschte sich, dass alle Java-Programme auf allen Computern gleich funktionieren.

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

Sun tat alles, um das Schreiben von Java-Software, die in ein Betriebssystem integriert ist, zu erschweren. Bei jeder Integration in ein Betriebssystem würde die Software auf jedem Betriebssystem anders funktionieren.

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

Sun hat Java auf dem Desktop getötet, indem alle Programmierer, die Microsoft Java-basierte Systeme verwendeten, geschockt wurden, sodass jeder Programmierer, der sich in den frühen Tagen für Java entschied, schlecht aussah.

Jeder, der Desktop-Software schreibt, die darauf bedacht ist, „nativ zu sein“, hat vor langer Zeit gelernt, Java nicht zu verwenden, und seine Ansichten werden jedes Mal verstärkt, wenn er Oracle-Software verwendet.

Daher ist es heutzutage nicht mehr erforderlich, dass Desktop-Software von Java-Programmierern „nativ angezeigt“ wird.

Ian
quelle
5
"Sun hat alles in seiner Macht Stehende getan, um das Schreiben von Java-Software, die in ein Betriebssystem integriert ist, zu erschweren." Sie haben einfach keine großen Anstrengungen unternommen, um es einfach zu machen. "Sun hat Java auf dem Desktop getötet, indem alle Programmierer, die Microsoft Java-basierte Systeme verwendeten," falsch, die gegenseitige Feindseligkeit zwischen Microsoft und Sun veranlasste Microsoft, eine Version der AWT-Bibliotheken zu erstellen, die nicht mit den Anforderungen von Sun kompatibel war und die berüchtigten verursachte So / MS-Klagen.
Jwenting
1
@jwenting, Sun kümmerte sich mehr darum, Probleme für Microsoft zu machen, als um Programmierer, die sich für das Java-basierte System von Microsoft entschieden hatten. Daher gab ich Jave auf und blieb bei MFC, bis C # herauskam.
Ian
3
vielleicht ein paar Leute bei Sun, aber dieses Gefühl war beiderseitig. Wenn Sie ausschließlich für eine einzelne Plattform entwickeln, ist ein natives Tool für diese Plattform IMMER die bevorzugte Option. Dies hat nichts mit der Unternehmenspolitik zu tun. Wenn Sie Ihre Tools auf der Grundlage von "Ich hasse Sun" oder "Ich hasse Microsoft" auswählen, spiegelt dies Ihre professionelle Einstellung nur sehr schlecht wider. Ich habe hauptsächlich Java verwendet, aber daneben habe ich auch Delphi, C #, Ruby, C ++, C, Progress verwendet, was auch immer das Beste für den jeweiligen Job war. Und meistens ist das eine hybride Lösung.
Jwenting
3

Was Sie denken, ist, nativedass 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 eine Java-App starten. Es scheint nicht heimisch zu sein. Beispielsweise können fast alle Microsoft-Projekte (Office, Outlook usw.) mit Windows-Standardsteuerelementen nicht visuell reproduziert werden.

Es wird noch schlimmer, wenn Microsoft und Apple ihren Betriebssystemplattformen dynamische UI-Funktionen hinzufügen. Entwickler können ihre Apps auf die gleiche Weise gestalten, wie Webdesigns Stile für Websites erstellen.

Java auf der Android-Plattform folgt diesem Pfad. Erstellen der in XML definierten Benutzeroberflächenelemente für Android mit Skins.

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

Reactgular
quelle
1
+1, in der Windows 95-Ära gab es ein "Standard" -Look für Windows-Steuerelemente. Nun nicht so sehr.
GroßmeisterB
Ja, es ist ein paar Jahre her, dass ich Desktop programmiert habe, aber ich war überrascht, dass .NET nicht mit einem Ribbon Style Control ausgeliefert wurde, obwohl es in die von MS erstellte Produktivitätssoftware integriert wurde.
Rig
@Rig Seit NET 4.0 gibt es in .NET ein gutes natives Ribbon Control. Hier ist ein guter Artikel: c-sharpcorner.com/UploadFile/0b73e1/ribbon-control-in-wpf-4-5
Christian Sauer
1
@ Rig Sie benötigen .NET 4.5, nicht .NET 4. Visual Studio 2010 kann nur bis zu 4 als Ziel verwenden. Sie benötigen VS2012 oder neuer für Ziel 4.5. Ich kann es beim Targeting auf 4.5 in VS2013 sehen, aber nicht, wenn ich die Zielversion auf 4 ändere.
Bob
1
@Rig Es ist möglich, das Menüband in Net 4.0 zu verwenden. Sie können es von Microsoft herunterladen und es wird angezeigt : 10rem.net/blog/2010/10/22/wpf-ribbon-october-release (Ich bin mir nicht sicher, ob dies der Fall ist ist die neueste Version). Laden Sie es besser von Nuget herunter. Ich musste das für ein Programm tun, das unter Windows XP laufen musste - funktioniert einwandfrei und ist größtenteils mit der Net 4.5-Variante kompatibel, sodass Sie die 4.0-Sache herausreißen können, wenn XP endgültig in den Ruhestand geht.
Christian Sauer
-1

Welches Betriebssystem möchten Sie auch "native" aussehen?

Man kann einfach nicht zu 100% für alle einheimisch sein.

SWT usw. sind der beste Ansatz, um für alle so natürlich zu wirken, wie es nur geht, wenn Sie einen Kompromiss eingehen müssen .

Tatsächlich wird dieser Kompromiss immer schwieriger zu erreichen. nicht so sehr aufgrund von Betriebssystemen, sondern aufgrund von Eingabegeräten. Für Touchscreens, müssen Sie tatsächlich entwerfen anders, weil es keine rechte Maustaste. Aus diesem Grund müssen Sie ansonsten dieselbe Funktionalität bereitstellen.

Es wird niemals eine magische Taste geben, die die Funktionalität "intuitiv" von der rechten Maustaste auf die Gastsysteme überträgt, ohne dass Sie jeden einzelnen Aspekt für jedes einzelne Eingabegerät spezifizieren (zu diesem Zeitpunkt sind Sie für jede von Ihnen in Betracht gezogene Plattform beheimatet, aber dennoch nicht -Native für alle, die Sie nicht berücksichtigt haben).

Anony-Mousse
quelle
-2

Wirklich gute Frage. Ich habe mich in den letzten Jahren immer selbst darüber gewundert, ich dachte, es steckt ein legitimer Grund dahinter, aber das gibt es wirklich nicht.

Ich denke, die Antwort ist ziemlich einfach, und viele Antworten befassen sich nicht wirklich mit dem Thema.

Wenn Ihre Sprache das Zeichnen von Kreisen auf dem Bildschirm zulässt, ist es zu 100% möglich, ein darauf basierendes GUI-Framework zu erstellen, das das Erscheinungsbild und Verhalten von Windows-Formularsteuerelementen genau nachahmt.

Da Java plattformübergreifend ist, ist es durchaus möglich, sicherzustellen, dass die Benutzeroberfläche basierend auf dem aktuell ausgeführten Systemtyp (Mac / Windows) auf beiden Plattformen unterschiedlich aussieht und dem Laufzeitplattformstil entspricht.

Wie Sie beispielsweise in XAML sehen können, kann die Benutzeroberfläche leicht in sehr strukturierter Form und Sprache dargestellt werden. Die Auswahl des "nativen" Verhaltens ist auch möglich, wenn dafür Zeit benötigt wird.

So wäre es möglich, ein GUI-Framework zu erstellen, mit dem Java-Entwickler Anwendungen erhalten, die auf Mac und Windows nativ aussehen.

Wir kommen also zu Swing, das ist nur ein GUI-Framework aus der potenziellen Unendlichkeit von GUI-Frameworks, die für Java erstellt werden könnten. Es verhält sich wie es programmiert wurde, was nicht dem obigen Prozess folgt und Sie erhalten auf beiden Systemen seltsam aussehende Apps. Das ist die Entscheidung, die die Swing-Entwickler getroffen haben. Niemand hat sie gezwungen, dies zu tun und sich so zu verhalten.

Valentin Kuzub
quelle
2
Dies beantwortet nicht die Frage, Fragesteller bereits diesen Punkt behandelt: "Swing könnte absichtlich entworfen worden sein, um ein unverwechselbares Aussehen zu haben"
Mücke
Ich bin anderer Meinung, aber danke, dass Sie Ihr Minus (?) Kommentiert haben
Valentin Kuzub