Re: Converting from svg format to javafx css svg
For JavaFX 8, please refer to http://download.java.net/jdk8/jfxdocs/javafx/scene/doc-files/cssref.html You can use -fx-min-width, -fx-pref-width, -fx-max-width and corresponding height properties to set region size. Best regards, Alexander Kouznetsov (408) 276-0387 On 15 дек 2013 11:17, Pedro Duque Vieira wrote: I think it is an interesting use of CSS - sizing stuff.. I think its the only way that currently exists, i.e. using padding. P.s.: what happened to the width and height property that was discussed in this mailing list? On Dec 15, 2013 7:11 AM, Gerrit Grunwald han.s...@muenster.de wrote: Hi Pedro, If you set -fx-scale-shape: true; you just have to know the aspect ratio of your svg path and can control the size of the Region in Java code (either in the skin or in the region class). To be honest I never tried to size a shape by using only padding in css. Cheers, Gerrit Am 15.12.2013 um 07:37 schrieb Pedro Duque Vieira pedro.duquevie...@gmail.com: Hi Gerrit, Yeah, thanks putting -fx-scale-shape: false does make the svg shape the original size as seen in Illustrator. I'm still left with a doubt though, you say you resize the region to make the svg the way you want to, how do you do that? programmatically, through java? How about doing it through CSS? That's why I was using padding, but I don't want to disrupt the aspect ratio.. Thanks, best regards, On Sat, Dec 14, 2013 at 11:47 PM, Gerrit Grunwald han.s...@muenster.dewrote: Hi Pedro, If I got you right you have scaling problems with the -fx-shape in css right? So if you use -fx-scale-shape: false; the svg path should be exactly the same size as the original path from Illustrator and if you would like to scale the shape to the size of the Region you just set it to true and set the size if the Region to the size you need the svg path. If your svg path has a certain aspect-ratio you should take care about it by resizing the Region correctly. That is the way I use it everywhere and it works really nicely. I usually don't use the padding for the svg path in css to resize it. Just my 0.02€... Cheers, Gerrit Am 14.12.2013 um 22:00 schrieb Pedro Duque Vieira pedro.duquevie...@gmail.com: Hi, While working in JMetro (Metro like controls for javafx) I have the following process for creating svg graphics using javafx css: 1- I create the vector graphics in Adobe Illustrator 2- save the file in svg format 3- get the svg path notation from the svg file and use it with javafx -fx-shape css property The thing that I haven't still mastered is how does the size of the vector graphics in Illustrastor translate to the size I have to input in the -fx-padding css property. I know I have to enter half the value of width for the left and right and half the value of the height for the top and bottom but still that doesn't seem to work. It's still more of a process of trial and error for me. Thanks in advance. -- Pedro Duque Vieira -- Pedro Duque Vieira
Re: Progress Bar into Combo Box is not working properly
You shouldn't mix ComboBox data items and JavaFX nodes. So change ComboBoxVBox to ComboBoxMyData. Next, you can set ProgressBars as ListCell graphics as you already do. And make sure that each cell has its own ProgressBar node. Nodes cannot be present several times in the scenegraph. That's why there is the following situation: selected node cannot appear in the list of nodes at the same time: Your example also has some code to hide combobox which is confusing as it is not related to the question. Best regards, Alexander Kouznetsov (408) 276-0387 On 16 дек 2013 18:18, Peter Penzov wrote: Hi All, I want to implement Progress Bar into Combo Box. I pasted the code here: http://stackoverflow.com/questions/20518329/combobox-with-progress-bars-is-not-working-properly When I run the code the progress bar is empty. There is no selected Progress Bar which is displayed by default. And also after a time the progress bar is not responsible. I tested the code with Java 8b119. Maybe this is a bug. Can you please assist me to fix this issue? Regards, Peter
Re: Font.font() says it is point size but it looks like it are pixels
Tom,
Could you please file a bug on this?
Best regards,
Alexander Kouznetsov
(408) 276-0387
On 23 дек 2013 15:31, Tom Schindl wrote:
Hi,
The JavaDoc of Font.font says:
-8-
size - The point size of the font. This can be a fractional value, but
must not be negative. If the size is 0 the default size will be used.
-8-
I highly doubt this is correct (see attached picture from Linux where
you see native, qt and javafx) and a sample FX-Code using setFont and
using CSS (see at the end of this mail)
The result is correct if CSS is used and looking up the code in the CSS
shows that values are calculated back to pixels when passed to the
Font-factory method (FontConverter.convert!).
I guess one can not fix this Font.font API to really work with points
(which would be the natural expectation at least to me) but the JavaDoc
has to be fixed!
Another thing I came across is that the DPI calculation is fixed to 96
DPI - which i don't fully understand why it is fixed because the DPI can
vary between devices and monitors. Is this because of multi-monitors and
you are applying a transformation based on the screen the text is
rendered on?
Tom
---
HBox h = new HBox();
{
Text t = new Text(Hello World);
t.setFont(Font.font(50));
h.getChildren().add(t);
}
{
Text t = new Text(Hello World);
t.setStyle(-fx-font-size: 50pt;);
h.getChildren().add(t);
}
primaryStage.setScene(new Scene(h,300,300));
primaryStage.show();
hg: openjfx/8u-dev/rt: 2 new changesets
Changeset: fe834e7c49de Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2014-01-16 00:06 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/fe834e7c49de RT-35356 [Monocle] Implement keyboard input + modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/KeyInput.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/KeyState.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/MouseState.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/TouchInput.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/AbsoluteInputCapabilities.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxInputDevice.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxInputDeviceRegistry.java + modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxKeyProcessor.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxSystem.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/mx6/MX6Cursor.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/util/IntSet.java ! modules/graphics/src/main/native-glass/monocle/linux/LinuxSystem.c Changeset: 0de81508edf6 Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2014-01-16 11:15 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/0de81508edf6 RT-35380 [Monocle] Events are delivered to the window stack in reverse order ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleWindowManager.java
Re: [announce] InhiBeans: mitigate redundant recalculations
Hi Alexander,
On Thu, Jan 16, 2014 at 10:24 AM, Alexander Kouznetsov
alexander.kouznet...@oracle.com wrote:
There are two other options you may want to consider:
1) Use XXXBinding as following:
value.bind(new DoubleBinding() {
{ bind(widthProperty(), heightProperty()); }
@Override
protected Double computeValue() {
return widthProperty().get() * heightProperty().get();
}
}
this will perform the same invalidation mechanics for you as long as your
value is not requested immediately after change. JavaFX is mostly lazy so
if you, for example, bind it to some node's property it will be calculated
only once.
in the past I tried binding Label.textProperty() to a value like this and
it was calculated twice.
2) Use AnimationTimer. Its body is always invoked once per pulse so you
can do as much calculations you need once per pulse.
As I mentioned before, this only works when the result is not observable by
the client code. Otherwise it might be reasonable to assert the following:
obj.setWidth(w);
obj.setHeight(h);
assert obj.getArea() == w*h;
which is not true if area is only calculated on the next pulse.
Moreover, this approach doesn't scale. If you use the trick with next pulse
or runLater in several places in your code and then chain (bind) them, it
will take several pulses to propagate the change. Ironically, it then
doesn't even avoid multiple recalculations (e.g. analyze the case where
these parts depend on each other the way fibonacci numbers do: f[n+2] :=
f[n] + f[n+1]).
Regards,
Tomas
Best regards,
Alexander Kouznetsov
(408) 276-0387
On 15 дек 2013 23:30, John Hendrikx wrote:
Since you are only allowed to modify properties on the JavaFX thread (in
most cases), I've been using Platform.runLater() to make sure I observe
only complete changes.
Basically I register an InvalidationListener on the properties that are
relevant, and when one gets triggered I set a boolean and trigger a
Runnable that
will be run on the JavaFX thread later (and after the change completes).
The Runnable checks the relevant values and acts on them, then resets the
boolean.
I use this mechanism for example when I'm observing Objects with many
properties that need to be stored in a database. To make sure I only store
consistent objects, I only observe the values of the properties when my own
little piece of observer code runs on the JavaFX thread. Since nothing can
modify the properties except on the JavaFX thread, this is almost like a
form of transactions, ensuring that every change has completed before
observing the results.
--John
On 15/12/2013 18:39, Scott Palmer wrote:
Interesting idea.
There is a case I have been curious about and wonder what the best
practices are for it. Suppose you have a case when you are changing
multiple different properties that will be used in a single calculation.
You want to deal with a single change to all of them in one go. E.g.
imagine you have an area property that is bound to both width and
height. You want to write code like:
obj.setWidth(w);
obj.setHeight(h);
and have only ONE recalculation of the area property happen. Currently
the
way bindings work the area will be calculated twice. The intermediate
calculation is really not a value that you ever want to observe.
Are there helpers for this sort of situation? Are there guidelines in
the
JavaFX docs somewhere?
Regards,
Scott
On Sat, Dec 14, 2013 at 11:54 PM, Tomas Mikulatomas.mik...@gmail.com
wrote:
Hello,
I just published a small extension of javafx bindings and properties
that can help you reduce redundant recalculations.
They provide two additional methods:
public void block();
public void release();
Call p.block() when you suspect your actions will lead to multiple
invalidations of p, and call p.release() when you are done and want to
deliver a single invalidation notification to p's observers.
https://github.com/TomasMikula/InhiBeans
Regards,
Tomas
hg: openjfx/8u-dev/rt: 7 new changesets
Changeset: b7df69987d07 Author:David Grievedavid.gri...@oracle.com Date: 2014-01-16 08:01 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b7df69987d07 RT-31237: allow none as a css property value having the same semantics as null. ! modules/graphics/src/main/java/com/sun/javafx/css/converters/ColorConverter.java ! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSParser.java ! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java Changeset: fbc40f535dd4 Author:David Grievedavid.gri...@oracle.com Date: 2014-01-16 08:03 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/fbc40f535dd4 RT-30940: rework HelloLabelBorders. ! apps/toys/Hello/src/main/java/hello/HelloLabelBorders.java - apps/toys/Hello/src/main/java/hello/LabelBorders.css ! apps/toys/Hello/src/main/java/hello/hello.css Changeset: 9068ba8f3950 Author:David Grievedavid.gri...@oracle.com Date: 2014-01-16 08:03 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/9068ba8f3950 [DOCS ONLY] RT-27995: clarify default value of visibility propert in cssref. ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html Changeset: 8c1ff5eb1679 Author:David Grievedavid.gri...@oracle.com Date: 2014-01-16 08:03 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8c1ff5eb1679 [DOCS ONLY] RT-9178: add note to cssref regarding font inheritance ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html Changeset: c7499eb02a43 Author:David Grievedavid.gri...@oracle.com Date: 2014-01-16 08:03 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c7499eb02a43 RT-7413: clip has no parent. if a node has a clip, call impl_processCSS on the clip ! modules/graphics/src/main/java/javafx/scene/Node.java Changeset: e9afba41e211 Author:David Grievedavid.gri...@oracle.com Date: 2014-01-16 08:08 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e9afba41e211 Backed out changeset c7499eb02a43 ! modules/graphics/src/main/java/javafx/scene/Node.java Changeset: bd74f5138913 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-01-16 14:09 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/bd74f5138913 [JAVADOC] RT-35351 Fix javafx.scene.Node.setEventHandler javadoc ! modules/graphics/src/main/java/javafx/scene/Node.java
Strange exception in ComboBox
Hello, We have a strange exception in ComboBox at least since b121. We create a child stage with one combobox, and we systematically have an exception when clicking on an item in the list because of a child added to a parent (ComboBoxListViewSkin) without removing it from the previous one (ComboBox). - The list is composed of basic Strings - I checked and the Pane creation is performed in the JavaFX Thread - We did not set any specific skin to the scene we use - When I tried to copy the piece of code to test it separately from the whole app, it worked - There is no exception in Java 7 for the same exact code Is it something that could be related to a bug in Java 8, or do you think it must be a bug in our code ? Herve
hg: openjfx/8u-dev/rt: [JAVADOC] RT-35189 Scale documentation does not specify the default pivot
Changeset: 0236b4c3f472 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-01-16 14:18 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/0236b4c3f472 [JAVADOC] RT-35189 Scale documentation does not specify the default pivot ! modules/graphics/src/main/java/javafx/scene/transform/Rotate.java ! modules/graphics/src/main/java/javafx/scene/transform/Scale.java ! modules/graphics/src/main/java/javafx/scene/transform/Shear.java
hg: openjfx/8u-dev/rt: RT-35392 [Monocle] Correct window position in software rendering
Changeset: 5c06fa3e9703 Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2014-01-16 20:14 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/5c06fa3e9703 RT-35392 [Monocle] Correct window position in software rendering ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleView.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleWindow.java
Re: Strange exception in ComboBox
It's very hard to say without a test application and the exception stacktrace that you're seeing. If you could get those two things together and file them in a bug in jira, I can take a look. -- Jonathan On 17/01/2014 2:31 a.m., Hervé Girod wrote: Hello, We have a strange exception in ComboBox at least since b121. We create a child stage with one combobox, and we systematically have an exception when clicking on an item in the list because of a child added to a parent (ComboBoxListViewSkin) without removing it from the previous one (ComboBox). - The list is composed of basic Strings - I checked and the Pane creation is performed in the JavaFX Thread - We did not set any specific skin to the scene we use - When I tried to copy the piece of code to test it separately from the whole app, it worked - There is no exception in Java 7 for the same exact code Is it something that could be related to a bug in Java 8, or do you think it must be a bug in our code ? Herve
8u20 review request: RT-35355 - Software rendering ports of Monocle need notification of pixel upload end
Hi Kevin and Anthony, Would you review the following change to have Quantum notify Glass when it has finished rendering all scenes? This is to enable double-buffering on embedded and headless systems. https://javafx-jira.kenai.com/browse/RT-35355 http://cr.openjdk.java.net/~dblaukop/webrev-20140116-2022-RT-35355/webrev/ Thanks, Daniel
hg: openjfx/2u/dev/rt: Added tag 2.2.60-b03 for changeset fc533ffc2296
Changeset: b8fcc422cc09 Author:hudson Date: 2014-01-16 08:41 -0800 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/b8fcc422cc09 Added tag 2.2.60-b03 for changeset fc533ffc2296 ! .hgtags
Re: 8u20 review request: RT-35355 - Software rendering ports of Monocle need notification of pixel upload end
Dave suggested another way of does this, which I tried out and it seemed to work. Notes and link to patch are in the JIRA. Either approach is OK with me, but others might feel more strongly about it. Daniel On Jan 16, 2014, at 10:31 PM, Daniel Blaukopf daniel.blauk...@oracle.com wrote: Hi Kevin and Anthony, Would you review the following change to have Quantum notify Glass when it has finished rendering all scenes? This is to enable double-buffering on embedded and headless systems. https://javafx-jira.kenai.com/browse/RT-35355 http://cr.openjdk.java.net/~dblaukop/webrev-20140116-2022-RT-35355/webrev/ Thanks, Daniel
hg: openjfx/8u-dev/rt: 4 new changesets
Changeset: a4147a40b285
Author:David Grievedavid.gri...@oracle.com
Date: 2014-01-16 19:13 -0500
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a4147a40b285
RT-17334: check {h|v}valueProperty().isBound() before calling set
!
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java
Changeset: 30314ce7385c
Author:David Grievedavid.gri...@oracle.com
Date: 2014-01-16 19:13 -0500
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/30314ce7385c
RT-17395: if ScrollBarPolicy value is null, treat it as AS_NEEDED. Also changed
comparison of enum using equals method to using ==
!
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java
Changeset: 59da29c7f1b5
Author:David Grievedavid.gri...@oracle.com
Date: 2014-01-16 19:13 -0500
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/59da29c7f1b5
RT-18223: if ScrollBar is focusTraversable, requestFocus on certain mouse press
events (like a mouse press on increment button).
Reviewed by Jonathan
!
modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ScrollBarBehavior.java
Changeset: 89a4c84586c2
Author:David Grievedavid.gri...@oracle.com
Date: 2014-01-16 19:13 -0500
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/89a4c84586c2
[DOCS-ONLY] RT-18386: css lint on cssref.
! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html
Re: 8u20 review request: RT-35355 - Software rendering ports of Monocle need notification of pixel upload end
Dave suggested another way of does this, which I tried out and it seemed to work. Notes and link to patch are in the JIRA. Either approach is OK with me, but others might feel more strongly about it. Daniel On Jan 16, 2014, at 10:31 PM, Daniel Blaukopf daniel.blauk...@oracle.com wrote: Hi Kevin and Anthony, Would you review the following change to have Quantum notify Glass when it has finished rendering all scenes? This is to enable double-buffering on embedded and headless systems. https://javafx-jira.kenai.com/browse/RT-35355 http://cr.openjdk.java.net/~dblaukop/webrev-20140116-2022-RT-35355/webrev/ Thanks, Daniel
