JavaFX Flexible Layouts dynamisch erstellen / Design-Inspirationen

[top_chief]

Hallo,
ich wollte mich mal umhören, wie ihr vorgeht, wenn ihr in JavaFx in einem Fenster Inhalte anzeigen wollt, die in ihrem Umfang sehr unterschiedlich sind. Gibt irgendwelche Tipps und Kniffe? Bis jetzt habe ich die Bereiche, die sich der zB Fenstergröße anpassen, immer mit dem SceneBuilder erstellt - und ich frage mich, wie sich sowas reinweg in Java-Code bewerkstelligen lässt.
Ich habe mir mal diese "Ensemble" Anwendung angesehen, dort gibts ja bereits reichlich Inspirationen bzw. eine gute Übersicht, wie man mit recht einfachen Mitteln schon eine schöne Benutzeroberfläche "zaubern" kann. Wenn ihr gute Links oder Anleitungen kennt die, die Erstellung von der GUI thematisieren, bitte posten

Danke vorab
Martin

 

[Flown]

Es gibt eine ganze Sparte an Informatiker die sich das Problem der UI annehmen. Wie UI aufgebaut sein soll, wie sie am besten funktioniert, usw. Dazu findest du allerhand an UI Guidelines im Netz.
Händisch UI programmiert man heutzutage nicht mehr (bzw. ganz selten). WYSISWYG Editoren, wie SceneBuilder, sind perfekt ausgelegt um deine UI Vorstellungen umzusetzen - wer hat auch schon Lust fxml Code zu schreiben?

 

[dennisbauer]

Für feste GUIs, deren Layout feststeht und sich während der Laufzeit nicht großartig verändert baue ich in Scenebuilder fertig, mit entsprechenden FXML-Annotationen im Controller, um auf diese einen Injectionpoint für meine Module und Widgets zu haben.
Wenn ein Modul statisch ist, ist das Vorgehen hier genauso wie das oben genannte. Sofern das Modul flexible Inhalte benötigt, mache ich grundlegend die Unterscheidung, ob es ein größerer Widgets wird, welches wiederholt eingebunden werden muss. Dann baue ich dieses Widget ebenfalls über den Scenebuilder und entsprechendem Controller und binde dies dynamisch, meist in eine VBox, ein. Wenn es nur kleinere Elemente sind, wie z.B. Textfelder und ein Label, dann baue ich dies meist programmatisch zusammen. Das geht dann schneller von der Hand.


Was mir nur sehr stark auffällt ist, dass das große Aufkommen von FXML-Dateien zum Bauen eines Moduls sehr schnell die Ladezeiten in die Höhe treiben kann, weshalb ich es eher bevorzuge ab einer bestimmten Tiefe auch größere Templates programmatisch zu erstellen.

 

[Thallius]

Es gibt eine ganze Sparte an Informatiker die sich das Problem der UI annehmen. Wie UI aufgebaut sein soll, wie sie am besten funktioniert, usw. Dazu findest du allerhand an UI Guidelines im Netz.
Händisch UI programmiert man heutzutage nicht mehr (bzw. ganz selten). WYSISWYG Editoren, wie SceneBuilder, sind perfekt ausgelegt um deine UI Vorstellungen umzusetzen - wer hat auch schon Lust fxml Code zu schreiben?

Dann hast Du aber noch nicht an grossen Projekten gearbeitet. Wir haben immer wieder Applikationen wo sich das UI dynamisch je nach Daten die verarbeitet werden müssen aufbaut.
Nehmen wir mal an Du fragst die Detaildaten einer Person ab.
Bei einer Person bekommst du jetzt 1 Telefonnummer, bei der anderen 4 Telefonnummern. Klar kann man das jetzt auch häßlich machen und einfach ein Popup für die Telefonnummern nehmen. Das bedeutet aber, dass ich in 90% der Fälle wo die Person nur eine Telefonnummer hat ich immer das vollkommen sinnlose Popup habe.

Oder ich mache es eben schön und erzeugt das UI dynamisch je nachdem was für Informationen ich zur Person bekomme.

Und das ist ja nur ein Beispiel. Solche Fälle kommemn zu hunderten vor.

Gruß

Claus

 

[Flown]

Dann hast Du aber noch nicht an grossen Projekten gearbeitet.

Immer vorsichtig sein mit solchen Aussagen.

Wie ich bereits vorher gesagt habe, ist das auch eine eigene, riesige Sparte (UI-Entwicklunt, Design, etc.). Da gibt es nicht die eine richtige Lösung. Vieles hängt von der Philosophie der Entwickler und deren Stil/Erfahrung ab.

Es gibt jetzt zwei Möglichkeiten um Daten anzuzeigen. Entweder man hat die UI und trimmt die Daten so, dass sie auf die UI passen, oder man kennt die Struktur der Daten und lässt sich die UI generieren.

