Haben die alten Widgets ausgesorgt?



  • Mechanics schrieb:

    Swing in Java war schon immer Schrott.

    Begründung?

    Besser als AWK war es allemal.



  • What's wrong with swing schrieb:

    Mechanics schrieb:

    Swing in Java war schon immer Schrott.

    Begründung?

    Besser als AWK war es allemal.

    Die, die Swing verbrochen haben sagen selbst, dass nicht viel Zeit in das Designen von Swing geflossen ist. Und hast du es schon mal verwendet? Wenn man besseres gewohnt es fühlt es sich furchtbar an.



  • In Java8 har sich neben JavaFX auch so eine Menge getan. Es gibt jetzt einen Metaspace der nativen Arbeitsspeicher nutzt und dessen maximalgröße nicht mehr angegeben werden muss, aber man kann sie limitieren wenn man will. Dann können Interfaces auch Default-Methoden haben. Die Collections haben die Methode forEach bekommen, der man dann einen Lambda-Ausdruck übergeben kann. Will man Beispielweise auf alle Elemente eine Funktion anwenden, wie z.B. println zur Ausgabe dieser, dann schreibt man nur noch:

    myList.forEach( System.out :: println );
    

    Das wird auch beim Eventhandling in JavaFX ganz viel eingesetzt. Auch das Binden nach dem MVVM-Prinzip ist eine feine Sache. Das schafft eine bidirektionale Bindung zwischen Variablen, so ähnlich wie Signals/Slots in beide Richtungen bei Qt.

    Und da gibt es noch viel mehr Änderungen, die die Programmierung mit Java doch sehr verändern und vereinfachen werden.

    Ich denke auch, dass die alte Methode der GUI-Programmierung durch WPF, Qt-Quick und JavaFX komplett ersetzt wird, jedenfalls für neue Projekte. Es ist schon erschreckend wie schnell und unkompliziert man mit der neuen Art was auf die Beine gestellt bekommt. Braucht man wirklich mal extrem performante Numerik, so erstellt man einfach eine native Lib und bindet sie mit ein. Es gibt nicht mehr viele Gründe, eine gesamte Anwendung nativ machen zu wollen.



  • Keiner Zusatz zu Java8, durch die Default-Methoden in Interfaces ist jetzt auch Mehrfachvererbung möglich. Ob man das nutzen möchte, muss jeder selbst abwägen.



  • Das "Deadly Diamond of Death" Problem von der Mehrfachvererbung in C++ stellt sich aber nicht bei Java8, da Interfaces nach wie vor nur statische und konstante Felder/Eigenschaften besitzen dürfen.



  • GUIBuilder schrieb:

    Wenn man sich so die Entwicklung in der GUI-Technologie anschaut, dann geht alles den Weg von WPF

    Ja, leider.

    GUIBuilder schrieb:

    Zusätzlich sind die GUI-Elemente vollständig GPU-Beschleunigt und wirklich flink dadurch.

    Den Eindruck hatte ich nicht. Tatsächlich kann ich mich an keine WPF-Anwendung erinnern, die nicht träge wirkte. Herkömmliche GUIs (Win32-Steuerelemente, selbstgezeichnet mit Direct2D, Qt etc.) fühlten sich eigentlich immer flotter an.

    Was habe ich verpaßt? Was ist so toll an WPF und JavaFX? Brauchbare GUI-Builder gibts auch für Qt, WinForms, VCL. Vektor-UI ist vielleicht in der Theorie richtig; aber ist das auch eine Verbesserung für den Benutzer? Weil die ganzen Vektor-UIs so tun, als gäbe es keine Pixel mehr, wird das Ergebnis auf einem gewöhnlichen Bildschirm schlechter. Z.B. der Scrollbar-Greifer im Win7-Theme wird je nach Position anders gerendert, weil WPF standardmäßig kein Grid-Fitting macht. Und auch Text rendert WPF standardmäßig mit "ClearType Natural", so daß die Schrift zwar fast perfekt mit dem UI skaliert, aber verglichen mit gewöhnlichem grid-fitted ClearType viel schlechter zu lesen ist. JavaFX und WinRT scheinen überhaupt nur mit Graustufen-Antialiasing zu rendern. Die Entwickler haben wahrscheinlich alle Retina-Displays und halten das Thema damit für erledigt 😞

    Das einzige wirklich gute WPF-GUI, das ich kenne, ist Visual Studio. Und selbst da tanzt WPF ein wenig aus der Reihe, z.B. wenn man die Systemschriftgröße von 9pt auf 8pt stellt. Die ganzen Winforms-Dialoge machen hingegen keine Probleme.



  • JavaFXFan schrieb:

    In Java8 har sich neben JavaFX auch so eine Menge getan. Es gibt jetzt einen Metaspace der nativen Arbeitsspeicher nutzt und dessen maximalgröße nicht mehr angegeben werden muss, aber man kann sie limitieren wenn man will. Dann können Interfaces auch Default-Methoden haben. Die Collections haben die Methode forEach bekommen, der man dann einen Lambda-Ausdruck übergeben kann. Will man Beispielweise auf alle Elemente eine Funktion anwenden, wie z.B. println zur Ausgabe dieser, dann schreibt man nur noch:

    myList.forEach( System.out :: println );
    

    Das wird auch beim Eventhandling in JavaFX ganz viel eingesetzt. Auch das Binden nach dem MVVM-Prinzip ist eine feine Sache. Das schafft eine bidirektionale Bindung zwischen Variablen, so ähnlich wie Signals/Slots in beide Richtungen bei Qt.

    Gibt's eigentlich irgendwo eine Webseite, die auf einer Übersicht die Geschichte von Java erwähnt.
    Also welche Features in welcher Java Version hinzukamen?
    Ideralerweise mit einem Verweis auf Beispiele und einer Erläuterung wie so ein Featue genau angewendet wird und was es macht?

    Zu JavaFX habe ich dann noch speziell eine Frage.
    Das Video habe ich mir angesehen.
    Man kann da Bilder darstellen und diese zeitlich animiert verschieben und das ganze wird von der GPU noch beschleunigt.

    Gibt es da also irgendeinen Grund, der dagegen spricht JavaFX für ein 2d Spiel zu verwenden?

    Im Prinzip müßte man mit JavaFX ja auch so etwas wie Age of Empires 2, Civilization 5, Project Zomboid oder irgendein anderes 2d Spiel realisieren können.
    Wo sind da also noch die Grenzen zwischen GUI und Grafikengine?

    Warum sollte man sich z.B. mit SDL abquälen und alles selber implementieren, wenn JavaFX schon alles bietet?

    So ein klassisches GUI Toolkit, dass nur Fesnter und Buttons zeichnen kann ist es ja nun nicht mehr.



  • For Games? schrieb:

    so etwas wie Age of Empires 2, Civilization 5, Project Zomboid oder irgendein anderes 2d Spiel realisieren können.

    Project Zomboid kenn ich nicht, aber was soll an den anderen beiden 2D sein? Prinzipiell würds schon irgendwie gehen, aber was brauchbares kriegst du damit nicht hin. Von nichts kommt nichts 😉 Wenn du nicht trollst, dann stellst du dir Spieleentwicklung viel zu einfach vor.



  • JavaFxFan schrieb:

    Das "Deadly Diamond of Death" Problem von der Mehrfachvererbung

    Kenn ich nicht. Du meintest sicher das "Deadly Diamond of Deadly Death"-Problem.



  • Mechanics schrieb:

    For Games? schrieb:

    so etwas wie Age of Empires 2, Civilization 5, Project Zomboid oder irgendein anderes 2d Spiel realisieren können.

    Project Zomboid kenn ich nicht, aber was soll an den anderen beiden 2D sein? Prinzipiell würds schon irgendwie gehen, aber was brauchbares kriegst du damit nicht hin. Von nichts kommt nichts 😉 Wenn du nicht trollst, dann stellst du dir Spieleentwicklung viel zu einfach vor.

    Mir ging es um die prinzipielle Frage, nicht daraum, dass ich vorhabe das zu machen.
    Wenn du aber nicht weißt, ob JavaFX hier grenzen auflegt (war ja meine Frage), wieso antwortest du dann?



  • Ich habs doch schon beantwortet. Gehen würde es schon, aber du kriegst nichts brauchbares raus. Wenn du was brauchbares haben willst, musst du viel tiefer ansetzen und entweder alles selber machen, oder Engines/Frameworks verwenden, die explizit für Spiele gedacht waren.



  • Mechanics schrieb:

    Ich habs doch schon beantwortet. Gehen würde es schon, aber du kriegst nichts brauchbares raus. Wenn du was brauchbares haben willst, musst du viel tiefer ansetzen und entweder alles selber machen, oder Engines/Frameworks verwenden, die explizit für Spiele gedacht waren.

    So wie jetzt hast du es nicht geschrieben.
    Dein ganzes Posting, also der Schwerpunkt von diesem hast du auf mich bezogen und thematisch darauf, wie du es in deinen letzten Satz beschreibst:

    [QUOTE] aber was brauchbares kriegst DU damit nicht hin. Von nichts kommt nichts 😉 ..., dann stellst du dir Spieleentwicklung viel zu einfach vor.[QUOTE]

    Also in der Form:
    "schon wieder ein Newb der Megasuperdollspiel progammieren will und keine Ahnung hat."

    So war dein Posting zu lesen, daher meine Reaktion weil ich ja nur wissen wollte, welche Grenzen einem JavaFX auferlegen würde.



  • Ich denke schon, dass Java auf jeden Fall für Casual Games reicht, was heute ein sehr großer Markt ist, siehe Android. Wer sich mal ein Bild über die Geschwindigkeit der GUI machen will, der kann sich gerne mal die Essential-Demo(ist jetzt in den 8er Demos enthalten) von JavaFX anzuschauen. Bei mir läuft da alles butterweich.

    Dass nicht jedem neue Wege gefallen ist klar. Ich persönlich habe großen Spaß daran gefunden, mit JavaFX rum zu spielen und dabei habe ich Java seit Jahren nicht mehr angerührt, sondern mich mehr mit C++ und Qt beschäftigt. Das habe ich erst mal komplett gestoppt, weil ich mit JavaFX einfach schneller, stressfreier ans Ziel komme. Schon allein wieder ohne Trennung von Header und Source arbeiten zu können ist ein Traum. Und was für ein Segen, endlich am PC und Mac einfach weiterarbeiten zu können, ohne irgendwelche Libs für die jeweilig Plattform kompilieren zu müssen. Das geht zwar alles irgendwie, aber in der Summe bremst C++ bei mir den Programmierspaß doch erheblich. Aber das ist ja Geschmackssache. Ein bisschen C++ zu können, falls man wirklich das letzte bisschen Speed braucht und was auslagern muss, ist ja auch nicht verkehrt.

    Für meine kleinen Tools und ein bisschen Gameprogramming auf PC und Android reicht Java für mich locker.



  • @For Games?: Das war natürlich nicht auf dich persönlich bezogen, ich hätt wohl eher "man" schreiben sollen...
    Für bestimmte Spiele würde JavaFx sicherlich reichen. Aber schon sowas wie Age Of Empires 2 ist bei weitem kein Casual Game mehr, auch wenns mittlerweile etwas betagt ist. Man braucht einfach viel mehr Kontrolle über alle möglichen Details, um sowas brauchbar umzusetzen. Man fängt da vielleicht mit JavaFx an und merkt erstmal, dass man irgendwie voran kommt. Dann fangen aber die Probleme an und man will etwas anders machen. Man findet irgendwelche Hacks und Workarounds. Dann kommen weitere Probleme. Und irgendwann merkt man einfach, dass es einfach besser und einfacher gewesen wäre, das alles von vornherein anderes aufzubauen. Wenn man ein ganz kleines Spiel schreibt, wird man vielleicht erst gar nicht auf größere Probleme stoßen, da könnte JavaFx wieder ausreichend sein.

    JavaFXFan schrieb:

    Aber das ist ja Geschmackssache. Ein bisschen C++ zu können, falls man wirklich das letzte bisschen Speed braucht und was auslagern muss, ist ja auch nicht verkehrt.

    Nicht unbedingt nur Geschmackssache... Ich sehe das so, dass die Vorteile anderer Sprachen gegenüber C++ immer vernachlässigbarer werden, je größer ein Projekt ist. Ich hätte auch wenig Lust, irgendwas kleines in C++ anzufangen (erst recht, wenn die Umgebung noch nicht eingerichtet ist und man erst was zusammensuchen muss). Da bin ich mit C# wesentlich schneller (und das ist jetzt wieder Geschmacks-/Erfahrungssache, das gefällt mir besser als Java und damit hab ich mehr Erfahrung). Aber bei großen Projekten die schon laufen, ist man mit C++ mindestens genauso produktiv.



  • Nachdem einem JavaFX einen 3D Kontext bietet kann man damit natürlich alles umsetzen.



  • JavaFXFan schrieb:

    Ich denke schon, dass Java auf jeden Fall für Casual Games reicht, was heute ein sehr großer Markt ist, siehe Android. Wer sich mal ein Bild über die Geschwindigkeit der GUI machen will, der kann sich gerne mal die Essential-Demo(ist jetzt in den 8er Demos enthalten) von JavaFX anzuschauen. Bei mir läuft da alles butterweich.

    Habe diese Demo jetzt mal getestet.
    Grafisch sind das leider alles sehr einfach gehaltene Demos mit wenigen Objekten.
    Das beste dürfte noch das Feuerwerk (Canvas Fireworks) und das mit den Buchstaben sein "Key Stroke Motion", wo man ganz schnell Tasten eintippen kann und dann der Buchstabe aufpoppt zur Seite geht und dann verschwindet, also wie eine Sprudelquelle, wenn man schnell ist.

    Aber ich habe auch Lag gefunden. Besonders störend fand ich das bei dem einen
    "Brick Breaker" Spiel, da hat es mich 3 Leben gekostet, nur weil die Eingabe der Maus zu langsam reagierte, wenn der Balken ganz rechts war und nun schnell nach links musste. Irgendwie klebte der für einen kurzen Augenblick am Rand fest.
    Könnte natürlich auch an der Programmierung liegen.

    Schön sehen die Beispiele alle aus. Und ich hätte nicht gedacht,
    dass damit auch 3d Körper möglich wären.

    Für meine kleinen Tools und ein bisschen Gameprogramming auf PC und Android reicht Java für mich locker.

    Danke, die Aussage ist doch mal ein Wort.



  • Mechanics schrieb:

    Aber bei großen Projekten die schon laufen, ist man mit C++ mindestens genauso produktiv.

    Wieso ist man bei kleinen/mittelgroßen Projekten mit C# und Java produktiver und bei großen Projekten plötzlich nicht mehr? 😕



  • IBV schrieb:

    Mechanics schrieb:

    Aber bei großen Projekten die schon laufen, ist man mit C++ mindestens genauso produktiv.

    Wieso ist man bei kleinen/mittelgroßen Projekten mit C# und Java produktiver und bei großen Projekten plötzlich nicht mehr? 😕

    Bei C# (oder Java) kann man sofort loslegen. Du startest die Entwicklungsumgebung, hast eines riesige Standardbibliothek, die wahrscheinlich schon vieles von dem was du brauchst mitbringt, und kannst direkt loslegen. Mit C++ kann man erstmal nicht ganz so direkt loslegen. Man braucht erstmal ein Buildsystem. Wenn man sich noch gar nicht auskennt, ist es schon mal eine Hürde. Wenn man sich mit einem auskennt, aber aus irgendeinem Grund plötzlich ein anderes braucht, ist es wieder eine Hürde. Dann braucht man wahrscheinlich erstmal irgendwelche Frameworks. Ist ziemlich wahrscheinlich, dass auch ein kleines Tool eine GUI brauchen wird, also muss man sich erstmal ein Framework wie Qt oder GTK besorgen und einrichten. Auch damit ist man nicht ganz so schnell, wie mit C#. Ich arbeite schon seit zig Jahren mit Qt und, trotzdem könnte ich eine kleine langweilige GUI in C# schneller erledigen. Wenn man dann irgendwelche zusätzlichen Bibliotheken braucht, ist es erstmal wahrscheinlich, dass man in C++ erstmal zusätzlichen Code schreiben muss, um die einzubinden, allein schon, weil jeder seine eigenen String und Container Klassen schreibt. Das kostet bei einem kleinen Projekt alles Zeit und rentiert sich nicht.
    Bei einem großen Projekt ist es egal (vor allem, wenns schon läuft). Da hat man irgendwann ein Buildsystem eingerichtet, verwendet bereits zig Bibliotheken, hat gewisse Workflows usw. Da werden dann wieder die Stärken von C++ wichtiger, wie Flexibilität oder gutes Laufzeitverhalten.



  • Das mit den Fixkosten stimmt schon, aber C# bietet auch genug Langzeitvorteile. Ich bin ja völlig verdorben, seit ich LINQ benutze, weil meine Unit-Tests jetzt WYSIWIM sind. Oder seit ich State-Machines für Hintergrundtasks nicht mehr von Hand machen muß.



  • Ich hab ja nicht unbedingt behauptet, dass C# für große Projekte schlecht wäre. Nur, dass sich die Vorteile relativieren und C++ dann auch nicht mehr so schlecht abschneidet.


Anmelden zum Antworten