JavaFX ListCell höhe verändert sich beim ändern der Text-Farbe

[sascha-sphw]

Ich habe gerade eine Entdeckung gemacht und kann mir das Verhalten leider überhaupt nicht erklären.

Ich habe eine Liste mit eigenem ListCell, der Text wird mit CSS rot eingefärbt wenn man in der Combobox "Colored" auswählt.

Wenn man genau aufpasst, sieht man wie sich die Zeilenhöhe auf einmal verringert.

Wenn man nun "Not Colored" auswählt wird der Text Style gelöscht, aber die Zeilenhöhe bleibt unverändert.

Wenn man nun wieder auf "Colored" schaltet und anschließend die Combobox mit ctrl click deselectiert, wird die Zeilenhöhe wieder vergrößert, obwohl doch genau der gleiche Code zum löschen des Styles ausgeführt wird.


Würde mich freuen wenn der eine oder andere mal drüber schauen kann und mit mir diskutiert, wie diese Verhalten zu erklären ist.

Hier gehts zum Source.

sascha-sphw/size-issue

Contribute to sascha-sphw/size-issue development by creating an account on GitHub.

github.com

 

[mihe7]

Ich würde mal vermuten (kenne mich mit FX nicht aus), dass setStyle(null) die Standardeinstellungen wiederherstellt. Was passiert denn, wenn Du z. B. node.setStyle("-fx-fill: black; -fx-text-fill: black;") verwendest?

 

[sascha-sphw]

Ich würde mal vermuten (kenne mich mit FX nicht aus), dass setStyle(null) die Standardeinstellungen wiederherstellt.

Jap, aber wo ist der Unterschied zwischen dem setStyle(null); wenn ich auf "Not Colored" stelle und dem setStyle(null); wenn ich "Colored" deselektiere. Und wo kommt der Höhenunterschied her, font size bleibt ja unverändert.

Was passiert denn, wenn Du z. B. node.setStyle("-fx-fill: black; -fx-text-fill: black;") verwendest?

Interessanterweise, das gleiche wie bei setStyle(null); also die Zeile verändert die Höhe.

 

[mihe7]

Interessanterweise, das gleiche wie bei setStyle(null); also die Zeile verändert die Höhe.

Dann habe ich keine Erklärung dafür. @dzim ?

 

[sascha-sphw]

Mir ist gerade aufgefallen, das es mit der Default Font nicht passiert, also nur wenn ich eine andere nehme.

 

[mihe7]

Das wird ja immer besser. Könnte mit der Font-Engine zusammenhängen. Ich weiß nicht, was da aktuell ist, vor ein paar Jahren habe ich mal was bauen müssen, wo die Metrics eine entscheidende Rolle spielten. Da gab es dann derart massive Unterschiede zwischen Windows und Linux, dass das in der Form nicht brauchbar war.

 

[sascha-sphw]

Ich habe jetzt mal ein ContextMenu eingebaut, das mir die Größen der einzelnen Nodes ausgibt. Folgendes konnte ich beobachten.

Deselektiert:

message childs:
child 'Text[text="This it the line number 0", x=0.0, y=0.0, alignment=LEFT, origin=BASELINE, boundsType=LOGICAL, font=Font[name=Consolas, family=Consolas, style=Regular, size=13.0], fontSmoothingType=GRAY, fill=0x000000ff]' -> pref w/h: 178,69/13,00
message -> w/h: 455,00/17,00, pref w/h: 179,00/13,00
rootNode -> w/h: 455,00/17,00, pref w/h: 179,00/13,00

Colored:

message childs:
child 'Text[text="This it the line number 0", x=0.0, y=0.0, alignment=LEFT, origin=BASELINE, boundsType=LOGICAL, font=Font[name=Consolas, family=Consolas, style=Regular, size=13.0], fontSmoothingType=GRAY, fill=0xff0000ff]' -> pref w/h: 178,69/13,00
message -> w/h: 455,00/16,00, pref w/h: 179,00/13,00
rootNode -> w/h: 455,00/16,00, pref w/h: 179,00/13,00

