-
Beiträge
-
Quote:Original von krey
Das Look and Feel kann ja geändert werden. Darum gehts. Und dann hat die Java Applikation noch ihr altes Look and Feel.UIManager.getSystemLookAndFeelClassName()
Quote:Aber alle Sprachen haben bisher das Prinzip befolgt das Rad nicht neu zu erfinden und selbst etwas zu zeichnen sondern die Systemeigenen Komponenten zu nutzen.Warum gibt es dann GTK+ und Qt für X11?
Es gibt doch auch Xt/Intrinsics , das wäre doch „systemeigen“.UIManager.getSystemLookAndFeelClassName() <- kriegt das Java Look and Feel, das dem System am änlichsten ist!! Nicht das System Look and Feel!!!!!! GTK+ und Qt für X11 <- Das sind doch in gewisser Weise nur Wrapper. Es gibt 2 unterschiedliche da es früher eine Qt/KDE Lizenz gab die GTK+ leute nicht teilten (unfrei). Da jetzt auch die Qt Sachen offen sind macht das keinen Unterschied mehr. Nur diese beiden gibt es nur wegen ihrer Historie. Außerdem wird intern alles ins X Protokoll übersetzt.
ihr kommt vom thema ab und werdet mir zu fachspezifisch.
ihr könnt aus den bisherigen beiträgen ja ein neues thema zusammenschneidenQuote:Original von krey
UIManager.getSystemLookAndFeelClassName() <- kriegt das Java Look and Feel, das dem System am änlichsten ist!! Nicht das System Look and Feel!!!!!!Quote:Original von me1357
Apple hat bisher immer ein zum System passendes l&f installiert gehabt.
Warum sollte das in Zukunft anders sein?Quote:GTK+ und Qt für X11 <- Das sind doch in gewisser Weise nur Wrapper.Nein.
Es setzen beide direkt auf die libX11 auf.Nein.
Es setzen beide direkt auf die libX11 auf.??? Habe ich denn etwas anderes gesagt? Das sind Bibliotheken die alles vereinfachen, die wrappen den Qt/Gtk Programm zu einem Binary, dass das X Protocol versteht/spricht.
Quote:Original von kreyDas sind Bibliotheken die alles vereinfachenWo wird denn Vereinfacht?
GTK+ und Qt zeichnen ihre Widgets komplett selbst, mit primitiven Grafikfunktionen für X11, genauso wie es Swing macht.
Andere Toolkits für X11 (zum Beispiel Motif oder Xaw) basieren auf Xt Intrinsics, was allgemeine Methoden bietet um Widgets zu zeichnen.Das ist sachlich falsch. Die VM hat abstrakte Methoden um die Grafiken zu zeichnen. Diese werden von Swing benutzt. Sonst würde das ganze nicht funktionieren, denn unter Windows gibt es keinen X Server der das X Protokoll spricht.
AWT zum Beispiel benutzt API Layering um Fenster direkt mit Systemfunktionen zu zeichnen, sprich der Windows API.
Swing zeichnet alle Komponenten selbst und überlässt dem System an sich nichts, außer der Darstellung der gezeichneten Bilder und dem Zugriff auf Sockets für Events etc.
Qt benutzte seine eigene Zeichenengine und Steuerelemente. Es emuliert das unterschiedliche Aussehen auf den verschiedenen Plattformen (GUI-Emulation). Das machte das Portieren einfacher, da nur sehr wenige Klassen in Qt von der verwendeten Plattform abhängig sind. Der Nachteil war aber, dass Qt das Aussehen jeder Plattform präzise nachahmen musste, was nicht immer möglich war. In der neusten Version von Qt hat man von diesem Konzept Abstand genommen und verwendet, wie viele andere Toolkits (wxWidgets oder SWT), auch die plattformeigenen Elemente zur Implementierung.
Somit werden die Fenster dort wirklich (wieder) von der Windows API gezeichnet.
Das neuere GTK+ (mit Theme engine) geht wieder den Weg das System look and feel zu emulieren, natürlich auch auf Kosten der Geschwindigkeit.
Quote:Original von Strubbl
ihr kommt vom thema ab und werdet mir zu fachspezifisch.
ihr könnt aus den bisherigen beiträgen ja ein neues thema zusammenschneidenFinde ich auch, auch wenn ich nicht vom Fach bin. Ich finde du, whitenexx, solltest das Thema teilen und ein neues daraus schustern, wie Strubbl schon sagte. Es ist ja sicherlich nicht uninteressant was ihr da redet aber ich glaube das ist nicht die Hilfestellung die sich Strubbl gewünscht hat, oder? Wenn doch dann bitte nicht schlagen
Quote:Original von krey
Das ist sachlich falsch. Die VM hat abstrakte Methoden um die Grafiken zu zeichnen. Diese werden von Swing benutzt.Ja, aber ob abstrakt oder nicht, primitiv sind sie trotzdem.
Und letzen Endes schickt die java-vm dann primitive Zeichenoperationen direkt an den Xserver.Quote:In der neusten Version von Qt hat man von diesem Konzept Abstand genommen und verwendet, wie viele andere Toolkits (wxWidgets oder SWT), auch die plattformeigenen Elemente zur Implementierung.Nein, nicht unter X11.
Quote:Ja, aber ob abstrakt oder nicht, primitiv sind sie trotzdem.
Und letzen Endes schickt die java-vm dann primitive Zeichenoperationen direkt an den Xserver.Alle Programme mit graphischer Oberfläche arbeiten mit dem X Server, wie sollte es auch sonst laufen? Aber wenn das System eigene Methoden/Funktionen benutzt die ein Fenster zeichnen ist das noch etwas ganz anderes als wenn Swing etc. eigene Komponenten berechnet. Wieso ist AWT sonst schneller als Swing :o)
AWT Komponenten kommen wirklich vom System, swing Komponenten nicht. Wie das ganze umgesetzt wird hängt von der Implementierung von der VM ab.
Quote:Nein, nicht unter X11.Quellen?
Quote:Original von kreyAber wenn das System eigene Methoden/Funktionen benutzt die ein Fenster zeichnen ist das noch etwas ganz anderes als wenn Swing etc. eigene Komponenten berechnet.Was ist denn „das System“?
Es gibt den Xserver, der wird von Swing benutzt zum zeichnen.
Es die Möglichkeit mit nativen Bibliotheken Widgets zu zeichen (mit Xt über Xaw, Motif ..), die benutzt Swing nicht, die benutzt Gtk+ nicht, die benutzt Qt nicht …Quote:Original von krey
Quellen?Mach mal einen einfachen Bildvergleich:
natives Programm (Xaw):
http://catb.org/~esr/writings/taoup/html/graphics/xcalc.pngQt-Programm:
http://www.gentoo-portage.com/up_img/img_800px/740.png
Meinst du wirklich, dass Qt hier plattformeigene Elemente benutzt?Bildvergleich – tzZ?
Das X Programm ist deiner Formulierung nach auch nciht nativ. Das wird ja auch per Anweisung an den X-Server gezeichnet.
Es die Möglichkeit mit nativen Bibliotheken Widgets zu zeichen <- QT,GTK+ Was ist denn für dich nativ? Der X Server ist doch auch nur ein Teil der Software auf dem System. Natürlich kommunizieren in der Regel alle Programme die etwas graphisch darstellen mit dem X Server. Nur es macht Unterschiede ob Bibliotheken die Fenster Zeichnen bereits Systemeigen vorhanden sind, oder ob das ganze auf eine VM gepackt wird die nur ein Minimum an Systemkomponenten nutzt und eigentlich nur Bilder hin und herschickt.
Quote:Original von krey
Das X Programm ist deiner Formulierung nach auch nciht nativ.Es basiert auf einem Toolkit, das zum direkten Softwareumfang der X11-Distribution gehört.
Ich finde das könnte man als nativ bezeichnen.
Unter Windows würde ja denke ich auch jeder die Win-API als nativ bezeichnen.Quote:Es die Möglichkeit mit nativen Bibliotheken Widgets zu zeichen <- QT,GTK+Was ist daran nativ? Die Programmiersprache?
Abgesehen davon, dass die nicht in Java geschrieben sind, machen sie auch nichts anders Swing.
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.