Re: CSS under 1.8.0_40 not identical to 31 or older
Create an issue in JIRA and include a simple example that reproduces the
issue.
On 2/4/15 4:13 PM, Tom Eugelink wrote:
I've just now ran JFXtras Samples under the latest 1.8.0_40 and it
does not render identical as when run under 1.8.0_31, some CSS rules
are not applied. Samples is easily downloaded from here
(http://jfxtras.org/resources/java/jfxtras-labs-samples-8.0-r4-SNAPSHOT-shadow.jar)
and started simply with java -jar.
When run under 1.8.0_31 or older, the LocalDateTimeTextfieldSample
shows a textfield with a popup button. When the button is pressed a
popup is shown, with a gradient as the background and both an ok and
cancel icon in the right top. The exact same jar under 1.8.0_40 does
not show the gradient nor the two icons.
LocalDateTimeTextfield under water uses CalendarTextField, so the code
for this is in the calendar based control:
https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-controls/src/main/java/jfxtras/internal/scene/control/skin/CalendarTextFieldSkin.java
https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-controls/src/main/resources/jfxtras/internal/scene/control/CalendarTextField.css
Interesting are the lines starting at 351 in the skin, which do:
Popup lPopup = new Popup();
...
BorderPane lBorderPane = new BorderPane();
lBorderPane.getStyleClass().add(this.getClass().getSimpleName() +
_popup); // this amounts to CalendarTextFieldSkin_popup
...
lPopup.getContent().add(lBorderPane);
This no longer results in applying the background colors as defined in
the css file on line 12.
.CalendarTextFieldSkin_popup {
-fx-background-color: -fx-shadow-highlight-color,
-fx-outer-border, -fx-inner-border, -fx-body-color;
-fx-background-insets: 0 0 -1 0,0,1,2;
-fx-background-radius: 5,5,4,3;
-fx-padding: 0.77em 0.73em 0.75em 0.73em;
-fx-text-fill: -fx-text-base-color;
}
Neither are the two in the css defined icons applied to the ImageViews.
Is this intentional or a bug?
Tom
Re: Label prefHeight vs wrapText
Sorry to dig up this old thread. Just wanted to mention a much simpler workaround if a label inside a vbox does not wrap its text: label.setMinHeight(Region.USE_PREF_SIZE); As before the trick is to prevent vbox from reducing the label height below its pref height to preserve the wrapping - even if other children of the vbox need to be shrunk. Werner On 28.05.2014 18:10, Werner Lehmann wrote: Martin, thanks for the explanation. Feels good to finally understand this ;-) And while I created a ticket as per your suggestion... [#RT-37309] VBox: vshrink layout hint similar to vgrow ...it seems I can use this as a workaround: label1.minHeightProperty().bind(Bindings.createDoubleBinding( () - label1.prefHeight(vbox.getWidth()), vbox.widthProperty())); Maybe something similar could be made available per label boolean property. So basically the ability to ask a label to consider wrapping when calculating its minHeight... I can imagine that this might have made more sense as a default behavior: if people explicitly ask for wrapping text, they would probably accept a larger minHeight. Werner
Build farm for OpenJFX (on ARM)
Hi Johan, all, Following the announcement that JDK builds for ARM will no longer include JavaFX I started talking with the OpenJDK Adoption group (https://wiki.openjdk.java.net/display/Adoption/Main) about the possibility of using their CloudBees CI system to produce OpenJFX binaries (for all operating systems including ARM) as a way to help keep JavaFX alive on IoT devices. For those who don't know the Adoption group, its mission is to help developers get started with building OpenJDK, testing new features, submitting bug reports, and cleaning up code. Adoption has a CloudBees CI set up and I've been talking with Mani Sarkar (@theneomatrix369) about setting up an OpenJFX CI project with cross-compile support that builds OpenJFX for all archs. The cross-compile instructions here https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+ARM+Hard+Float are working great for me locally so now we're trying to work out how to move that to the cloud. I don't want to tread on anyone's toes here and we're not trying to become any kind of official source for JavaFX, just trying to make sure there's an easy way (e.g. binaries) for end users to add JavaFX to their ARM JDKs and to help people dip their toes into OpenJFX development as per the Adoption group's mission. Happy to coordinate on how we can make this useful and avoid any duplication of effort :) Personally, I'm a big fan of JavaFX and use it as the UI layer in JITWatch (https://github.com/AdoptOpenJDK/jitwatch/). I'm also into IoT and wearables and think JavaFX would be great on the new Raspberry Pi 2. Cheers, Chris @chriswhocodes
Re: Build farm for OpenJFX (on ARM)
On 2/5/15, 3:35 AM, Chris Newland wrote: Hi Chris, I have answering a few questions for Mani on getting a Linux Linux ARM build running on the Fedora based cloudbees setup. There are still some packages I am missing for a full Fedora 21 build related to desktop media, but the core builds fine now. (Any Fedora users out there that want to help me find the right media development packages ?) Pretty excited to see this moving forward. Was dabbling last night to move some of the packaging steps into the Open, so that when we have a Cloudbees build, it will have a simple output overlay bundle. Glad to hear the 'Building for ARM' Wiki worked out for you. I have put a lot of time into the Building part of the Wiki, and am always looking for corrections/clarifications. As for treading on toes - Kevin and I are really pleased that the community is picking up these builds. Hopefully we can end up with a stable and a development bundle to point people too. There has been a lot of work in ARM (Monocle, touch, and 3D) that has not made it into an official ARM bundle. Open projects take a community, and it is nice to see so many of you helping out. Speaking of helping out if people want to help with contributions, we need a Oracle Contributor Agreement http://www.oracle.com/technetwork/community/oca-486395.html on file before taking code changes. Dave Hi Johan, all, Following the announcement that JDK builds for ARM will no longer include JavaFX I started talking with the OpenJDK Adoption group (https://wiki.openjdk.java.net/display/Adoption/Main) about the possibility of using their CloudBees CI system to produce OpenJFX binaries (for all operating systems including ARM) as a way to help keep JavaFX alive on IoT devices. For those who don't know the Adoption group, its mission is to help developers get started with building OpenJDK, testing new features, submitting bug reports, and cleaning up code. Adoption has a CloudBees CI set up and I've been talking with Mani Sarkar (@theneomatrix369) about setting up an OpenJFX CI project with cross-compile support that builds OpenJFX for all archs. The cross-compile instructions here https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+ARM+Hard+Float are working great for me locally so now we're trying to work out how to move that to the cloud. I don't want to tread on anyone's toes here and we're not trying to become any kind of official source for JavaFX, just trying to make sure there's an easy way (e.g. binaries) for end users to add JavaFX to their ARM JDKs and to help people dip their toes into OpenJFX development as per the Adoption group's mission. Happy to coordinate on how we can make this useful and avoid any duplication of effort :) Personally, I'm a big fan of JavaFX and use it as the UI layer in JITWatch (https://github.com/AdoptOpenJDK/jitwatch/). I'm also into IoT and wearables and think JavaFX would be great on the new Raspberry Pi 2. Cheers, Chris @chriswhocodes -- David Hilldavid.h...@oracle.com Java Embedded Development A man's feet should be planted in his country, but his eyes should survey the world. -- George Santayana (1863 - 1952)
Re: Build farm for OpenJFX (on ARM)
Hi All, As per Chris's message and the tweet I got last night / this morning I'm updating you (which I was intending to do when the time was right), that we now have a successful OpenJFX build on Cloudbees, see https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/OpenJFX/. Our build farm is able to build an updated artefact each day. Currently its a Linux build, the ARM build is on its way, an issue with a dependency has hindered us, but once that is also successful you will be able to download both these binaries from the above Cloudbees location. I'll add to what Chris has mentioned, I was not aware of another initiative to build OpenJFX binaries and ours is to not duplicate the effort but make such opensource binaries related to OpenJDK available to everyone in the community. We need all the help you can give us. As you can see from the list on the cloud farm, something or the other always needs to be attended to. Thanks. Cheers, Mani On Thu, Feb 5, 2015 at 8:35 AM, Chris Newland cnewl...@chrisnewland.com wrote: Hi Johan, all, Following the announcement that JDK builds for ARM will no longer include JavaFX I started talking with the OpenJDK Adoption group (https://wiki.openjdk.java.net/display/Adoption/Main) about the possibility of using their CloudBees CI system to produce OpenJFX binaries (for all operating systems including ARM) as a way to help keep JavaFX alive on IoT devices. For those who don't know the Adoption group, its mission is to help developers get started with building OpenJDK, testing new features, submitting bug reports, and cleaning up code. Adoption has a CloudBees CI set up and I've been talking with Mani Sarkar (@theneomatrix369) about setting up an OpenJFX CI project with cross-compile support that builds OpenJFX for all archs. The cross-compile instructions here https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+ARM+Hard+Float are working great for me locally so now we're trying to work out how to move that to the cloud. I don't want to tread on anyone's toes here and we're not trying to become any kind of official source for JavaFX, just trying to make sure there's an easy way (e.g. binaries) for end users to add JavaFX to their ARM JDKs and to help people dip their toes into OpenJFX development as per the Adoption group's mission. Happy to coordinate on how we can make this useful and avoid any duplication of effort :) Personally, I'm a big fan of JavaFX and use it as the UI layer in JITWatch (https://github.com/AdoptOpenJDK/jitwatch/). I'm also into IoT and wearables and think JavaFX would be great on the new Raspberry Pi 2. Cheers, Chris @chriswhocodes -- @theNeomatrix369 http://twitter.com/theNeomatrix369* | **Blog http://neomatrix369.wordpress.com** | *LJC Associate LJC Advocate (@adoptopenjdk @adoptajsr programs) *Meet-a-Project - *MutabilityDetector https://github.com/MutabilityDetector* | **Bitbucket https://bitbucket.org/neomatrix369* * | **Github https://github.com/neomatrix369* * | **LinkedIn http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b* *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for Excellence, and success will come chasing after you!*
Re: Build farm for OpenJFX (on ARM)
Cool! On Feb 5, 2015, at 2:19 PM, Mani Sarkar sadhak...@gmail.com wrote: Hi All, As per Chris's message and the tweet I got last night / this morning I'm updating you (which I was intending to do when the time was right), that we now have a successful OpenJFX build on Cloudbees, see https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/OpenJFX/. Our build farm is able to build an updated artefact each day. Currently its a Linux build, the ARM build is on its way, an issue with a dependency has hindered us, but once that is also successful you will be able to download both these binaries from the above Cloudbees location. I'll add to what Chris has mentioned, I was not aware of another initiative to build OpenJFX binaries and ours is to not duplicate the effort but make such opensource binaries related to OpenJDK available to everyone in the community. We need all the help you can give us. As you can see from the list on the cloud farm, something or the other always needs to be attended to. Thanks. Cheers, Mani On Thu, Feb 5, 2015 at 8:35 AM, Chris Newland cnewl...@chrisnewland.com wrote: Hi Johan, all, Following the announcement that JDK builds for ARM will no longer include JavaFX I started talking with the OpenJDK Adoption group (https://wiki.openjdk.java.net/display/Adoption/Main) about the possibility of using their CloudBees CI system to produce OpenJFX binaries (for all operating systems including ARM) as a way to help keep JavaFX alive on IoT devices. For those who don't know the Adoption group, its mission is to help developers get started with building OpenJDK, testing new features, submitting bug reports, and cleaning up code. Adoption has a CloudBees CI set up and I've been talking with Mani Sarkar (@theneomatrix369) about setting up an OpenJFX CI project with cross-compile support that builds OpenJFX for all archs. The cross-compile instructions here https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+ARM+Hard+Float are working great for me locally so now we're trying to work out how to move that to the cloud. I don't want to tread on anyone's toes here and we're not trying to become any kind of official source for JavaFX, just trying to make sure there's an easy way (e.g. binaries) for end users to add JavaFX to their ARM JDKs and to help people dip their toes into OpenJFX development as per the Adoption group's mission. Happy to coordinate on how we can make this useful and avoid any duplication of effort :) Personally, I'm a big fan of JavaFX and use it as the UI layer in JITWatch (https://github.com/AdoptOpenJDK/jitwatch/). I'm also into IoT and wearables and think JavaFX would be great on the new Raspberry Pi 2. Cheers, Chris @chriswhocodes -- @theNeomatrix369 http://twitter.com/theNeomatrix369* | **Blog http://neomatrix369.wordpress.com** | *LJC Associate LJC Advocate (@adoptopenjdk @adoptajsr programs) *Meet-a-Project - *MutabilityDetector https://github.com/MutabilityDetector* | **Bitbucket https://bitbucket.org/neomatrix369* * | **Github https://github.com/neomatrix369* * | **LinkedIn http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b* *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for Excellence, and success will come chasing after you!*
Re: Build farm for OpenJFX (on ARM)
Hi David, I've just tried to build the soft float version following the instructions on the wiki. However when doing a 'gradle -PCOMPILE_TARGETS=armv6sf'. It complains 'Error: missing tool packages: [arm-linaro-4.7.tgz]'. I assume the shellscript that downloads the cross compiler tools is missing some libraries (?). Installing 'gcc-arm-linux-gnueabi' didn't solve it either. Erik On Thu, Feb 5, 2015 at 3:46 PM, David Hill david.h...@oracle.com wrote: On 2/5/15, 3:35 AM, Chris Newland wrote: Hi Chris, I have answering a few questions for Mani on getting a Linux Linux ARM build running on the Fedora based cloudbees setup. There are still some packages I am missing for a full Fedora 21 build related to desktop media, but the core builds fine now. (Any Fedora users out there that want to help me find the right media development packages ?) Pretty excited to see this moving forward. Was dabbling last night to move some of the packaging steps into the Open, so that when we have a Cloudbees build, it will have a simple output overlay bundle. Glad to hear the 'Building for ARM' Wiki worked out for you. I have put a lot of time into the Building part of the Wiki, and am always looking for corrections/clarifications. As for treading on toes - Kevin and I are really pleased that the community is picking up these builds. Hopefully we can end up with a stable and a development bundle to point people too. There has been a lot of work in ARM (Monocle, touch, and 3D) that has not made it into an official ARM bundle. Open projects take a community, and it is nice to see so many of you helping out. Speaking of helping out if people want to help with contributions, we need a Oracle Contributor Agreement http://www.oracle.com/ technetwork/community/oca-486395.html on file before taking code changes. Dave Hi Johan, all, Following the announcement that JDK builds for ARM will no longer include JavaFX I started talking with the OpenJDK Adoption group (https://wiki.openjdk.java.net/display/Adoption/Main) about the possibility of using their CloudBees CI system to produce OpenJFX binaries (for all operating systems including ARM) as a way to help keep JavaFX alive on IoT devices. For those who don't know the Adoption group, its mission is to help developers get started with building OpenJDK, testing new features, submitting bug reports, and cleaning up code. Adoption has a CloudBees CI set up and I've been talking with Mani Sarkar (@theneomatrix369) about setting up an OpenJFX CI project with cross-compile support that builds OpenJFX for all archs. The cross-compile instructions here https://wiki.openjdk.java.net/display/OpenJFX/Cross+ Building+for+ARM+Hard+Float are working great for me locally so now we're trying to work out how to move that to the cloud. I don't want to tread on anyone's toes here and we're not trying to become any kind of official source for JavaFX, just trying to make sure there's an easy way (e.g. binaries) for end users to add JavaFX to their ARM JDKs and to help people dip their toes into OpenJFX development as per the Adoption group's mission. Happy to coordinate on how we can make this useful and avoid any duplication of effort :) Personally, I'm a big fan of JavaFX and use it as the UI layer in JITWatch (https://github.com/AdoptOpenJDK/jitwatch/). I'm also into IoT and wearables and think JavaFX would be great on the new Raspberry Pi 2. Cheers, Chris @chriswhocodes -- David Hilldavid.h...@oracle.com Java Embedded Development A man's feet should be planted in his country, but his eyes should survey the world. -- George Santayana (1863 - 1952)
Re: CSS under 1.8.0_40 not identical to 31 or older
FWIW, we are also experiencing css differences between 8u25 and 8u40. In some custom controls portions appear completely unstyled on 8u40, as if the selectors would stop working. Couldn't take a closer look so far due to time constraints... Werner
Re: CSS under 1.8.0_40 not identical to 31 or older
Luckily I had a test project still available from a previous CSS issue, so a
simple test was easily created.
https://javafx-jira.kenai.com/browse/RT-39995
Now I only need a way to attach a file to that issue...
Tom
On 5-2-2015 16:47, David Grieve wrote:
Create an issue in JIRA and include a simple example that reproduces the issue.
On 2/4/15 4:13 PM, Tom Eugelink wrote:
I've just now ran JFXtras Samples under the latest 1.8.0_40 and it does not render
identical as when run under 1.8.0_31, some CSS rules are not applied. Samples is easily
downloaded from here
(http://jfxtras.org/resources/java/jfxtras-labs-samples-8.0-r4-SNAPSHOT-shadow.jar) and
started simply with java -jar.
When run under 1.8.0_31 or older, the LocalDateTimeTextfieldSample shows a
textfield with a popup button. When the button is pressed a popup is shown, with a
gradient as the background and both an ok and cancel icon in the right top. The exact
same jar under 1.8.0_40 does not show the gradient nor the two icons.
LocalDateTimeTextfield under water uses CalendarTextField, so the code for this
is in the calendar based control:
https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-controls/src/main/java/jfxtras/internal/scene/control/skin/CalendarTextFieldSkin.java
https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-controls/src/main/resources/jfxtras/internal/scene/control/CalendarTextField.css
Interesting are the lines starting at 351 in the skin, which do:
Popup lPopup = new Popup();
...
BorderPane lBorderPane = new BorderPane();
lBorderPane.getStyleClass().add(this.getClass().getSimpleName() + _popup); // this
amounts to CalendarTextFieldSkin_popup
...
lPopup.getContent().add(lBorderPane);
This no longer results in applying the background colors as defined in the css
file on line 12.
.CalendarTextFieldSkin_popup {
-fx-background-color: -fx-shadow-highlight-color, -fx-outer-border,
-fx-inner-border, -fx-body-color;
-fx-background-insets: 0 0 -1 0,0,1,2;
-fx-background-radius: 5,5,4,3;
-fx-padding: 0.77em 0.73em 0.75em 0.73em;
-fx-text-fill: -fx-text-base-color;
}
Neither are the two in the css defined icons applied to the ImageViews.
Is this intentional or a bug?
Tom
Re: CSS under 1.8.0_40 not identical to 31 or older
Thanks, Tom. Send me the source and I'll attach it on your behalf.
On 2/5/15 1:08 PM, Tom Eugelink wrote:
Luckily I had a test project still available from a previous CSS
issue, so a simple test was easily created.
https://javafx-jira.kenai.com/browse/RT-39995
Now I only need a way to attach a file to that issue...
Tom
On 5-2-2015 16:47, David Grieve wrote:
Create an issue in JIRA and include a simple example that reproduces
the issue.
On 2/4/15 4:13 PM, Tom Eugelink wrote:
I've just now ran JFXtras Samples under the latest 1.8.0_40 and it
does not render identical as when run under 1.8.0_31, some CSS rules
are not applied. Samples is easily downloaded from here
(http://jfxtras.org/resources/java/jfxtras-labs-samples-8.0-r4-SNAPSHOT-shadow.jar)
and started simply with java -jar.
When run under 1.8.0_31 or older, the LocalDateTimeTextfieldSample
shows a textfield with a popup button. When the button is pressed a
popup is shown, with a gradient as the background and both an ok and
cancel icon in the right top. The exact same jar under 1.8.0_40 does
not show the gradient nor the two icons.
LocalDateTimeTextfield under water uses CalendarTextField, so the
code for this is in the calendar based control:
https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-controls/src/main/java/jfxtras/internal/scene/control/skin/CalendarTextFieldSkin.java
https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-controls/src/main/resources/jfxtras/internal/scene/control/CalendarTextField.css
Interesting are the lines starting at 351 in the skin, which do:
Popup lPopup = new Popup();
...
BorderPane lBorderPane = new BorderPane();
lBorderPane.getStyleClass().add(this.getClass().getSimpleName() +
_popup); // this amounts to CalendarTextFieldSkin_popup
...
lPopup.getContent().add(lBorderPane);
This no longer results in applying the background colors as defined
in the css file on line 12.
.CalendarTextFieldSkin_popup {
-fx-background-color: -fx-shadow-highlight-color,
-fx-outer-border, -fx-inner-border, -fx-body-color;
-fx-background-insets: 0 0 -1 0,0,1,2;
-fx-background-radius: 5,5,4,3;
-fx-padding: 0.77em 0.73em 0.75em 0.73em;
-fx-text-fill: -fx-text-base-color;
}
Neither are the two in the css defined icons applied to the ImageViews.
Is this intentional or a bug?
Tom
Re: CSS under 1.8.0_40 not identical to 31 or older
Thanks, David.
-- Kevin
David Grieve wrote:
Thanks, Tom. Send me the source and I'll attach it on your behalf.
On 2/5/15 1:08 PM, Tom Eugelink wrote:
Luckily I had a test project still available from a previous CSS
issue, so a simple test was easily created.
https://javafx-jira.kenai.com/browse/RT-39995
Now I only need a way to attach a file to that issue...
Tom
On 5-2-2015 16:47, David Grieve wrote:
Create an issue in JIRA and include a simple example that reproduces
the issue.
On 2/4/15 4:13 PM, Tom Eugelink wrote:
I've just now ran JFXtras Samples under the latest 1.8.0_40 and it
does not render identical as when run under 1.8.0_31, some CSS
rules are not applied. Samples is easily downloaded from here
(http://jfxtras.org/resources/java/jfxtras-labs-samples-8.0-r4-SNAPSHOT-shadow.jar)
and started simply with java -jar.
When run under 1.8.0_31 or older, the
LocalDateTimeTextfieldSample shows a textfield with a popup
button. When the button is pressed a popup is shown, with a
gradient as the background and both an ok and cancel icon in the
right top. The exact same jar under 1.8.0_40 does not show the
gradient nor the two icons.
LocalDateTimeTextfield under water uses CalendarTextField, so the
code for this is in the calendar based control:
https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-controls/src/main/java/jfxtras/internal/scene/control/skin/CalendarTextFieldSkin.java
https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-controls/src/main/resources/jfxtras/internal/scene/control/CalendarTextField.css
Interesting are the lines starting at 351 in the skin, which do:
Popup lPopup = new Popup();
...
BorderPane lBorderPane = new BorderPane();
lBorderPane.getStyleClass().add(this.getClass().getSimpleName() +
_popup); // this amounts to CalendarTextFieldSkin_popup
...
lPopup.getContent().add(lBorderPane);
This no longer results in applying the background colors as defined
in the css file on line 12.
.CalendarTextFieldSkin_popup {
-fx-background-color: -fx-shadow-highlight-color,
-fx-outer-border, -fx-inner-border, -fx-body-color;
-fx-background-insets: 0 0 -1 0,0,1,2;
-fx-background-radius: 5,5,4,3;
-fx-padding: 0.77em 0.73em 0.75em 0.73em;
-fx-text-fill: -fx-text-base-color;
}
Neither are the two in the css defined icons applied to the
ImageViews.
Is this intentional or a bug?
Tom
Re: CSS under 1.8.0_40 not identical to 31 or older
If the code sample is small (a small number of reasonably short files)
then just paste it in the comments. Otherwise, you can e-mail it as a
zip file to one of the developers @ Oracle (either myself or the
assigned engineer for the bug).
-- Kevin
Tom Eugelink wrote:
Luckily I had a test project still available from a previous CSS
issue, so a simple test was easily created.
https://javafx-jira.kenai.com/browse/RT-39995
Now I only need a way to attach a file to that issue...
Tom
On 5-2-2015 16:47, David Grieve wrote:
Create an issue in JIRA and include a simple example that reproduces
the issue.
On 2/4/15 4:13 PM, Tom Eugelink wrote:
I've just now ran JFXtras Samples under the latest 1.8.0_40 and it
does not render identical as when run under 1.8.0_31, some CSS rules
are not applied. Samples is easily downloaded from here
(http://jfxtras.org/resources/java/jfxtras-labs-samples-8.0-r4-SNAPSHOT-shadow.jar)
and started simply with java -jar.
When run under 1.8.0_31 or older, the LocalDateTimeTextfieldSample
shows a textfield with a popup button. When the button is pressed a
popup is shown, with a gradient as the background and both an ok and
cancel icon in the right top. The exact same jar under 1.8.0_40 does
not show the gradient nor the two icons.
LocalDateTimeTextfield under water uses CalendarTextField, so the
code for this is in the calendar based control:
https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-controls/src/main/java/jfxtras/internal/scene/control/skin/CalendarTextFieldSkin.java
https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-controls/src/main/resources/jfxtras/internal/scene/control/CalendarTextField.css
Interesting are the lines starting at 351 in the skin, which do:
Popup lPopup = new Popup();
...
BorderPane lBorderPane = new BorderPane();
lBorderPane.getStyleClass().add(this.getClass().getSimpleName() +
_popup); // this amounts to CalendarTextFieldSkin_popup
...
lPopup.getContent().add(lBorderPane);
This no longer results in applying the background colors as defined
in the css file on line 12.
.CalendarTextFieldSkin_popup {
-fx-background-color: -fx-shadow-highlight-color,
-fx-outer-border, -fx-inner-border, -fx-body-color;
-fx-background-insets: 0 0 -1 0,0,1,2;
-fx-background-radius: 5,5,4,3;
-fx-padding: 0.77em 0.73em 0.75em 0.73em;
-fx-text-fill: -fx-text-base-color;
}
Neither are the two in the css defined icons applied to the ImageViews.
Is this intentional or a bug?
Tom
Re: Build farm for OpenJFX (on ARM)
On 2/5/15, 11:47 AM, Erik De Rijcke wrote:
Hi David,
I've just tried to build the soft float version following the instructions on
the wiki. However when doing a 'gradle -PCOMPILE_TARGETS=armv6sf'. It complains
'Error: missing tool packages: [arm-linaro-4.7.tgz]'.
I assume the shellscript that downloads the cross compiler tools is missing
some libraries (?). Installing 'gcc-arm-linux-gnueabi' didn't solve it either.
Not many uses for soft float - Pi and most everyone else has moved to hard
float for the aprox 10% gain in performance.
The instructions on the Wiki deal with creating a tool chain for hard float and
then building with it.
Due to the relative lack of interest in soft float, I have not spent much time
working on the soft float side.
To work around this (at least to start, I don't have time to check it fully out
at the moment)
you would want to create a soft float toolchain using
buildSrc/crosslibs/crosslibs-armv6sf.sh, which you said you did :-)
That should create ../crosslibs. In there create a directory arm-linaro-4.7.
That should shut up the error message.
But... you will still need a cross compiler installed. So you can either make
that directory a link to your cross compiler, or you can use the gradle magic
override you can find in armv6sf.gradle:
if (rootProject.hasProperty(ARMV6SF_COMPILER)) {
logger.quiet Using alternate ARMV6SF_COMPILER
$rootProject.ARMV6SF_COMPILER
compilerHome=file(rootProject.ARMV6SF_COMPILER);
}
if (rootProject.hasProperty(ARMV6SF_COMPILER_PREFIX)) {
logger.quiet Using alternate ARMV6SF_COMPILER_PREFIX
$rootProject.ARMV6SF_COMPILER_PREFIX
compilerPrefix=${rootProject.ARMV6SF_COMPILER_PREFIX}
}
So you would add -PARMV6SF_COMPILER=/path_to_your_cross_compiler
-PARMV6SF_COMPILER_PREFIX=arm-linux-gnueabi-
to your gradle line, changing stuff as needed.
Dave
Erik
On Thu, Feb 5, 2015 at 3:46 PM, David Hill david.h...@oracle.com
mailto:david.h...@oracle.com wrote:
On 2/5/15, 3:35 AM, Chris Newland wrote:
Hi Chris,
I have answering a few questions for Mani on getting a Linux Linux ARM
build running on the Fedora based cloudbees setup. There are still some packages I
am missing for a full Fedora 21 build related to desktop media, but the core builds
fine now. (Any Fedora users out there that want to help me find the right media
development packages ?)
Pretty excited to see this moving forward. Was dabbling last night to move some of
the packaging steps into the Open, so that when we have a Cloudbees build, it
will have a simple output overlay bundle.
Glad to hear the 'Building for ARM' Wiki worked out for you. I have put a lot of time
into the Building part of the Wiki, and am always looking for
corrections/clarifications.
As for treading on toes - Kevin and I are really pleased that the community
is picking up these builds. Hopefully we can end up with a stable and a
development bundle to point people too. There has been a lot of work in ARM
(Monocle, touch, and 3D) that has not made it into an official ARM bundle.
Open projects take a community, and it is nice to see so many of you
helping out.
Speaking of helping out if people want to help with contributions, we need a
Oracle Contributor Agreement
http://www.oracle.com/technetwork/community/oca-486395.html on file before
taking code changes.
Dave
Hi Johan, all,
Following the announcement that JDK builds for ARM will no longer
include
JavaFX I started talking with the OpenJDK Adoption group
(https://wiki.openjdk.java.net/display/Adoption/Main) about the
possibility of using their CloudBees CI system to produce OpenJFX
binaries
(for all operating systems including ARM) as a way to help keep JavaFX
alive on IoT devices.
For those who don't know the Adoption group, its mission is to help
developers get started with building OpenJDK, testing new features,
submitting bug reports, and cleaning up code.
Adoption has a CloudBees CI set up and I've been talking with Mani
Sarkar
(@theneomatrix369) about setting up an OpenJFX CI project with
cross-compile support that builds OpenJFX for all archs.
The cross-compile instructions here
https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+ARM+Hard+Float
are working great for me locally so now we're trying to work out how to
move that to the cloud.
I don't want to tread on anyone's toes here and we're not trying to
become
any kind of official source for JavaFX, just trying to make sure there's
an easy way (e.g. binaries) for end users to add JavaFX to their ARM
JDKs
and to help people dip their toes into OpenJFX development as per the
Adoption group's mission.
Happy to coordinate on how we can make this useful and avoid any
duplication of effort :)