Es schein für mich so, als dass der Text seine Höhe nicht verändert, aber der Container (HBox) dennoch meint er müsse seine Höhe anpassen.

 

[mihe7]

Kannst ja mal einen Bug-Report einstellen - wäre interessant, was da rauskommt

 

[dzim]

War in den Ferien... Sorry.

Also Style ist schon etwas speziell und ich versuche die Verwendung davon so oft wie möglich zu vermeiden. Allein weil es auch schlecht zu warten ist.
Meine Alternative ist, wenn möglich, das Verwenden von Pseudo-Klassen (würde in dem konkreten Use-Case auch mehr Sinn ergebe aus meiner Sicht).

Aber zum Problem. Den Style auf Null setzen ist eine schlechte Idee. Ich glaube ich bin vor langer Zeit auch mal drüber gestolpert. Entweder ein leerer String, oder explizit die alternativen Werte verwenden. Null macht irgendetwas komisches, was vermutlich so nicht gewollt ist und was auch dem "default"-Wert entspricht - dieser ist IMHO "" (also ein leerer String).
Warum es sich genau so verhält... Keine Ahnung, aber CSS in JavaFX ist schon etwas... speziell. Sagen wir's mal so.
Ich denke auch, es wäre einen Bug-Report wert, aber solange würde ich einfach auf etwas "saubere" Methoden, wie Pseudo-Klassen oder immer explizites setzen aller gewünschten Styles (in allen Fällen, also Default, Deselektiert und Colored), setzen.