Bei dem zweiten Ansatz kenn ich die Struktur der Daten und kann sehr gute Voraussagen treffen, wie diese aufgearbeitet werden soll. In diesem Falle nehme ich geeigenete UI-Komponenten die zu meine Struktur passen.

Eine Lösung für dein Beispiel mit den verschiedenen Telefonnummern wäre eine Liste zu wählen und nicht einzelne Labels.

Also gibt es meiner Meinung nach mehrere Wege die nach Rom führen.

 

[top_chief]

Hehe, so groß ist mein Programm nicht, aber trotzdem hätte ich es gerne so, dass die UI ansehnlich ist. Gerade weil die Desktop-App eine Art Zusatz für eine mobile App sein soll und im mobilen Bereich die Nutzer häufig wert auf Form und Design legen.
So gesehen bin ich ein bisschen hin und hergerissen.. Einerseits merke ich dass der SceneBuilder schon sehr viel Arbeit abnimmt, aber auf der anderen Seite wohl auch seine Grenzen hat.
Um das Beispiel mit den Telefonnummern auf den Vorschlag mit den Templates anzuwenden:
Man erstellt ein eigenes Widget mit dem SceneBuilder, was bspw eine Telefonnummer und zwei Icons anzeigt und lädt das dann dynamisch für jedes Vorhandensein in eine Art Container (Layout). Ist das so richtig gedacht?
Über die "fx:id" werden die Elemente dann wohl kaum mehr ansprechbar sein, dass heißt man würde die Funktionalitäten eines Buttons dann gleich beim Hereinladen (mit)setzen, oder gibt es hier eine andere Lösung?

Schon mal Danke für eure Antworten.

 

[Thallius]

Liste wäre ja noch übler als ein Popup. Da habe ich in den 90% der Fälle wo es nur eine Nummer gibt trotzdem den ganzen Platz für 4-5 (oder wieviel auch immer ich als Default angegeben habe) Einträge verschwendet.

Aber Du hast recht. In vielen Applikationen wird es genauso gemacht und ich ärgere mich immer wieder darüber, dass Design und Funktionalität hinterher bleiben nur weil es einfach zu pogrammieren ist. Aber das ist nunmal heute so und dagegen kann man nichts machen und das werfe ich Dir sicherlich nicht vor

Ich bin was UI's angeht relativ pingelig, da ich viele Jahre mit für die Entwicklung eines sehr anwenderfreundlichen Videoschnitt-Systems verantwortlich war. Ziel der Software (welches auch erreicht wurde) war, auch über 60 jährige, die bis dato nie mit einem Computer gearbeitet hatten als Kunden zu gewinnen. Das Konzept ging damals voll auf. Heute ist sowas natürlich kein Thema mehr, da jeder mit einem Computer aufgewachsen ist. Aber damals haben wir sehr viel Erfahrung gesammelt wie man Programme gestalten kann um es dem Anwender einfacher zu machen und gleichzeitig ein für das Auge gefäliges Design zu schaffen. (Wir sind damals sogar dafür ausgezeichnet worden)

Von daher ist da immer noch was hängen geblieben das nicht so recht aus meinem Schädel raus will und wenn man nur mit Bordmittel (UIBUilder) arbeitet, dann hat man halt einfach zu wenig flexibilität um so ein hochgestecktes Ziel zu erreichen.

Gruß

Claus

 

[dzim]

Na ja. Ich würde heutzutage auch wiederkehrende UI-Schnipsel (egal, ob sie am Ende in einer Liste landen, oder nicht), nicht mehr von Hand machen sondern per deklarativer UI. Dort Änderungen einzuführen ist immer noch einfacher, als die Code-Stellen zu suchen.
Ich finde es auch besser eine Strikte Trennung von UI und Controller durchzuziehen.

Ich gebe aber auch zu, das ich das auch schon mal "vergessen" habe...

 

[Ruzmanz]

Ich denke, dass JavaFX auf den richtigen Weg ist. Mit CSS und eigenen Komponenten kann man sehr gut ein individuelles Design erstellen. Insgesamt fällt mir spontan kein Fall ein, wo man kein FXML nutzen sollte. Sehe darin auch keinen Widerspruch zu der Aussage von Thallius. Meiner Meinung nach müsste die Komponente selbst entscheiden wie sie sich aufbaut (bei wenigen / vielen Kontakten). Es spricht auch nichts dagegen eigene Komponenten wie z.B. Video-Timeline zu erfinden.

Viele Entwickler sind aber keine Designer. Manche Entwickler glauben, dass sie dem Nutzer einen gefallen tun, wenn sie individuelle Komponenten erstellen. Atlassian hat exzessiv diesen Ansatz verfolgt. Am Ende gab es ca. 20 verschiedene Comboboxen. Sowas ist sehr fehleranfällig, schwer zu warten und der Nutzer muss alle verschiedenen Input-Elemente lernen (also nicht mehr intutiv!).