Und wenn du noch etwas mehr Untersuchen möchtest sind zwei Projekte empfehlenswert: CSSFX (https://github.com/McFoggy/cssfx) und Scenic View (https://github.com/JonathanGiles/scenic-view). Letzteres vor allem, weil du damit deine CSS-Klassen, -Pseudo-Klassen und -Styles live untersuchen kannst. Und eigentlich auch alle anderen Properties, wie Pref/Min/Max-Height aber auch reale Höhe, etc. Sehr nützliches Tool, hat mir schon sehr oft geholfen, wenn ich knifflige Style-Anpassungen gemacht habe (hallo Table- und ListView! Argh! 💩).

 

[sascha-sphw]

War in den Ferien... Sorry.

Kein Thema. Antworten ist ja keine Pflicht.

Aber zum Problem. Den Style auf Null setzen ist eine schlechte Idee. Ich glaube ich bin vor langer Zeit auch mal drüber gestolpert. Entweder ein leerer String, oder explizit die alternativen Werte verwenden. Null macht irgendetwas komisches, was vermutlich so nicht gewollt ist und was auch dem "default"-Wert entspricht - dieser ist IMHO "" (also ein leerer String).

Habe ich auch versucht. Egal ob setStyle(null), setStyle("") oder setStyle("-fx-fill: black; -fx-text-fill: black;"), das Ergebnis war, zumindest bei mir, exakt das Gleiche. Aber der Punkt ist ja der, wenn Du auf "Not Colored" stellst, läuft ja der selbe code der auch beim Deselektieren durchlaufen wird, dennoch ist das Ergebnis eine Veränderung der Höhe.
Es scheint (für mich) auch weniger mit dem Styling an sich zu tun zu haben, da sich die Höhe der Text Node ja nicht verändert.

Meine Alternative ist, wenn möglich, das Verwenden von Pseudo-Klassen (würde in dem konkreten Use-Case auch mehr Sinn ergebe aus meiner Sicht).

Ich verstehe nicht ganz wie Du das meinst, hast Du ein Beispiel hierfür? Wir reden schon über das gleiche (https://developer.mozilla.org/de/docs/Web/CSS/Pseudo-classes), oder?

Das Projekt ist auch nur ein minimal Beispiel um das Problem zu fokussieren. Im echten Projekt (https://www.softpagehomeware.de/products/logviewer), kann der User die Farben (Text/Background) selbst über die UI festlegen.

Ich habe dann auch noch ein wenig weiter rum probiert um zu sehen ob das Verhalten ohne ListCell (also nur HBox -> Text), auch zu beobachten ist. Ist es aber nicht, hier funktioniert alles wie erwartet.

Mein aktueller Workaround ist, die prefHeight der ListCell auf die eingestellte Schriftgröße + Padding zu setzen, funktioniert erst mal.

Einen Bug Eintrag werde ich demnächst noch machen, aber ich denke das es was mit einer fehlerhaften Berechnung der ListCell Size zu tun hat, dafür habe ich so einiges gefunden, unter anderem auch Bug Einträge.

Und wenn du noch etwas mehr Untersuchen möchtest sind zwei Projekte empfehlenswert: CSSFX (https://github.com/McFoggy/cssfx) und Scenic View (https://github.com/JonathanGiles/scenic-view). Letzteres vor allem, weil du damit deine CSS-Klassen, -Pseudo-Klassen und -Styles live untersuchen kannst. Und eigentlich auch alle anderen Properties, wie Pref/Min/Max-Height aber auch reale Höhe, etc. Sehr nützliches Tool, hat mir schon sehr oft geholfen, wenn ich knifflige Style-Anpassungen gemacht habe (hallo Table- und ListView! Argh! 💩).

Werde ich mal ausprobieren. Danke für die Links!

 

[dzim]

Habe ich auch versucht. Egal ob setStyle(null), setStyle("") oder setStyle("-fx-fill: black; -fx-text-fill: black;"), das Ergebnis war, zumindest bei mir, exakt das Gleiche. Aber der Punkt ist ja der, wenn Du auf "Not Colored" stellst, läuft ja der selbe code der auch beim Deselektieren durchlaufen wird, dennoch ist das Ergebnis eine Veränderung der Höhe.
Es scheint (für mich) auch weniger mit dem Styling an sich zu tun zu haben, da sich die Höhe der Text Node ja nicht verändert.

Doch doch, das ist schon vom Styling abhängig! Das null setzen, bzw. das allgmeine Manipulieren des Styles hat Auswirkungen und du triggerst deine applyStyle Methode ja auf öfter.

Aber mal kurz zu deinem Code:

    @Override
    protected void updateItem(ListItemModel item, boolean empty) {
        super.updateItem(item, empty);
        setText(null); // use ""
        message.getChildren().clear();
        // this::applyStyle creates a new lambda each time
        // create a variable like so: private InvalidationListener listener = this::applyStyle;
        // add and remove this listener instead of this:applyStyle
        selectedGroup.removeListener(this::applyStyle);
        if (empty || item == null) {
            // clean up here instead of always? at least reset the style here as well!
            return;
        }
        selectedGroup.addListener(this::applyStyle);
        message.getChildren().add(new Text(item.text));
        applyStyle(null);
    }

Auch wenn der Code nur eine Demo ist (finde aber gut, dass du das gemacht hast!), ist hier noch Verbessungspotential vorhanden.

Ich verstehe nicht ganz wie Du das meinst, hast Du ein Beispiel hierfür? Wir reden schon über das gleiche (https://developer.mozilla.org/de/docs/Web/CSS/Pseudo-classes), oder?

Ja genau.

Veraltet: Siehe z.B. hier https://docs.oracle.com/javase/8/javafx/user-interface-tutorial/apply-css.htm und hier https://docs.oracle.com/javase/8/javafx/api/javafx/scene/doc-files/cssref.html.

JavaFX 14:

• https://openjfx.io/javadoc/14/javafx.graphics/javafx/scene/doc-files/cssref.html
• https://openjfx.io/javadoc/14/javafx.graphics/javafx/css/PseudoClass.html
• https://thierrywasyl.wordpress.com/2018/08/14/style-class-vs-pseudoclass-in-javafx/

Im Prinzip ist es dann so, dass du dann so eine Pseudo-Klasse wie in den Beispielen "anlegst" und dann auf den Controls immer nur "true" oder "false" für aktiv/inaktiv setzen musst. Ist, wenn man es einmal verwendet hat, recht einfach.

Mein aktueller Workaround ist, die prefHeight der ListCell auf die eingestellte Schriftgröße + Padding zu setzen, funktioniert erst mal.

Ich bin mir nicht mehr ganz sicher, aber ich glaube bei mir waren solche Workarounds auch ab und an nötig...

 

[sascha-sphw]

Auch wenn der Code nur eine Demo ist (finde aber gut, dass du das gemacht hast!), ist hier noch Verbessungspotential vorhanden.

Make It Work Make It Right Make It Fast. 😉

Ja genau.

Veraltet: Siehe z.B. hier https://docs.oracle.com/javase/8/javafx/user-interface-tutorial/apply-css.htm und hier https://docs.oracle.com/javase/8/javafx/api/javafx/scene/doc-files/cssref.html.

JavaFX 14:

• https://openjfx.io/javadoc/14/javafx.graphics/javafx/scene/doc-files/cssref.html
• https://openjfx.io/javadoc/14/javafx.graphics/javafx/css/PseudoClass.html
• https://thierrywasyl.wordpress.com/2018/08/14/style-class-vs-pseudoclass-in-javafx/

Im Prinzip ist es dann so, dass du dann so eine Pseudo-Klasse wie in den Beispielen "anlegst" und dann auf den Controls immer nur "true" oder "false" für aktiv/inaktiv setzen musst. Ist, wenn man es einmal verwendet hat, recht einfach.

Werde ich mir mal genauer anschauen. Danke nochmal an dieser Stelle!

 

[sascha-sphw]

Nachdem ich ein neues Feature (Word Wrap) in meinen LogViewer eingebaut habe, musste ich mich nochmal etwas intensiver mit diesem Thema beschäftigen und konnte es lösen, indem ich die Höhe einfach selbst berechne, dazu habe ich einfach die folgenden beiden Methoden überschrieben.

@Override
protected double computeMinWidth(double height) {
    return message.minWidth(height) + message.getInsets().getTop() + message.getInsets().getBottom();
}

@Override
protected double computePrefHeight(double width) {
    return message.prefHeight(width) + message.getInsets().getTop() + message.getInsets().getBottom();
}

Falls es jemand brauchen kann. Der Source liegt jetzt auf Bitbucket.

Log in with Atlassian account

Log in to Jira, Confluence, and all other Atlassian Cloud products here. Not an Atlassian user? Sign up for free.

bitbucket.org

 

[sascha-sphw]

Hier ist es jetzt auch public. :-D

Bitbucket

bitbucket.org

 

[sascha-sphw]

Nachdem ich ein neues Feature (Word Wrap) in meinen LogViewer eingebaut habe, musste ich mich nochmal etwas intensiver mit diesem Thema beschäftigen und konnte es lösen, indem ich die Höhe einfach selbst berechne, dazu habe ich einfach die folgenden beiden Methoden überschrieben.

@Override
protected double computeMinWidth(double height) {
    return message.minWidth(height) + message.getInsets().getTop() + message.getInsets().getBottom();
}

@Override
protected double computePrefHeight(double width) {
    return message.prefHeight(width) + message.getInsets().getTop() + message.getInsets().getBottom();
}

Falls es jemand brauchen kann. Der Source liegt jetzt auf Bitbucket.

Log in with Atlassian account

Log in to Jira, Confluence, and all other Atlassian Cloud products here. Not an Atlassian user? Sign up for free.

bitbucket.org

Es sollte computeMinHeight sein nicht computeMinWidth...

@Override
protected double computeMinHeight(double width) {
    return message.minHeight(width) + message.getInsets().getTop() + message.getInsets().getBottom();
}

@Override
protected double computePrefHeight(double width) {
    return message.prefHeight(width) + message.getInsets().getTop() + message.getInsets().getBottom();
}