Re: Half-baked API (Camera position)
Could do something useful with what was there now? We can always fix this in future by adding another API to govern the interpretation of the value. Throwing the exception indicates that the call is unsupported, but application code can be written to catch the exception and when we implement the API, it can break (I realize that this is unlikely). Steve On 2013-10-16 10:46 AM, Richard Bair wrote: My quick vote would be throwing the exception, but is like to hear from Steve and Kevin. On Oct 16, 2013, at 1:04 AM, Pavel Safrata pavel.safr...@oracle.com wrote: Hello, it looks like we can't help releasing a not-fully-baked piece of API with FX8. We've added bunch of new APIs for 3D and did our best to make them work well. Unfortunately, there's been not enough timepriority to fine-tune their behavior in 2D world. Right now I'm concerned about camera position in scene. It is inherent in the 3D perspective camera that it has its specific position in world, but the 2D parallel camera as we have it projects everything to the XY plane basically by ignoring the Z coordinate, so the camera position doesn't matter all that much. However, some of the newly added APIs depend on it: 1. Near/far clip on camera. This obviously cannot work without knowing where the camera is. Right now the parallel camera does no clipping though, so I guess we are OK to go with it as a known limitation. 2. PickResult on events which reports intersectedDistance between the camera and the picked point. This is worse because we can't just not support it - there will be some value and once somebody uses it we'll have a backward compatibility issue. The state right now is that the camera is (tentatively, by my arbitrary decision) at [0, 0, -1] and reports distances from there (note that as the camera renders everything, for nodes in front of Z=-1 it reports negative distances). This may change when the camera position is properly discussed and specified. Note that this post is *not* meant to discuss the camera position. Even if we could find the answer quickly (which I doubt), it's most probably too late to apply the change for FX8. So finally here is my question: do you think it's OK to solve this by keeping the current behavior and documenting the intersectedDistance in a way that for parallel camera the numbers are unspecified and subject to change in future versions? Or would you prefer something more drastic like throwing an UnsupportedOperationException (losing the possibility to compare the distances)? Thanks, Pavel
Re: Constructor annotation
It seems we are settling on @NamedArgument ... anybody disagree strongly?
Steve
On 2013-10-16 11:45 AM, Richard Bair wrote:
Ya that works too.
On Oct 16, 2013, at 8:41 AM, Eva Krejcirova eva.krejcir...@oracle.com wrote:
Good point!
In FX sources, we already use the @Default annotation which was used by
annotation processor when generating the builders. Because of this, it has
source retention policy, so it cannot be used by FXMLLoader. I was thinking
about promoting this to runtime annotation but maybe your solution is better.
We should solve this for FX8 otherwise the FXMLLoader will behave differently
from how the generated builders behaved.
Eva
On 16.10.2013 17:24, Tom Schindl wrote:
One thing that just came to my mind is that maybe also need a way to
define the default value to be used, with a builder I could e.g. define
that the default for fields are different from their real native default.
class MyBuilder {
private boolean a = true;
private int x = -1;
private Insets i = new Insets(10);
}
If we want to have a full replacement for builders the annotation must
have the possibility define this (in future).
public @interface NamedArgument {
String value();
String defaultValue();
ClassConverter converterClass();
}
If no converterClass is given we'd have to do our best to auto-convert
the String. I don't want to say that we should implement the default
value definition in FX8 but it would feel more natural with an
annotation per argument.
Tom
On 16.10.13 17:12, Tom Schindl wrote:
To me the JavaBean solution with one annotation looks error prone, does
anybody know why they did not use an annotation per field?
Tom
On 16.10.13 16:58, Stephen F Northover wrote:
+1 for base. Should we not follow closely what Java Beans is doing for
consistency? I realize that we can't have the reference.
Steve
On 2013-10-16 10:53 AM, Kevin Rushforth wrote:
Not to mention Tom's point that it can't be in the fxml module without
created unwanted (and circular) module dependencies. Seems like it
needs to be in the base module then, right?
-- Kevin
Richard Bair wrote:
+1 this is my preference. It is useful for things other than FXML,
and should be considered part of our javafx.beans API.
On Oct 16, 2013, at 4:20 AM, Tom Schindl
tom.schi...@bestsolution.at wrote:
On 16.10.13 11:22, Eva Krejcirova wrote:
Hi All,
when we retired builders, we caused a problem for FXML which doesn't
have a way to create classes without default constructors. Back
then we
decided to use an annotation for this but never actually got to
implement it and we need to fix this for FX8. I am in the process of
adding this functionality to FXMLLoader but we need to decide how the
annotation will look like and I could use some help with this.
We cannot use already existing ConstructorProperties for this, because
it's java.beans package and we don't want to create to dependency on
this package in JavaFX, so we need to introduce a new annotation.
We have two options:
1. Annotate the whole constructor:
e.g.
@ConstructorArguments({a, b, list})
public ImmutableClass(int a, int b, Integer... list)
2. Annotate the arguments:
e.g.
public ImmutableClass(@FXMLArgument(a) int a,
@FXMLArgument(b)int b, @FXMLArgument(list)Integer... list)
Which option do you like more and how should the annotation be named?
Option 2, but does it really have to hold FXML in the annotation name?
Where would you put the annotation? I think it should NOT be in the
FXML-Package-Namespace because the core should NOT depend on FXML!
I'd go with @Argument or simply @NamedArgument (@Named is already used
by javax.inject)
Tom
Re: Constructor annotation
Eva,
Perhaps @NamedArg is shorter and makes the code more readable?
If you don't have a JIRA already, please create one and paste in this
discussion. Interested parties can add themselves to the watchers list.
Steve
On 2013-10-16 1:25 PM, Richard Bair wrote:
Looks good to me.
On Oct 16, 2013, at 10:02 AM, Stephen F Northover
steve.x.northo...@oracle.com wrote:
It seems we are settling on @NamedArgument ... anybody disagree strongly?
Steve
On 2013-10-16 11:45 AM, Richard Bair wrote:
Ya that works too.
On Oct 16, 2013, at 8:41 AM, Eva Krejcirova eva.krejcir...@oracle.com wrote:
Good point!
In FX sources, we already use the @Default annotation which was used by
annotation processor when generating the builders. Because of this, it has
source retention policy, so it cannot be used by FXMLLoader. I was thinking
about promoting this to runtime annotation but maybe your solution is better.
We should solve this for FX8 otherwise the FXMLLoader will behave differently
from how the generated builders behaved.
Eva
On 16.10.2013 17:24, Tom Schindl wrote:
One thing that just came to my mind is that maybe also need a way to
define the default value to be used, with a builder I could e.g. define
that the default for fields are different from their real native default.
class MyBuilder {
private boolean a = true;
private int x = -1;
private Insets i = new Insets(10);
}
If we want to have a full replacement for builders the annotation must
have the possibility define this (in future).
public @interface NamedArgument {
String value();
String defaultValue();
ClassConverter converterClass();
}
If no converterClass is given we'd have to do our best to auto-convert
the String. I don't want to say that we should implement the default
value definition in FX8 but it would feel more natural with an
annotation per argument.
Tom
On 16.10.13 17:12, Tom Schindl wrote:
To me the JavaBean solution with one annotation looks error prone, does
anybody know why they did not use an annotation per field?
Tom
On 16.10.13 16:58, Stephen F Northover wrote:
+1 for base. Should we not follow closely what Java Beans is doing for
consistency? I realize that we can't have the reference.
Steve
On 2013-10-16 10:53 AM, Kevin Rushforth wrote:
Not to mention Tom's point that it can't be in the fxml module without
created unwanted (and circular) module dependencies. Seems like it
needs to be in the base module then, right?
-- Kevin
Richard Bair wrote:
+1 this is my preference. It is useful for things other than FXML,
and should be considered part of our javafx.beans API.
On Oct 16, 2013, at 4:20 AM, Tom Schindl
tom.schi...@bestsolution.at wrote:
On 16.10.13 11:22, Eva Krejcirova wrote:
Hi All,
when we retired builders, we caused a problem for FXML which doesn't
have a way to create classes without default constructors. Back
then we
decided to use an annotation for this but never actually got to
implement it and we need to fix this for FX8. I am in the process of
adding this functionality to FXMLLoader but we need to decide how the
annotation will look like and I could use some help with this.
We cannot use already existing ConstructorProperties for this, because
it's java.beans package and we don't want to create to dependency on
this package in JavaFX, so we need to introduce a new annotation.
We have two options:
1. Annotate the whole constructor:
e.g.
@ConstructorArguments({a, b, list})
public ImmutableClass(int a, int b, Integer... list)
2. Annotate the arguments:
e.g.
public ImmutableClass(@FXMLArgument(a) int a,
@FXMLArgument(b)int b, @FXMLArgument(list)Integer... list)
Which option do you like more and how should the annotation be named?
Option 2, but does it really have to hold FXML in the annotation name?
Where would you put the annotation? I think it should NOT be in the
FXML-Package-Namespace because the core should NOT depend on FXML!
I'd go with @Argument or simply @NamedArgument (@Named is already used
by javax.inject)
Tom
Re: Half-baked API (Camera position)
I took a quick look through JavaFX to find how this exception is used. It is mostly used to indicate impossible situation. Is that the situation we have here? Personally, for me, if we throw the exception, then we will generally just leave it that way forever. Steve On 2013-10-16 11:22 AM, Pavel Safrata wrote: On 16.10.2013 17:03, Stephen F Northover wrote: Could do something useful with what was there now? We can always fix this in future by adding another API to govern the interpretation of the value. Not much useful. Anyway, any such stuff can be quite easily done by reading the intersectedPoint's Z coordinate. Throwing the exception indicates that the call is unsupported, but application code can be written to catch the exception and when we implement the API, it can break (I realize that this is unlikely). The exception can tell by the message that the operation will be supported in the future. Pavel Steve On 2013-10-16 10:46 AM, Richard Bair wrote: My quick vote would be throwing the exception, but is like to hear from Steve and Kevin. On Oct 16, 2013, at 1:04 AM, Pavel Safrata pavel.safr...@oracle.com wrote: Hello, it looks like we can't help releasing a not-fully-baked piece of API with FX8. We've added bunch of new APIs for 3D and did our best to make them work well. Unfortunately, there's been not enough timepriority to fine-tune their behavior in 2D world. Right now I'm concerned about camera position in scene. It is inherent in the 3D perspective camera that it has its specific position in world, but the 2D parallel camera as we have it projects everything to the XY plane basically by ignoring the Z coordinate, so the camera position doesn't matter all that much. However, some of the newly added APIs depend on it: 1. Near/far clip on camera. This obviously cannot work without knowing where the camera is. Right now the parallel camera does no clipping though, so I guess we are OK to go with it as a known limitation. 2. PickResult on events which reports intersectedDistance between the camera and the picked point. This is worse because we can't just not support it - there will be some value and once somebody uses it we'll have a backward compatibility issue. The state right now is that the camera is (tentatively, by my arbitrary decision) at [0, 0, -1] and reports distances from there (note that as the camera renders everything, for nodes in front of Z=-1 it reports negative distances). This may change when the camera position is properly discussed and specified. Note that this post is *not* meant to discuss the camera position. Even if we could find the answer quickly (which I doubt), it's most probably too late to apply the change for FX8. So finally here is my question: do you think it's OK to solve this by keeping the current behavior and documenting the intersectedDistance in a way that for parallel camera the numbers are unspecified and subject to change in future versions? Or would you prefer something more drastic like throwing an UnsupportedOperationException (losing the possibility to compare the distances)? Thanks, Pavel
Re: Half-baked API (Camera position)
The problem is this: How is anyone supposed to ever do anything with this? I suppose they call the thing by mistake, get an exception and then never call it again. Then, later on, we come along and fix it. If the original people ever catch the exception and do something, then when we stop throwing the exception, they will be broken. Exceptions are API. I suppose the odds of people catching and exception like this and doing something are low but it is a possibility. I would rather do something sensible with it now as best we can and document it. In the future, if this turns out not to be a good thing, we add a new API that gives a better result (ie. intersectedDistance3D() or whatever). Steve On 2013-10-16 3:37 PM, Pavel Safrata wrote: As I've said, we intend to fix it in the future, so the situation should not be impossible. It is mostly used that way in the existing code, but there definitely are precedents for throwing it just temporarily. For instance: nodeOrientationProperty().getCssMetaData: throw new UnsupportedOperationException(Not supported yet.); or MeshView.impl_computeContains(): throw new UnsupportedOperationException(Not supported yet.); (internal but directly accessible to users via contains()) Pavel On 16.10.2013 20:10, Stephen F Northover wrote: I took a quick look through JavaFX to find how this exception is used. It is mostly used to indicate impossible situation. Is that the situation we have here? Personally, for me, if we throw the exception, then we will generally just leave it that way forever. Steve On 2013-10-16 11:22 AM, Pavel Safrata wrote: On 16.10.2013 17:03, Stephen F Northover wrote: Could do something useful with what was there now? We can always fix this in future by adding another API to govern the interpretation of the value. Not much useful. Anyway, any such stuff can be quite easily done by reading the intersectedPoint's Z coordinate. Throwing the exception indicates that the call is unsupported, but application code can be written to catch the exception and when we implement the API, it can break (I realize that this is unlikely). The exception can tell by the message that the operation will be supported in the future. Pavel Steve On 2013-10-16 10:46 AM, Richard Bair wrote: My quick vote would be throwing the exception, but is like to hear from Steve and Kevin. On Oct 16, 2013, at 1:04 AM, Pavel Safrata pavel.safr...@oracle.com wrote: Hello, it looks like we can't help releasing a not-fully-baked piece of API with FX8. We've added bunch of new APIs for 3D and did our best to make them work well. Unfortunately, there's been not enough timepriority to fine-tune their behavior in 2D world. Right now I'm concerned about camera position in scene. It is inherent in the 3D perspective camera that it has its specific position in world, but the 2D parallel camera as we have it projects everything to the XY plane basically by ignoring the Z coordinate, so the camera position doesn't matter all that much. However, some of the newly added APIs depend on it: 1. Near/far clip on camera. This obviously cannot work without knowing where the camera is. Right now the parallel camera does no clipping though, so I guess we are OK to go with it as a known limitation. 2. PickResult on events which reports intersectedDistance between the camera and the picked point. This is worse because we can't just not support it - there will be some value and once somebody uses it we'll have a backward compatibility issue. The state right now is that the camera is (tentatively, by my arbitrary decision) at [0, 0, -1] and reports distances from there (note that as the camera renders everything, for nodes in front of Z=-1 it reports negative distances). This may change when the camera position is properly discussed and specified. Note that this post is *not* meant to discuss the camera position. Even if we could find the answer quickly (which I doubt), it's most probably too late to apply the change for FX8. So finally here is my question: do you think it's OK to solve this by keeping the current behavior and documenting the intersectedDistance in a way that for parallel camera the numbers are unspecified and subject to change in future versions? Or would you prefer something more drastic like throwing an UnsupportedOperationException (losing the possibility to compare the distances)? Thanks, Pavel
Re: Half-baked API (Camera position)
Initial position: I don't really want to see any exception. Throwing an exception is unexpected and should really be reserved for when something bad happens, not when we can't decide how an API works. If the exception goes in, it's API and it stays forever. Steve On 2013-10-16 5:23 PM, Kevin Rushforth wrote: Steve: if Pavel throws IllegalStateException(not yet supported for parallel camera) or similar, do you think that would be OK or do you not want to see any exception? -- Kevin Kevin Rushforth wrote: Would IllegalStateException be better here? Usually UOE is for operations that are simply not supported by the class in question. In this case, the operation is only unsupported if the camera on the scene (i.e., the state of an object) is of a certain type which can change at runtime. I'm OK either way, just want it to be a deliberate decision. -- Kevin Pavel Safrata wrote: As I've said, we intend to fix it in the future, so the situation should not be impossible. It is mostly used that way in the existing code, but there definitely are precedents for throwing it just temporarily. For instance: nodeOrientationProperty().getCssMetaData: throw new UnsupportedOperationException(Not supported yet.); or MeshView.impl_computeContains(): throw new UnsupportedOperationException(Not supported yet.); (internal but directly accessible to users via contains()) Pavel On 16.10.2013 20:10, Stephen F Northover wrote: I took a quick look through JavaFX to find how this exception is used. It is mostly used to indicate impossible situation. Is that the situation we have here? Personally, for me, if we throw the exception, then we will generally just leave it that way forever. Steve On 2013-10-16 11:22 AM, Pavel Safrata wrote: On 16.10.2013 17:03, Stephen F Northover wrote: Could do something useful with what was there now? We can always fix this in future by adding another API to govern the interpretation of the value. Not much useful. Anyway, any such stuff can be quite easily done by reading the intersectedPoint's Z coordinate. Throwing the exception indicates that the call is unsupported, but application code can be written to catch the exception and when we implement the API, it can break (I realize that this is unlikely). The exception can tell by the message that the operation will be supported in the future. Pavel Steve On 2013-10-16 10:46 AM, Richard Bair wrote: My quick vote would be throwing the exception, but is like to hear from Steve and Kevin. On Oct 16, 2013, at 1:04 AM, Pavel Safrata pavel.safr...@oracle.com wrote: Hello, it looks like we can't help releasing a not-fully-baked piece of API with FX8. We've added bunch of new APIs for 3D and did our best to make them work well. Unfortunately, there's been not enough timepriority to fine-tune their behavior in 2D world. Right now I'm concerned about camera position in scene. It is inherent in the 3D perspective camera that it has its specific position in world, but the 2D parallel camera as we have it projects everything to the XY plane basically by ignoring the Z coordinate, so the camera position doesn't matter all that much. However, some of the newly added APIs depend on it: 1. Near/far clip on camera. This obviously cannot work without knowing where the camera is. Right now the parallel camera does no clipping though, so I guess we are OK to go with it as a known limitation. 2. PickResult on events which reports intersectedDistance between the camera and the picked point. This is worse because we can't just not support it - there will be some value and once somebody uses it we'll have a backward compatibility issue. The state right now is that the camera is (tentatively, by my arbitrary decision) at [0, 0, -1] and reports distances from there (note that as the camera renders everything, for nodes in front of Z=-1 it reports negative distances). This may change when the camera position is properly discussed and specified. Note that this post is *not* meant to discuss the camera position. Even if we could find the answer quickly (which I doubt), it's most probably too late to apply the change for FX8. So finally here is my question: do you think it's OK to solve this by keeping the current behavior and documenting the intersectedDistance in a way that for parallel camera the numbers are unspecified and subject to change in future versions? Or would you prefer something more drastic like throwing an UnsupportedOperationException (losing the possibility to compare the distances)? Thanks, Pavel
Re: GlassScene: setSecurityContext()
Comment out for now and get working code. On iOS at least, all apps come from the store. Steve On 2013-10-17 11:33 AM, Danno Ferrin wrote: Like I said in earlier ports, the language features of the back port aren't as difficult as the API support. I am guessing the security context has something to do with the u45 security patches, so I wouldn't expect a lot of detail until the next CPU release. Is this something we can simply comment out? This wouldn't be the first time compatibility was achieved by removal of an API (see date picker). On Thu, Oct 17, 2013 at 2:41 AM, Matthias Hänel hae...@ultramixer.comwrote: Hey Tobi, yes, I faced the same on the Android port. After uncommenting the new security stuff in GlassStage and GlassScene it's working again. This is just a preliminary solution. @Oracle is there a legal way that we can use parts of the jdk8 rt.jar? regards Matthias Am 17.10.2013 um 10:17 schrieb Tobias Bley t...@ultramixer.com: Hi, why do you introduced the security concept in GlassScene and GlassStage? setSecurityContext() What is the goal? The problem is the used class sun.misc.SharedSecrets is not available in the android class library. Altough I have added it to the robovm compat lib I’m getting a security error and are not able to start the app on iOS. Tobi
Re: Media is now opensource
This is huge! Thanks Kirill. Steve On 2013-10-18 12:35 PM, Kirill Kirichenko wrote: Hello OpenJFXers ! We're happy to announce that Media part of JavaFX is now open source. Opensourcing touched all Media component except ON2 FLV demuxer and VP6 decoder. The decoder will remain closed. You're all welcome to contribute. Thanks, K
Re: JavaFX on iOS and Android - are we there yet?
Rather than arguing this point, the correct answer is to provide both and let the application developer choose. Do you guys know how old this argument is? Hint: It predates Java. Steve On 2013-10-22 6:17 PM, Pedro Duque Vieira wrote: Even the most fab skins or CSS is not going to get us away from the need to integrate JavaFX controls with true native controls. As has been pointed out, there are some native controls on both iOS and Android for which there is no JavaFX equivalent and this will always be the case. Even if someone were to develop near identical lightweight controls in JavaFX, they would need to behave slightly differently on iOS than they do on Android and vice versa. I don't think this is exactly this straight forward. Ideally you would want to have this kind of native behavior on every platform. But having this native behavior involves having a different version of your app for each OS you want to deploy in, which might not be what the developers want. Remember JavaFX is a cross platform development kit and the major reason a developer would choose JavaFX over doing native mobile development is that his app can run on a variety of mobile platforms: windows 8, ipad, android, iPhone, etc with the same code base and *MOST* importantly with much less development time than building an app for each platform. For the sake of development time an app that doesn't go against any of the different platforms UX but that has the least common denominator so that each user in each different platform understands the UI might be a better solution for the sake of development time. One such example is the back button that appears when you drill down a list on an ios app but doesn't appear in an android app because every android phone as a physical back button. I do agree with you that there are some places where a native looking control is ideal and doesn't involve any extra effort from the developer to customize it for the given platform like for instance comboboxs where a kind of wheel appears where the user can choose an option, or input controls where the native keyboard pops up. Thanks, best regards,
Re: JFXPanel vs. real world usage
Hi Matthais, There was quite a debate way back when as to whether there should be heavyweight or lightweight embedding. If heavyweight, then FX would not play well with AWT/Swing and would have all the heavyweight/lightweight issues inherent there. If lightweight, then this is more work for the embedding toolkit because it needs to forward events and implement drawing. The simplest implementation of drawing is to draw images. A more complex implementation would require that FX and AWT/Swing communicate using a common underlying graphics currency that both toolkits support (such as OpenGL or DirectX textures). 1) There has been some talk of doing the underlying communication thing but nobody has looked into it. It will require quite low level coordinated changes to AWT/Swing and FX. I did not see a JIRA that is tracking this idea. Feel free to enter one. 2) Please enter a JIRA with a benchmark that is too slow for you using the current JFXPanel implementation. Steve On 2013-10-24 12:03 PM, Matthias Hänel wrote: Hi, I just took a look at JFXPanel. This implementation is from my perspective just a pin point for a real implementation. The problem with the current one is, that a JFX scene is rendered down to a pixelbuffer that is rendered on a Swing Panel by paintComponent. Is there a particular reason for this? Actually, I expected the embedding of the OpenGL/DirectX context in other words the heavy weigth component of the entire JFX scene. In the current stage of the JFXPanel it's not even usable for very small addons, since the performance is soo damn bad ;) Maybe I missed another way to get JFX inserted into an existing Swing-Application? Any hints? regards Matthias
Re: JFXPanel vs. real world usage
Please enter a JIRA with your sample code attached. Steve On 2013-10-24 2:37 PM, Tobias Bley wrote: I added a simple accordion as JFXPanel into a swing frame and the performance is not good. the cpu usage goes up to 100% when moving the mouse over the accordion title panes (hover effect). The resizing performance is bad too. Am 24.10.2013 um 20:10 schrieb rdarr...@yahoo.com: I have the same experience. We're using this and it works ok as far as performance. -Original Message- From: Pedro Duque Vieira pedro.duquevie...@gmail.com Sender: openjfx-dev-boun...@openjdk.java.net Date: Thu, 24 Oct 2013 18:20:42 To: OpenJFX Mailing Listopenjfx-dev@openjdk.java.net Subject: RE: JFXPanel vs. real world usage Hi Matthias, I don't see any problems with performance and I've been using this a lot. Best regards, -- Pedro Duque Vieira
Re: iOS Default font is wrong
If the OS is reporting the wrong value for the default a classic trick
is to create a dummy control that normally has the font we want and
query that.
Steve
On 2013-10-29 11:21 AM, Richard Bair wrote:
Hi guys,
The default font for iOS is supposed to be System Bold 15 (according to
http://stackoverflow.com/questions/17325152/what-size-font-is-the-title-in-a-default-uibutton
anyway), and it does look more correct to me. Our code is getting to this
native method in MacFontFinder.c
JNIEXPORT jfloat JNICALL
Java_com_sun_javafx_font_MacFontFinder_getSystemFontSize
(JNIEnv *env, jclass obj)
{
CTFontRef font = CTFontCreateUIFontForLanguage(
kCTFontSystemFontType,
0.0, //get system font with default size
NULL);
jfloat systemFontDefaultSize = (jfloat) CTFontGetSize (font);
CFRelease(font);
return systemFontDefaultSize;
}
However it appears the return value is 13 instead of 15 (and I don't know what the actual
default font family / weight is that we're returning). It is possible the answer coming
from this native API call is wrong. Any ideas?
Richard
Re: iOS Default font is wrong
Eh? Just create a bogus native control, query the font and throw the control away. No text node necessary. Stege On 2013-10-30 4:27 PM, Richard Bair wrote: The only problem is that the CSS requires a UI control, so just putting a Text node up gets the wrong size. Also the API we have to say get the default font will be wrong. We could just hard-code in a hack for iOS maybe? Richard On Oct 30, 2013, at 12:41 PM, Felipe Heidrich felipe.heidr...@oracle.com wrote: Could we call UIFont using Objective-C Runtime Something like: id class_UIFont = objc_getClass(UIFont); SEL sel_labelFontSize = sel_registerName(labelFontSize); float size = objc_msgSend_fpret(class_UIFont, sel_labelFontSize); ? Anyway, we are back to the original question: What font to use. Reading Richard's original request we are still not getting the recommend font which is bold. I start to think the answer to get this right in the CSS… Felipe On Oct 30, 2013, at 10:14 AM, Oldrich Maticka oldrich.mati...@oracle.com wrote: Hi, CTFontCreateUIFontForLanguage() returns fonts with same sizes for both iOS and Mac OS X. See table below. Unfortunately I made a mistake when I wrote 15.0 for CTFontCreateUIFontForLanguage(kCTFontPushButtonFontType) font size, unfortunately it is 13.0. Other sizes reported were correct (I have verified it yet once). iPad3 (iOS7.0) MacOSX 10.8 kCTFontUserFontType 12 12 kCTFontUserFixedPitchFontType 10 10 kCTFontSystemFontType 13 13 kCTFontEmphasizedSystemFontType 13 13 kCTFontSmallSystemFontType 11 11 kCTFontSmallEmphasizedSystemFontType11 11 kCTFontMiniSystemFontType 9 9 kCTFontMiniEmphasizedSystemFontType 9 9 kCTFontViewsFontType12 12 kCTFontApplicationFontType 13 13 kCTFontLabelFontType10 10 kCTFontMenuTitleFontType14 14 kCTFontMenuItemFontType 14 14 kCTFontMenuItemMarkFontType 14 14 kCTFontMenuItemCmdKeyFontType 14 14 kCTFontWindowTitleFontType 13 13 kCTFontPushButtonFontType 13 13 kCTFontUtilityWindowTitleFontType 11 11 kCTFontAlertHeaderFontType 13 13 kCTFontSystemDetailFontType 9 9 kCTFontEmphasizedSystemDetailFontType 9 9 kCTFontToolbarFontType 11 11 kCTFontSmallToolbarFontType 10 10 kCTFontMessageFontType 13 13 kCTFontPaletteFontType 11 11 kCTFontToolTipFontType 11 11 kCTFontControlContentFontType 12 12 Oldrich On 10/30/13 4:38 PM, Felipe Heidrich wrote: Hi, Correct me if I'm wrong, to use UIWhatever or NSWhatever we will need Objective-C (or use the ugly objc_msgSend). That is more work as we don't have Objective-C in native font code. Besides, creating a Button requires, usually, a lot more boilerplate code. We will also have to link to UIKit frameworks, etc. Now, creating a CTFont using CTFontCreateUIFontForLanguage(kCTFontPushButtonFontType) would be a very easy change. Oldrich, could you please prepare a table with the fontSize for all values on CTFontUIFontType for MacOSX and iOS ? Thanks On Oct 30, 2013, at 6:38 AM, Stephen F Northover steve.x.northo...@oracle.com wrote: Let's use UIButton as this seems to match the stack overflow discussion. Steve On 2013-10-30 7:51 AM, Oldrich Maticka wrote: I have tried simple app with several controls. Fonts in Interface Builder - UIButton - System 15.0 UILabel - System 17.0 UITextField - System 14.0 UITextView - System 14.0 Same fontsize - 15.0 has UIButton's label created at runtime. UIFont class methods for getting system font information return: + labelFontSize 17.0 + buttonFontSize 18.0 + smallSystemFontSize 12.0 + systemFontSize 14.0 In fx Java_com_sun_javafx_font_MacFontFinder_getSystemFontSize returns 13.0 We can use different CTFontUIFontType in this method to return something better than 13.0 - e.g. with kCTFontPushButtonFontType as an argument to CTFontCreateUIFontForLanguage() it returns 15.0, but we need to decide, what we want to use as default. Should be our system default the size same as for UIButton, UILabel or other control? I was using iPad3 (iOS 7.0, Xcode 5.0). Olda On 10/29/13 7:32 PM, Stephen F Northover wrote: I was going to create a dummy control (say a Button) and ask for the font. Just an idea. Steve On 2013-10-29 2:18 PM, Felipe Heidrich wrote: The code Richard sent is creating a dummy font and asking for its size. The problem is that there are about 3 thousand different fonts on the Mac ;-) Here we are creating a CTFont. For Mac OS X most native apps probably would be using a NSFont (cause that is what cocoa controls take). Likewise on iOS I think the common font is UIFont (cause I think that is what UIKIt controls take). Could anyone fire up Xcode, create a dummy iOS app, create a UIFont and see what is the size ? Felipe On Oct 29, 2013, at 8:40 AM, Stephen F Northover steve.x.northo...@oracle.com
Re: JavaFX on rPi iOS with RoboVM
Hi Tom, I bet if you entered a JIRA for some of these items (with [iOS] in the title), someone ... cough, cough ... might be able to take a look at them. My RoboVM setup has been broken for a few weeks and I have been unable to get to it. Steve On 2013-10-30 11:47 AM, Tom Schindl wrote: Hi, I've been working on some samples for my presentation at EclipseCon Europe and wanted share my findings. 1. rpi (opendjk b113) - As a demo i used Gerrit Grunwalds imagerollover [1] which in principle works great but at a certain point crashes with an exception so something in the OpenGL implementation there does not work. You should be able to reproduce yourself by running the code. 2. iOS -- I've been running on jfx78 backport from about 2 weeks ago. I saw some commits for iOS but I don't think that matters. a) Image rollover I delambdarized Gerrits code to run on JDK6 (which RoboVM is) and while the animations are smooth (in the simulator and real iPad-Device) there's a lot of what Steve calls screenscheese. I don't think that RoboVM is the cause for this. b) Charts [2] PieCharts are not working completely there are certain segments in the pie missing (on the Simulator it is ok, on the device it is broken!), BarCharts work ok. x/y translate animations: animation them e.g. by sliding them in from is lags a lot. I know that charts are not the easiest components but anyways I think sliding a chart in and out must be smooth. fade animation: lags and is not smooth It might be that my animation code is not doing the right things [3] but I doubt that it is that wrong. I don't know how much Java-Bound this animation code is so RoboVM could be one cause of the problem although I doubt that because e.g. for the x/y translate animations the smaller the area I animate the smoother it gets. Tom [1]https://bitbucket.org/hansolo/imagerollover [2]http://tomsondev.bestsolution.at/2013/10/25/javafx-on-ios-with-the-help-of-robovm/ [3]http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.ui.mobile/src/org/eclipse/fx/ui/mobile/animations/TransitionDelegate.java
Re: Reenable webkit on jfx78?
My vote: enable it. Steve On 2013-10-30 6:07 PM, Stefan Fuchs wrote: Hi, Currently the web-module (aka webkit) is not included in the jfx78 backport. I have done some tests after enabling it in jfx78. At least on linux it works fine. However it increases the compile time and memory usage during compilation considerably (if you choose to build the native part of webkit). So the pros are: - backport is more complete - backport should be easier maintain (less changes) The cons are: - compile time Are there any opinions, whether i should enable the web-module on future releases of jfx78 or not? Stefan
Re: [API REVIEW] Add javafx.scene.layout.BackgroundInsets (RT-26277)
Hi David, Looks good. Please update the JIRA with what you intend to do. People are welcome to follow along there if they have any ideas for a different API / approach. Steve On 2013-11-04 2:22 PM, David Grieve wrote: https://javafx-jira.kenai.com/browse/RT-26277 relates to the use of percentage values in -fx-background-insets. BackgroundFill (in javafx.scene.layout) uses Insets, which does not allow for a percentage value. My proposal here is to simply copy the BorderWidths implementation to a BackgroundInsets class, with appropriate renaming along the way, and use it in place of Insets in BackgroundFill. The impact on the BackgroundFill API is: -public final Insets getInsets() +public final BackgroundInsets getBackgroundInsets() Since BackgroundFill is new in 8.0, backward compatibility is not a concern.
Re: JFXPanel with WebView in JDK8
Please enter a JIRA with your test code in it and add me as a watcher.
Thanks.
Steve
On 2013-11-05 2:37 PM, Lidierth Malcolm wrote:
NOTE: THIS EXCEPTION OCCURS WITH JDK8, BUT NOT WITH JDK7
public class NewFXMain1 {
public static void main(String[] args) throws
InterruptedException, InvocationTargetException {
EventQueue.invokeAndWait(new Runnable() {
// Create the Swing components on the EDT
@Override
public void run() {
JFrame f = new JFrame();
f.getContentPane().setPreferredSize(new Dimension(500,
500));
f.pack();
f.setVisible(true);
final JFXPanel jfx = new JFXPanel();
f.getContentPane().add(jfx);
// FX Thread
Platform.runLater(new Runnable() {
@Override
public void run() {
WebView browser = new WebView();
WebEngine webEngine = browser.getEngine();
// This is a reference to a web page on the
Waterloo web site
webEngine.load(http://waterloo.sourceforge.net/devwebpage/MathJax/mathjax.html;);
Scene s = new Scene(browser);
jfx.setScene(s);
}
});
}
});
}
}
This gives (Note: using JDK8 and Running from NetBeans 7.4):
Executing
C:\Users\malcolm\Documents\waterloo\Sources\Java\kcl-waterloo-jfx\dist\run1852659813\kcl-waterloo-jfx.jar
using platform C:\Program Files\Java\jdk1.8.0/bin/java
Exception in thread AWT-EventQueue-0 java.lang.NullPointerException
at
javafx.embed.swing.JFXPanel.getInputMethodRequests(JFXPanel.java:744)
at
sun.awt.im.InputMethodAdapter.haveActiveClient(InputMethodAdapter.java:61)
at sun.awt.windows.WInputMethod.activate(WInputMethod.java:285)
at sun.awt.im.InputContext.activateInputMethod(InputContext.java:396)
at sun.awt.im.InputContext.focusGained(InputContext.java:338)
at sun.awt.im.InputContext.dispatchEvent(InputContext.java:245)
at
sun.awt.im.InputMethodContext.dispatchEvent(InputMethodContext.java:196)
at java.awt.Component.dispatchEventImpl(Component.java:4817)
at java.awt.Container.dispatchEventImpl(Container.java:2293)
at java.awt.Component.dispatchEvent(Component.java:4707)
at
java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1954)
at
java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:986)
at
java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:610)
at java.awt.Component.dispatchEventImpl(Component.java:4756)
at java.awt.Container.dispatchEventImpl(Container.java:2293)
at java.awt.Component.dispatchEvent(Component.java:4707)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:746)
at java.awt.EventQueue.access$400(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:697)
at java.awt.EventQueue$3.run(EventQueue.java:691)
at java.security.AccessController.doPrivileged(Native Method)
at
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
at
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:86)
at java.awt.EventQueue$4.run(EventQueue.java:719)
at java.awt.EventQueue$4.run(EventQueue.java:717)
at java.security.AccessController.doPrivileged(Native Method)
at
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:716)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:220)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:135)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:123)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:119)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:111)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:97)
Code Review Policies
Hello Committers, Let me summarize how to initiate a code review, since this changed recently. All information about how a bug was fixed needs to be in the JIRA. This means that all patches, webrevs, discussions and who is doing the review needs to be captured there. The email to openjfx-dev is intended to inform the community that a review is happening so others can join in, but it doesn't need to contain detailed information about the fix. People can get all that from the JIRA. This about it this way: What we are trying to avoid is having any interesting information about the fix appear only in the mailing list. The bottom line is that the comment section of JIRA should contains the contents of the email that previously you would have sent to the list. If you want the information to be in two places, that is fine, but it must be in the JIRA. However, the discussion and any subsequent action is in the JIRA. https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews Thanks, Steve and Daniel
Re: Android replaces Dalvik with ART
This is what .NET does. There was never an interpreter for any managed code. Steve On 2013-11-07 2:54 PM, Stefan Fuchs wrote: Hi, well if I understand it correctly, ART is just an Ahead of Time compiler like robovm. Therefore we can only hope, that they open-source it, so that we can use it on iOS :). See the German article on heise: http://www.heise.de/newsticker/meldung/Dalvik-Nachfolger-Google-laedt-zum-Testen-der-neuen-Android-Runtime-ein-2041644.html Best regards, Stefan Hi, after we reached the goal to use JavaFX on Android via Dalvik, Google announces the successor of Dalvik, called ART (Android Runtime). The start to move because of the legal issues with Java and Oracle…. http://source.android.com/devices/tech/dalvik/art.html The question is now: How to use JFX on Android on top of ART? As I posted in my blog.software4java.com, we need a own JVM to embed in Android apps. Best regards, Tobi
Re: did anyone encountered this?
Let's consider flipping the switch so people don't see the problem or *possibly* switching to gradle 1.8. This is something I see all the time and I'm betting others do too. I have filed https://javafx-jira.kenai.com/browse/RT-34171 to track the issue. Steve On 2013-11-08 8:03 AM, Kevin Rushforth wrote: As a follow-up to this, yes it has been fixed in gradle 1.8: http://issues.gradle.org/browse/GRADLE-2831 We won't be switching our builds to gradle 1.8 for FX 8, but if developers want to give it a try on their own systems, that would be fine. -- Kevin Kevin Rushforth wrote: I see this from time to time. This is a bug in the version of ant that is used by gradle for dependencies. It has been reported that gradle 1.8 may have a newer version of ant that fixes this bug. In the mean time, a less intrusive workaround is: gradle -PUSE_DEPEND=false ... If enough people are getting bitten by this, should we consider making USE_DEPEND=false the default? -- Kevin Artem Ananiev wrote: Yes, I've seen this many times. I didn't spend much time trying to understand what is the problem, though. The workaround is simple: just delete 3DViewer build folder. Thanks, Artem On 11/6/2013 5:35 PM, Assaf Yavnai wrote: :apps:experiments:3DViewer:compileJava FAILED FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':apps:experiments:3DViewer:compileJava'. java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. BUILD FAILED Total time: 39.292 secs assaf@assaf-Latitude-E6410:~/ws/udev-refactoring/rt$ java -versionjava version 1.8.0-ea Java(TM) SE Runtime Environment (build 1.8.0-ea-b113) Java HotSpot(TM) Server VM (build 25.0-b55, mixed mode) Thanks, Assaf
Re: Build fail: unresolved external symbol mainCRTStartup
Hi Leonid, I have the same configuration as you I think. I'm just making sure I can build. First, do you have 32-bit JDK8? Are you running under a cygwin shell? What is your gradle command line? Steve On 2013-11-08 9:08 AM, Leonid Popov wrote: Hi, I've just cloned a new workspace from ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx and tried to build it. The following error encountered: link /LIBPATH:..\lib /NOLOGO /MAP /INCREMENTAL:NO /SUBSYSTEM:CONSOLE /MANIFEST /MANIFESTFILE:obj\DerivedSourcesJava.intermediate.manifest /OUT:..\lib\DerivedSourcesJava.exe @C:\Users\lp154592\AppData\Local\Temp\nm9A16.tmp LINK : error LNK2001: unresolved external symbol mainCRTStartup ..\lib\DerivedSourcesJava.exe : fatal error LNK1120: 1 unresolved externals My box is Windows 7 64-bit with MSVS 10 installed; Gradle 1.4 is used for building. Any suggestions? Thanks, Leonid
Re: Build fail: unresolved external symbol mainCRTStartup
Ok, you can't say that and not tell us what the problem was! Steve On 2013-11-13 9:55 AM, Leonid Popov wrote: Finally managed to build it with JDK 1.8-ea build 114 64 bit. On 11/12/2013 6:00 PM, Leonid Popov wrote: Thanks Kevin, but unfortunately it didn't help. Even having it cleaned completely, the build script still generates 32-bit YarrInterpreter.obj and then fails to link it to a 64-bit library. Still investigating. On 11/11/2013 8:43 PM, Kevin Rushforth wrote: Hi Leonid, Building JavaFX on Windows requires Cygwin, so it doesn't surprise me that it fails with a DOS shell. The error you are seeing on cygwin seems like a mismatch where part of the build is trying to use a 32-bit build and part trying to use 64-bit. My recommendation is to try the following, from a cygwin shell: 1. Ensure that your JAVA_HOME and PATH point to the same version of Java (the 32-bit Java). 2. Completely clean your repo cd rt gradle clean rm -rf buildSrc/build buildSrc/.gradle .gradle 3. Rebuild, making sure you compile both media and webkit (not sure if needed, but better to remove one more variable): gradle -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true sdk See if the above will work. -- Kevin Leonid Popov wrote: Hi Steve, Yes, I use 32-bit JDK for building. I tried to build it from both Windows and Cygwin command shells. The error I mentioned happens when building from Windows. If I try to build it from Cygwin, I get another error: Building Webkit configuration /Release/ into C:\javafx\8my\jfx\rt\modules\web\build/win Calling 'qmake -makefile C:/javafx/8my/jfx/rt/modules/web/src/main/native/Source/WebKitJava.pro CONFIG-=debug CONFIG+=release DEFINES+=IMAGEIO=1' in C:/javafx/8my/jfx/rt/modules/web/build/win/Release ... Microsoft (R) Program Maintenance Utility Version 10.00.30319.01 Copyright (C) Microsoft Corporation. All rights reserved. cd JavaScriptCore\ C:\MsVS10\VC\BIN\nmake.exe -f Makefile.JavaScriptCoreJava Microsoft (R) Program Maintenance Utility Version 10.00.30319.01 Copyright (C) Microsoft Corporation. All rights reserved. lib /NOLOGO /OUT:..\lib\JavaScriptCoreJava.lib @.\nm2BB0.tmp obj\YarrInterpreter.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' NMAKE : fatal error U1077: 'C:\MsVS10\VC\BIN\lib.EXE' : return code '0x458' Stop. NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. My script for Cygwin is: export DXSDK_DIR=/cygdrive/c/DXSDK/ export WMSDK_DIR=/cygdrive/c/WMSDK/WMFSDK11/ export QTSDK_DIR=/cygdrive/c/Qt/4.6.0/ export VSINSTALLDIR=/cygdrive/C/MsVS10 export WINDOWS_VS_PATH=/cygdrive/C/MsVS10/VC/bin export GRADLE_DIR=/cygdrive/c/tools/gradle/ export JDK_HOME=/cygdrive/c/java/8b112/ export JAVA_HOME=$JDK_HOME export ANT_HOME=/cygdrive/c/ant/ export PATH=$GRADLE_DIR/bin/:$JAVA_HOME/bin/:$DXSDK_DIR/Utilities/Bin/x86:$PATH $GRADLE_DIR/bin/gradle -PCOMPILE_WEBKIT=true -PCONF=Debug sdk I'm trying but I can't realize what changed after my last successfull build. Leonid. On 11/8/2013 9:10 PM, Stephen F Northover wrote: Hi Leonid, I have the same configuration as you I think. I'm just making sure I can build. First, do you have 32-bit JDK8? Are you running under a cygwin shell? What is your gradle command line? Steve On 2013-11-08 9:08 AM, Leonid Popov wrote: Hi, I've just cloned a new workspace from ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx and tried to build it. The following error encountered: link /LIBPATH:..\lib /NOLOGO /MAP /INCREMENTAL:NO /SUBSYSTEM:CONSOLE /MANIFEST /MANIFESTFILE:obj\DerivedSourcesJava.intermediate.manifest /OUT:..\lib\DerivedSourcesJava.exe @C:\Users\lp154592\AppData\Local\Temp\nm9A16.tmp LINK : error LNK2001: unresolved external symbol mainCRTStartup ..\lib\DerivedSourcesJava.exe : fatal error LNK1120: 1 unresolved externals My box is Windows 7 64-bit with MSVS 10 installed; Gradle 1.4 is used for building. Any suggestions? Thanks, Leonid
Re: H/V resize cursors in a JFXPanel
Hi Werner, This is all great information. If you can prove that RT-26235 is a dup or related to RT32507, please indicate in the bug reports. Also note the inconsistency. Please add me to the watchers list if not already there. Thanks, Steve On 2013-11-18 7:38 AM, Werner Lehmann wrote: Hi, still on FX2 I am plagued with a bug that prevents getting h-resize (split) cursor in a JFXPanel. This is a known and acknowledged issue, see [#RT-26235] SplitPane in JFXPanel: Mouse cursor not changed I have looked some more into this and noticed that this really seems to affect the h/v-resize cursors only, other cursors work fine, even on a JFXPanel. So I am wondering if this might be related to [#RT-32507] Cursor.cursor does not accept cursor names with hyphens which revolves around h-resize versus h_resize. This is contradicted though by the fact that RT-26235 is unresolved in 8 (and even scheduled only for 9) while RT-32507 is supposed to be fixed in 8. The split cursor is missing everywhere: on a splitpane, on the columns of a tableview, on custom controls - all inside JFXPanel, of course. I tried to work around this by using -fx-cursor: h_resize instead of -fx-cursor: h-resize but that helps only outside of a JFXPanel (and will probably be broken with FX8). Also tried to work around by setting the cursor in code: setCursor(Cursor.H_RESIZE) - but even then only other cursors work, not the h/v resize ones. Any ideas to make this work for FX2 (and maybe even for FX8 considering the fix version for RT-26235)? Rgds Werner
Re: Use of plugins in WebView
There is no FX API to get the underlying window handle (HWND) on the desktop or in the browser. Steve On 2013-11-18 9:02 PM, Peter Zhelezniakov wrote: On 11/18/2013 06:20 PM, Philipp Dörfler wrote: And especially a HWND is what I’m looking for. So I guess anything requiring a HWND is just not usable within an JFX App at all? :/ I'm not a Glass expert, but I'd expect such platform-specific data to be well hidden from a JavaFX developer.
Re: Show case: JFX on iOS and Android
Nice work Tobi! Especially building on software that is shifting under your feet. Steve On 2013-11-18 5:02 PM, Tobias Bley wrote: For all who do not follow me on twitter: a few screenshots concerning JFX on iOS and Android: http://blog.software4java.com/?p=148#comment-4629 Best regards, Tobi
Re: How to report RT-30362 regressing on b114?
Please open a new JIRA with all the information that you have put in this email message. Add the label 'regression' in the JIRA label field and put 'Regression' in the title text of the bug (optional but a good idea, that way people scanning a big list of bugs can tell right away that the bug is a regression). Thanks! Steve On 2013-11-20 9:41 AM, ngalarn...@abinitio.com wrote: Hello, How do I report a regression? It looks to me like RT-32636/RT-30362 has regressed on b114. On Win7, my JavaFX app ScenicView DP4, both running Java8 b114 have mostly black screens when coming out of Screen Lock. SceneBuilder, which reports it is running b113, looks fine. What is the proper procedure for reporting this? Add a comment to one of the bug reports? Open a new one? Something else? Thanks, Neil NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution.
Re: Does the rendering system in JavaFX process font hints?
Hi Sybille, Please try your code on jdk8. The font engine in FX has been changed to use the native rasterizer on Windows and Mac. Steve On 2013-11-29 8:14 AM, Sybille Lein wrote: I have some questions about the font rendering system that is used in the JavaFX system. We are developing a JavaFX application with a customer owned font. This font is a TrueType font and includes font hints. There are usually two options for the font engine in operating systems: processing hints, or running an auto-hinter. It appears to me that the JavaFX font rendering system ignores the hints in the fonts, and runs the auto-hinter instead.It doesn’t invoke the byte-code interpreter. My question is about how the font engine works with font hints on Mac OS X and Windows? And is it possible to configure the font engine in JavaFX to process hints? I tested it under Mac OS X and java version 1.7.0_17. Thanks Sybille This message is intended for a particular addressee only and may contain business or company secrets. If you have received this email in error, please contact the sender and delete the message immediately. Any use of this email, including saving, publishing, copying, replication or forwarding of the message or the contents is not permitted.
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry and the drive of these fantastic people. Their work will undoubtedly be extremely useful to many developers worldwide. I want to make all that *perfectly clear* because now I am going to explain why I (probably) will not be one of those people and (hopefully) do it with the utmost respect for the aforementioned rock stars :-) Right, so back to the issue of whether to or not to implement or use a native Look and Feel. Some of the following comments have already been made by me on other networks and in other forums so apologies if it seems a bit repetitive to some. At first glance, the idea of a native Look and Feel seems almost like the proverbial Holy Grail. I mean, if such a thing were truly possible and viable, who wouldn't want one? You still have your single codebase across all platforms and you just just plug-in the particular native Look and Feel for your target platform and voila! World domination will surely soon follow! Well, not quite. It's a great idea but I am going out on a limb to claim that it has *never* worked. Ever! And by work I mean so that your not-so-native app looks
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry and the drive of these fantastic people. Their work will undoubtedly be extremely useful to many developers worldwide. I want to make all that *perfectly clear* because now I am going to explain why I (probably
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Yes, if it helps an application ship using the components and technology they need to make their product successful. In any case, this discussion is academic. Steve On 2013-12-10 12:25 PM, Anthony Petrov wrote: We have implemented HW/LW components mixing for AWT/Swing in the past [1]. However, the feature is very limited (no transparency support, etc.), and the limitations come from native system capabilities that can't be worked around easily. Do we really want something limited like this in FX? [1] http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html -- best regards, Anthony On 12/10/2013 06:14 AM, Stephen F Northover wrote: At one point, I was very interested in seeing this happen but there wasn't the band width and resources. Steve On 2013-12-09 1:00 PM, Felix Bembrick wrote: What can we expect from the JavaFX team in this regard in the future? I know we have talked about mixing lightweight and heavyweight controls in the same context but is it going to happen? Is this planned for JFX9 perhaps? Is it *really* even feasible? On 10 Dec 2013, at 4:55, Stephen F Northover steve.x.northo...@oracle.com wrote: Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
I was very interesting in heavyweight integration a while back but could not get anyone very enthusiastic about it. Steve On 2013-12-10 1:35 PM, Felix Bembrick wrote: Stephen, why do you refer to this discussion as academic? Felix On 11 December 2013 05:20, Stephen F Northover steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com wrote: Yes, if it helps an application ship using the components and technology they need to make their product successful. In any case, this discussion is academic. Steve On 2013-12-10 12:25 PM, Anthony Petrov wrote: We have implemented HW/LW components mixing for AWT/Swing in the past [1]. However, the feature is very limited (no transparency support, etc.), and the limitations come from native system capabilities that can't be worked around easily. Do we really want something limited like this in FX? [1] http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html -- best regards, Anthony On 12/10/2013 06:14 AM, Stephen F Northover wrote: At one point, I was very interested in seeing this happen but there wasn't the band width and resources. Steve On 2013-12-09 1:00 PM, Felix Bembrick wrote: What can we expect from the JavaFX team in this regard in the future? I know we have talked about mixing lightweight and heavyweight controls in the same context but is it going to happen? Is this planned for JFX9 perhaps? Is it *really* even feasible? On 10 Dec 2013, at 4:55, Stephen F Northover steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com wrote: Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example
Re: Please put release number in review requests
This is a great idea. I have seen Anthony doing this already. Steve On 2013-12-11 1:49 PM, Kevin Rushforth wrote: It would be helpful if the release for which a review is requested is in the subject line now that we have multiple releases in flight. A suggestion for this (from the Wiki https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews) is: 8 review request: RT-12345: summary of the bug 8u20 review request: RT-12345: summary of the bug Thanks. -- Kevin
Re: [8u20] post-commit notification: RT-34820: Self Illumination map issues of PhongMaterial
Hi all, I gentle reminder. When others need to verify a bug, they need to know what code was run to test the fix. In the case of RT-34820 and many others, if you read the JIRA, you can find out pretty quickly. However it's nicer if there is a standard comment at the end of the JIRA so people can scan it quickly. Something like: Tested-with: Ensemble Unit Tests: none Standard templates in comments really help out a lot for manager guys when they need to scan a billion JIRA and try to grasp quickly what is going on. Here is the wiki entry that describes this (hidden at the bottom of the page) https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews Thanks, Steve On 2013-12-13 10:30 AM, Vadim Pakhnushev wrote: Hello, https://javafx-jira.kenai.com/browse/RT-34820 http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8a5c6817206d Thanks, Vadim
(In)Sanity Testing Mondays
Hello all, As discussed at the committer meetings earlier this week, starting next week we are going to try out (In)Sanity Testing Mondays. The community is invited to join in. The goal here is to improve our overall quality substantially with a small investment. The testing is NOT intended to take a day, or even half a day - we are targeting 1 hour for testing each week. So clearly this won't be a deep-dive into each test that you run, it's more of a quick high-level sanity test. If there is a particular area you are concerned with, please feel free to spend more time there and less in other areas, but you do need to run each test that is assigned to you. On Monday morning, in your time zone, ensure that you have the latest build and start. We will be running Ensemble and Modena and other tests but anything is fair game. Committers will have various assignments and platforms but these are not set in stone until the end of time. You don't need to put together any type of formal report, but we encourage everyone to be online, reading email and available by IM while running the tests to discuss results real time as necessary. File JIRA for any new bugs you find and call it done! Be sure to check the One True Dashboard to see of your bug has been found already. https://javafx-jira.kenai.com/secure/Dashboard.jspa?selectPageId=11893 At the next committer meeting and on the list, we'll be discussing how things went and how we want to modify and improve the process going forward, so be prepared with your feedback. None of this is set in stone, so if it doesn't go well, don't despair - we intend to tweak this until it does work well. Cheers, and happy testing! Lisa, Kevin and Steve
Re: how to scroll ListView to make a specific item visible (only when not visible already)
Thank for coming back and answering. Steve On 2013-12-13 5:34 PM, Tomas Mikula wrote: On Wed, Sep 25, 2013 at 10:04 PM, Tomas Mikula tomas.mik...@gmail.com wrote: Hi, does anyone know of a way to make a specific ListView item visible, but don't scroll the ListView at all if the item is already in the viewport? I will answer my question from months ago: I have to dig up the VirtualFlow from ListView and the method VirtualFlow.show(int index) does exactly what I wanted. Best, Tomas I am working on a code editor, displaying lines in a ListView. Whenever the caret moves up/down, I want to bring the current line to the viewport. Thanks, Tomas P.S.: To determine if an item is visible, I tried tracking non-empty cells by listening to ListCell#emptyProperty(), but a non-empty cell is not necessarily visible.
Re: Option to keep Stages always on top on JavaFX 8 ?
Look how low the bug number is ... we must fix this. Steve On 2013-12-16 8:54 AM, Anthony Petrov wrote: Hi Peter, You might want to watch this bug: https://javafx-jira.kenai.com/browse/RT-153 -- best regards, Anthony On 12/16/2013 12:22 PM, Peter Penzov wrote: Hi All, I'm also interested in this. Can you share some information? Regards, Peter On Thu, Dec 12, 2013 at 12:27 AM, Herve Girod herve.gi...@gmail.com wrote: I know that this option is not available for JavaFX 2.2, but is it planned for Java 8, and for what time frame if the answer is yes (for example, for initial release or later ?) . This is an important feature for us, because we need to show JavaFX content on top of Windows created on other programs (for example, elements on top of a cartographic system produced by a C++ program, but it's just an example). As there is no alwaysOnTop API on Stage in JavaFX, a workaround is to create a Swing Window, put a JFXPanel in it, and the Scene in the JFXPanel. However, multitouch gestures are not handled by Swing, so these are not working in this case. Our only option is then to put a Stage toFront(), and hope that the other content won't pop on top of JavaFX while the user click on it. This is OK if no part of our Stage need to be transparent to user events, and also if all of the other Windows are created prior to the JavaFX stage is created, but it is not always possible, and we envision cases where our workaround won't work. Regards, Hervé
Re: accessibility
Hi Michael, Accessibility has been on and off the radar for OpenJFX for quite a while now. Some preliminary work was done, but a final implementation and API was never reached. Further, the people who were working on it either left the company or left to work some place else. The thing that makes accessibility difficult is that it is platform specific, has a big API and touches many different component areas. If you think about it, in the case of a visually impaired user, accessibility is presenting a widget system to be navigated that is independent of any output. Although nothing is official, we are looking to deliver accessibility in JDK9. If something is ready earlier, it is possible that it could appear in an earlier release. Thanks for being so patient with us. Steve On 2013-12-15 7:15 AM, Michał Zegan wrote: Hello, I have the following question: Does javafx support or plan to support accessibility? Another question is: if it is planned, then for what release?
Re: (In)Sanity Testing Mondays
Hi all, So we tested and found problems. Let's talk about our findings tomorrow and summarize the results to the list. It's likely faster than back and forth email or posts. I didn't see anyone (in)sane enough in the community taking part. If you tested, you get an opinion on the process. Committers: Tomorrow is the last meeting for the year. We won't meet Christmas or New Years Eve. Even I am not that horrible. You can't fool me. There ain't no Sanity Clause! Steve On 2013-12-13 2:50 PM, Stephen F Northover wrote: Hello all, As discussed at the committer meetings earlier this week, starting next week we are going to try out (In)Sanity Testing Mondays. The community is invited to join in. The goal here is to improve our overall quality substantially with a small investment. The testing is NOT intended to take a day, or even half a day - we are targeting 1 hour for testing each week. So clearly this won't be a deep-dive into each test that you run, it's more of a quick high-level sanity test. If there is a particular area you are concerned with, please feel free to spend more time there and less in other areas, but you do need to run each test that is assigned to you. On Monday morning, in your time zone, ensure that you have the latest build and start. We will be running Ensemble and Modena and other tests but anything is fair game. Committers will have various assignments and platforms but these are not set in stone until the end of time. You don't need to put together any type of formal report, but we encourage everyone to be online, reading email and available by IM while running the tests to discuss results real time as necessary. File JIRA for any new bugs you find and call it done! Be sure to check the One True Dashboard to see of your bug has been found already. https://javafx-jira.kenai.com/secure/Dashboard.jspa?selectPageId=11893 At the next committer meeting and on the list, we'll be discussing how things went and how we want to modify and improve the process going forward, so be prepared with your feedback. None of this is set in stone, so if it doesn't go well, don't despair - we intend to tweak this until it does work well. Cheers, and happy testing! Lisa, Kevin and Steve
Re: accessibility
Hi Mario, There is nothing specific at this time and we are unlikely to start looking at accessibility seriously until next year. Steve On 2013-12-17 4:47 AM, Mario Torre wrote: It would probably make sense to try doing this together rather than waiting for things to happen, this way you could use this wonderful workforce that your community is! Can you maybe point to bugs and/or share with us specific issues (and pain points) yet unresolved? Cheers, Mario 2013/12/16 Stephen F Northover steve.x.northo...@oracle.com: Hi Michael, Accessibility has been on and off the radar for OpenJFX for quite a while now. Some preliminary work was done, but a final implementation and API was never reached. Further, the people who were working on it either left the company or left to work some place else. The thing that makes accessibility difficult is that it is platform specific, has a big API and touches many different component areas. If you think about it, in the case of a visually impaired user, accessibility is presenting a widget system to be navigated that is independent of any output. Although nothing is official, we are looking to deliver accessibility in JDK9. If something is ready earlier, it is possible that it could appear in an earlier release. Thanks for being so patient with us. Steve On 2013-12-15 7:15 AM, Michał Zegan wrote: Hello, I have the following question: Does javafx support or plan to support accessibility? Another question is: if it is planned, then for what release?
Re: accessibility
Hi Tito, Let me give you some background about where we are. There is a prototype implementation that implements some of accessibility for Windows and Mac. This has been released for a while but is disabled in FX for jdk8. There is no public API to make use of it and the FX controls have not been hooked up to use it. The focus for the past while has been on getting FX into jdk8 and meeting the ZBB (Zero Bug Bounce) deadline. Many issues needed to be deferred from 8 and will need to be looked at for 8u20. The deferred issues will likely consume the committers for the rest of the year. Starting next year, which is closer than you think, accessibility will once again be looked into. Please escalate with Oracle representatives and who ever else can give us the ammunition to get this implemented. Thanks! Steve On 2013-12-17 2:43 PM, Kumar, Tito wrote: Just to add to this thread. We have been developing quite extensively over the last year and half with the understanding that JavaFx would be rehab compliant with the release of JDK 8 . At least that was the commitment during JavaOne 2012 conference. We are escalating this issue with local Oracle representatives and executive management to give this a higher priority. As a government agency we cannot deploy if the application is not 508 compliant. It is after all the law of the land. Any assistance from this community is appreciated. Tito Kumar Office of the Legislative Counsel State of California -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Stephen F Northover Sent: Tuesday, December 17, 2013 9:37 AM To: Mario Torre Cc: openjfx-dev@openjdk.java.net Subject: Re: accessibility Hi Mario, There is nothing specific at this time and we are unlikely to start looking at accessibility seriously until next year. Steve On 2013-12-17 4:47 AM, Mario Torre wrote: It would probably make sense to try doing this together rather than waiting for things to happen, this way you could use this wonderful workforce that your community is! Can you maybe point to bugs and/or share with us specific issues (and pain points) yet unresolved? Cheers, Mario 2013/12/16 Stephen F Northover steve.x.northo...@oracle.com: Hi Michael, Accessibility has been on and off the radar for OpenJFX for quite a while now. Some preliminary work was done, but a final implementation and API was never reached. Further, the people who were working on it either left the company or left to work some place else. The thing that makes accessibility difficult is that it is platform specific, has a big API and touches many different component areas. If you think about it, in the case of a visually impaired user, accessibility is presenting a widget system to be navigated that is independent of any output. Although nothing is official, we are looking to deliver accessibility in JDK9. If something is ready earlier, it is possible that it could appear in an earlier release. Thanks for being so patient with us. Steve On 2013-12-15 7:15 AM, Michał Zegan wrote: Hello, I have the following question: Does javafx support or plan to support accessibility? Another question is: if it is planned, then for what release?
Re: Additions to apps/toys
HelloSanity ... a favorite of the (In)Sane testers. Steve On 2013-12-17 4:01 PM, David Hill wrote: As part of RT-34081, I just moved about 50 Hello 'toys' to open source. You can find then under rt/apps/toys/Hello These are toys in the sense that they are not official samples. These are usually vehicles to experiment with various features, or are used as part of quick feature tests. In particular - try HelloSanity. Have fun with them :-)
In(Sanity) Testing Mondays
Hi all, So the sanity testing was a success. I would not say that the universe has been fundamentally altered because of it but the idea that there is a weekly formal time when we kick the tires of FX is a good one. There were some problems getting the correct bits to test but that will be resolved for next week. We will be doing this next week and for the foreseeable future as it was a good forcing function for people to get their environments up to date and make sure that things were generally working. The big winner as a test case was HelloSanity. Although Ensemble exercises much of FX, some committers found the UI to be somewhat cumbersome for testing. There is so much functionality in Ensemble, that a comprehensive test just takes too long. Ensemble is still very important, but perhaps not the best sanity vehicle. I'm thinking that in future, we will look towards testing the FX toys that have recently been open sourced instead of having so many committers poking Ensemble. Further, we need to add some more 3D testing to the list of apps we run (3DViewer). In order to avoid entering duplicates, on the day of the testing, we won't process outstanding issues so that testers can quickly scan the One True Dashboard. https://javafx-jira.kenai.com/secure/Dashboard.jspa?selectPageId=11893 So we will be sanity testing next Monday the 23rd and after that refining the process as we go. As we approach our first 8u20 milestone, the testing effort will ramp up but we can discuss specifics closer to the date. https://wiki.openjdk.java.net/display/OpenJFX/8u20 Steve
Re: In(Sanity) Testing Mondays
Thanks. Fixed. On 2013-12-18 3:43 PM, Ali Ebrahimi wrote: I think there is a typo in wiki page: M1: January 13, 2013 = M1: January 13, 2014 Best Regards, Ali Ebrahimi On Wed, Dec 18, 2013 at 11:02 PM, Stephen F Northover steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com wrote: Hi all, So the sanity testing was a success. I would not say that the universe has been fundamentally altered because of it but the idea that there is a weekly formal time when we kick the tires of FX is a good one. There were some problems getting the correct bits to test but that will be resolved for next week. We will be doing this next week and for the foreseeable future as it was a good forcing function for people to get their environments up to date and make sure that things were generally working. The big winner as a test case was HelloSanity. Although Ensemble exercises much of FX, some committers found the UI to be somewhat cumbersome for testing. There is so much functionality in Ensemble, that a comprehensive test just takes too long. Ensemble is still very important, but perhaps not the best sanity vehicle. I'm thinking that in future, we will look towards testing the FX toys that have recently been open sourced instead of having so many committers poking Ensemble. Further, we need to add some more 3D testing to the list of apps we run (3DViewer). In order to avoid entering duplicates, on the day of the testing, we won't process outstanding issues so that testers can quickly scan the One True Dashboard. https://javafx-jira.kenai.com/secure/Dashboard.jspa?selectPageId=11893 So we will be sanity testing next Monday the 23rd and after that refining the process as we go. As we approach our first 8u20 milestone, the testing effort will ramp up but we can discuss specifics closer to the date. https://wiki.openjdk.java.net/display/OpenJFX/8u20 Steve
Re: IndexOutOfBoundsException with an empty CSS block
Sounds like a bug. Please enter a JIRA with your test code.
https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report
Thanks!
Steve
On 2013-12-22 1:11 PM, Tom Eugelink wrote:
When I assign a style class to a GridPane (which is then added to a
VBox and that to a BorderPane and that in a Popup), like so:
lAppointmentGroupGridPane.getStyleClass().add(AppointmentGroups);
Which has an empty block in CSS:
.AgendaPopup .AppointmentGroups {
}
An exception occurs. Commenting out the empty block in the CSS file
makes the exception go away.
Exception in thread JavaFX Application Thread
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:638)
at java.util.ArrayList.get(ArrayList.java:414)
at com.sun.javafx.css.StyleMap.getCascadingStyles(StyleMap.java:121)
at javafx.scene.CssStyleHelper.getStyle(CssStyleHelper.java:683)
at javafx.scene.CssStyleHelper.lookupFont(CssStyleHelper.java:1548)
at
javafx.scene.CssStyleHelper.transitionToState(CssStyleHelper.java:460)
at javafx.scene.Node.impl_processCSS(Node.java:8677)
at javafx.scene.Parent.impl_processCSS(Parent.java:1216)
at javafx.scene.Parent.impl_processCSS(Parent.java:1228)
at javafx.scene.Parent.impl_processCSS(Parent.java:1228)
at javafx.scene.Parent.impl_processCSS(Parent.java:1228)
at javafx.scene.Node.processCSS(Node.java:8587)
at javafx.scene.Scene.doCSSPass(Scene.java:538)
at javafx.scene.Scene.preferredSize(Scene.java:1504)
at javafx.scene.Scene.impl_preferredSize(Scene.java:1571)
at javafx.stage.Window$9.invalidated(Window.java:733)
at
javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:109)
at
javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:143)
at javafx.stage.Window.setShowing(Window.java:799)
at javafx.stage.Window.show(Window.java:814)
at javafx.stage.PopupWindow.showImpl(PopupWindow.java:403)
at javafx.stage.PopupWindow.show(PopupWindow.java:348)
at
jfxtras.labs.internal.scene.control.skin.AgendaWeekSkin.showMenu(AgendaWeekSkin.java:1969)
at
jfxtras.labs.internal.scene.control.skin.AgendaWeekSkin.access$2700(AgendaWeekSkin.java:84)
at
jfxtras.labs.internal.scene.control.skin.AgendaWeekSkin$MenuIcon$5.handle(AgendaWeekSkin.java:1238)
at
jfxtras.labs.internal.scene.control.skin.AgendaWeekSkin$MenuIcon$5.handle(AgendaWeekSkin.java:1233)
at
com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86)
at
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:238)
at
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
at
com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)
at javafx.event.Event.fireEvent(Event.java:203)
at javafx.scene.Scene$ClickGenerator.postProcess(Scene.java:3321)
at javafx.scene.Scene$ClickGenerator.access$8800(Scene.java:3252)
at javafx.scene.Scene$MouseHandler.process(Scene.java:3600)
at javafx.scene.Scene$MouseHandler.process(Scene.java:3385)
at javafx.scene.Scene$MouseHandler.access$1900(Scene.java:3336)
at javafx.scene.Scene.impl_processMouseEvent(Scene.java:1618)
at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2395)
at
Re: Major regression in mouse event processing..
Whew! Seems this was not a bug in FX. I thought I'd post back to let people know. Steve On 2013-12-21 2:33 PM, Pedro Duque Vieira wrote: Hi, I'm using Java8 build 120. Recently I've spotted a big difference in the way mouse events are being processed - this should have happened between recent builds, not much latter than 1 month from now. I have a chart inside a JFXPanel. I have a listener on that chart for mouse pressed events. I run the app and I press the mouse button over that chart. The mouse pressed event is never fired. This was working with a previous java8 build released not much latter than 1 month ago. Mouse Drag and Mouse Release events are being caught, only Mouse Pressed are ignored. This is a big show stopper and that's why I thought I'd also post an email to this mailing list. I thought it might be a good move since this is a big show stopper and javafx is already in a phase where not much changes are allowed. Don't know if this was necessary though... Jira issue is: https://javafx-jira.kenai.com/browse/RT-35094 Thanks, best regards,
Re: Regression: JavaFX 8 doesn't call listeners in Skin implementations
Hi Florian,
I would enter a JIRA with the steps to make the problem happen and the
smallest possible example code that shows it.
Thanks,
Steve
On 2014-01-02 5:10 PM, Florian Brunner wrote:
I also tried to add a listener directly to
control.getDockingSplitPaneChildren() in case the issue is with
Bindings.bindContent, but also this listener doesn't get called.
member:
private final ListChangeListenerDockingSplitPaneChildBase
dockingSplitPaneChildrenListener = new
ListChangeListenerDockingSplitPaneChildBase() {
@Override
public void onChanged(Change? extends DockingSplitPaneChildBase
change) {
System.out.println(Change!);
}
};
...
in constructor:
control.getDockingSplitPaneChildren().addListener(dockingSplitPaneChildrenListener);
-Florian
Am Donnerstag, 2. Januar 2014, 22.51:23 schrieb Florian Brunner:
Hi,
I'm in the process of upgrading Drombler FX to JavaFX 8 and hit another
regression issue: JavaFX 8 doesn't call listeners in my Skin implementation (it
used to work with JavaFX 2.x !)
Here is the Skin implementation:
https://sourceforge.net/p/drombler/drombler-fx/ci/default/tree/drombler-fx-core-docking/src/main/java/org/drombler/fx/core/docking/impl/skin/DockingSplitPaneSkin.java
When I add something to
control.getDockingSplitPaneChildren()
what should trigger the listeners, then with a debugger I can trace the call up
to the WeakListChangeListener where on line 87 the listener is null.
Note that I'm not using a WeakListChangeListener explicitly - JavaFX 8 must
have created this somewhere and for some reason the listener from the Skin got
lost!
I also tried to keep a reference to my listeners as a member variable in the
Skin implementation, but this didn't work either.
I haven't filed an issue yet because I guess there is already a new way how to
solve this.
Note that I would like to solve this first with this basic Skin
implementation and not with the new SkinBase class just yet, as I'm not familiar with
that new class yet. One refactoring step at a time. ;-)
-Florian
Re: General schedule/roadmap/status
Hi Kevin, Oracle builds Java 8 using the OpenJDK. OpenJFX is a part of the OpenJDK and is built into Oracle's Java 8 distribution. The rest of these questions are really for the various different Linux distributions that consume open source projects and produce their own builds. I suggest that you ping them and find out their plans. Thanks, Steve On 2014-01-02 7:24 PM, Kevin Smith wrote: Hi all, If my questions are answered by existing web pages or archived email threads, please point me to them. I looked, but could not find any. We are looking at committing to JavaFX for some major new UI work, and want to understand the likely availability of JavaFX for our OpenJDK users. My understanding is that JavaFX is/will be built into Java 8. That's true for OpenJDK 8 also, right? I am aware of Oracle's Java 8 build, and I found a Fedora OpenJDK 8 package. I don't see anything like that for Debian, and couldn't find any mention of any current or planned work on one. Does anyone know when a preview version of OpenJDK might be packaged for Debian? The scheduled release of Oracle Java 8 is in a few months. Will the OpenJDK release be simultaneous with that? Earlier? Based on past history, is there likely to be a long delay between the official Java 8 release, and when it is available in a public Debian (or Ubuntu) release? Do they tend to ship preview releases, or do they only release full public versions of OpenJDK? There were milestones in October and November related to ZBB and other quality levels? Have those been hit? How is Open JavaFX looking relative to the big release date? Has anyone packaged Open JavaFX for Java 7 (e.g. on Debian)? Thanks much, Kevin
Re: JavaFX versus AWT/Swing Hardware Acceleration
Hi Ryan, I'll let others describe hardware acceleration in AWT/Swing but in JavaFX, D3D and ES2 shaders are used to draw. These run directly on the graphics card and render data that is downloaded there. Because JavaFX has a scene graph, it has a notion of what has been changed and can render only a subset of the scene graph nodes. This is a very high level description of JavaFX but captures the essence of what is happening. Any other FX committers want to comment? Steve On 2014-01-01 1:39 PM, Ryan Cuprak wrote: What is the difference between hardware acceleration in JavaFX versus Swing/AWT? I heard a while back someone claim that Swing/AWT could never fully leverage hardware acceleration. However there are the usual mix of -D parameters (sun.java2.opengl/sun.java2d.d3d, etc.) for Swing/AWT. So I am just wondering how JavaFX’s acceleration differs from the hardware acceleration in Swing. When I was giving a talk at a JUG meeting someone called me out on the hardware acceleration bit and I realized I didn’t fully understand the differences between the two. I understand that JavaFX has a scene graph and Swing doesn’t etc. So I am assuming that the scene graph operations are optimized on the GPU whereas if you were trying to replicate a scene graph in Swing you would obviously be doing all the work on the CPU. So Swing’s hardware acceleration is more about buffers? I did come across this article: https://weblogs.java.net/blog/opinali/archive/2010/05/03/first-long-look-javafx-13-and-prism Specifically this line caught my attention Prism finally renders effects with full hardware acceleration and without the extra buffer copies that spoil effects on the Swing toolkit.” This article is a dated - brings up a second question about hardware acceleration with a hybrid Swing/JavaFX application - what happens? Thanks, -Ryan
Post commit review: [Re: hg: openjfx/8u-dev/rt: RT-35147: [Android, Ensemble8] App should react to hardware buttons on Android]
Hi Alex, Samples were changed to support Android. Apparently, hitting escape twice should exit an application and this behavior was coded into EnsembleApp. I'm not an Android guy but if this is standard Android behavior, it should be part of JFX, not the example code. Anyhow, I'll let Stefan or Johan comment on this and they can enter a follow on JIRA. Steve On 2014-01-03 12:32 PM, hang...@oracle.com wrote: Changeset: 6f0901527ad0 Author:snorthov Date: 2014-01-03 12:23 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6f0901527ad0 RT-35147: [Android, Ensemble8] App should react to hardware buttons on Android Reviewed-by: snorthov Contributed-by: Stefan Fuchs snfu...@gmx.de ! apps/samples/Ensemble8/src/app/java/ensemble/EnsembleApp.java ! apps/samples/Ensemble8/src/app/java/ensemble/PlatformFeatures.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/Description.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SamplePageContent.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SourceTab.java ! apps/samples/Ensemble8/src/app/java/ensemble/util/FeatureChecker.java ! modules/base/src/main/java/com/sun/javafx/PlatformUtil.java
Re: Very poor performance of JavaFX on iPhone - 6 months later
Hi Tobias, Sorry about that. Looking at the bug, it seems to me that we have gotten to the bottom of it. Some iOS devices are scrolling fine while others are slower. The difference seems to be that high dpi disables optimizations and this causes the slowness on iOS. The same optimizations are disabled on the desktop, but the desktop is much faster and people don't notice. There was some discussion about performance in the simulator, but we should ignore that. Performance on the device is what matters. iOS and Android are not currently supported platforms for JavaFX. We are looking towards the community to step up and submit patches to take these ports forward. Johan Vos and others are helping with Android. Are you interested in working on iOS? If so, please build on the patches in https://javafx-jira.kenai.com/browse/RT-31453 and take the work forward. The first step would be to prove that we can be fast (which I think we can if we run with the optimizations) then understand how to turn the optimizations back on. Steve On 2014-01-03 3:28 PM, Tobias Bley wrote: Hi, many months ago I reported the „poor performance on iOS“ issue (https://javafx-jira.kenai.com/browse/RT-31453). Now 6 months later the bug is already open and no one of Oracle answers me on Jira. What’s up? How can we fix this important bug? Best, Tobi
Re: Post commit review: [Re: hg: openjfx/8u-dev/rt: RT-35147: [Android, Ensemble8] App should react to hardware buttons on Android]
If you feel that further work needs to be done here, please enter a JIRA and include this discussion. Thanks, Steve On 2014-01-03 2:43 PM, Stefan Fuchs wrote: Hi, well, the back button is always used to go back one dialog level, until the start screen has be reached. (Dialogs are canceled, browsers go to previous website, etc...) If you press the back button on the start screen of the app, I found three different strategies to handle the back button: 1. Exit the app on first button press (examples: WhatsApp, Google Maps) 2. Hide the app on first button press and let the system kill the application, if system memory is exhausted. (examples: FireFox, Chrome) 3. Exit the app on second button press (note that most apps using this strategy print a notice message, after the first key press, which is currently not implemented for Ensemble8) (examples: Samsungs App Store) Stefan Stephen F Northover wrote: Hi Alex, Samples were changed to support Android. Apparently, hitting escape twice should exit an application and this behavior was coded into EnsembleApp. I'm not an Android guy but if this is standard Android behavior, it should be part of JFX, not the example code. Anyhow, I'll let Stefan or Johan comment on this and they can enter a follow on JIRA. Steve On 2014-01-03 12:32 PM, hang...@oracle.com wrote: Changeset: 6f0901527ad0 Author:snorthov Date: 2014-01-03 12:23 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6f0901527ad0 RT-35147: [Android, Ensemble8] App should react to hardware buttons on Android Reviewed-by: snorthov Contributed-by: Stefan Fuchs snfu...@gmx.de ! apps/samples/Ensemble8/src/app/java/ensemble/EnsembleApp.java ! apps/samples/Ensemble8/src/app/java/ensemble/PlatformFeatures.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/Description.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SamplePageContent.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SourceTab.java ! apps/samples/Ensemble8/src/app/java/ensemble/util/FeatureChecker.java ! modules/base/src/main/java/com/sun/javafx/PlatformUtil.java
Re: Very poor performance of JavaFX on iPhone - 6 months later
Hi Jeff, Please add your weight to the JIRA (indicate the hardware you are using). A fix for the desktop should also fix the problem on iOS. Steve On 2014-01-03 5:45 PM, Jeff Martin wrote: I noticed the high-dpi problem on a high-end MacBook Pro Retina. Took me by surprise for JavaOne demos since I usually use an external monitor (non-retina). I ended up switching to low dpi. jeff On Jan 3, 2014, at 3:59 PM, Stephen F Northover steve.x.northo...@oracle.com wrote: Hi Tobias, Sorry about that. Looking at the bug, it seems to me that we have gotten to the bottom of it. Some iOS devices are scrolling fine while others are slower. The difference seems to be that high dpi disables optimizations and this causes the slowness on iOS. The same optimizations are disabled on the desktop, but the desktop is much faster and people don't notice. There was some discussion about performance in the simulator, but we should ignore that. Performance on the device is what matters. iOS and Android are not currently supported platforms for JavaFX. We are looking towards the community to step up and submit patches to take these ports forward. Johan Vos and others are helping with Android. Are you interested in working on iOS? If so, please build on the patches in https://javafx-jira.kenai.com/browse/RT-31453 and take the work forward. The first step would be to prove that we can be fast (which I think we can if we run with the optimizations) then understand how to turn the optimizations back on. Steve On 2014-01-03 3:28 PM, Tobias Bley wrote: Hi, many months ago I reported the „poor performance on iOS“ issue (https://javafx-jira.kenai.com/browse/RT-31453). Now 6 months later the bug is already open and no one of Oracle answers me on Jira. What’s up? How can we fix this important bug? Best, Tobi
Re: How to draw line to connect Two components at run time?
Investigate SplitPane? Not sure what the question is. Steve On 2014-01-06 4:45 PM, Amine Tengilimoglu wrote: Hi; I met a problem and need urgent help from you here, I am new in javafx ... draw lines between any two components(are panes) at RUN-TIME, not at design time pls advice how to do it?
Re: Regression: JavaFX 8 doesn't call listeners in Skin implementations
If the code sample is small, then it can be pasted into comments.
Otherwise, please contact the bug owner and he/she can attach the files.
This is not optimal. I'm looking into getting attachments re-enabled
for the JIRA.
Steve
On 2014-01-07 5:28 PM, Florian Brunner wrote:
Hi Steve,
Ok, I've reported the issue here:
https://javafx-jira.kenai.com/browse/RT-35208
I even have a small sample application with a small custom control showing the
issue, but I don't have an option to add an attachement to the issue in Jira...
-Florian
Am Freitag, 3. Januar 2014, 11.23:03 schrieb Stephen F Northover:
Hi Florian,
I would enter a JIRA with the steps to make the problem happen and the
smallest possible example code that shows it.
Thanks,
Steve
On 2014-01-02 5:10 PM, Florian Brunner wrote:
I also tried to add a listener directly to
control.getDockingSplitPaneChildren() in case the issue is with
Bindings.bindContent, but also this listener doesn't get called.
member:
private final ListChangeListenerDockingSplitPaneChildBase
dockingSplitPaneChildrenListener = new
ListChangeListenerDockingSplitPaneChildBase() {
@Override
public void onChanged(Change? extends DockingSplitPaneChildBase
change) {
System.out.println(Change!);
}
};
...
in constructor:
control.getDockingSplitPaneChildren().addListener(dockingSplitPaneChildrenListener);
-Florian
Am Donnerstag, 2. Januar 2014, 22.51:23 schrieb Florian Brunner:
Hi,
I'm in the process of upgrading Drombler FX to JavaFX 8 and hit another
regression issue: JavaFX 8 doesn't call listeners in my Skin implementation (it
used to work with JavaFX 2.x !)
Here is the Skin implementation:
https://sourceforge.net/p/drombler/drombler-fx/ci/default/tree/drombler-fx-core-docking/src/main/java/org/drombler/fx/core/docking/impl/skin/DockingSplitPaneSkin.java
When I add something to
control.getDockingSplitPaneChildren()
what should trigger the listeners, then with a debugger I can trace the call up
to the WeakListChangeListener where on line 87 the listener is null.
Note that I'm not using a WeakListChangeListener explicitly - JavaFX 8 must
have created this somewhere and for some reason the listener from the Skin got
lost!
I also tried to keep a reference to my listeners as a member variable in the
Skin implementation, but this didn't work either.
I haven't filed an issue yet because I guess there is already a new way how to
solve this.
Note that I would like to solve this first with this basic Skin
implementation and not with the new SkinBase class just yet, as I'm not familiar with
that new class yet. One refactoring step at a time. ;-)
-Florian
Re: Bug Pass Friday
Thanks David. I know this is painful but in the end we'll be in a better place. Steve On 2014-01-10 8:38 AM, David Grieve wrote: I'm going to take a pass at bugs assigned to Mick. https://javafx-jira.kenai.com/issues/?jql=project%20%3D%20RT%20AND%20issuetype%20%3D%20Bug%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20%3D%20mickf If I get through that list, I'll start in on https://javafx-jira.kenai.com/issues/?jql=project%20%3D%20RT%20AND%20issuetype%20%3D%20Bug%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20%3D%20paru These are just bugs, not tweaks or features. On Jan 7, 2014, at 4:27 PM, Stephen F Northover steve.x.northo...@oracle.com wrote: Hello Committers, I'd like to organize our work for 8u20 this week. Recall that 8u20 is about improving the quality of FX rather than implementing new features. https://wiki.openjdk.java.net/display/OpenJFX/8u20 Bug Owners: I suggest that we implement Bug Pass Friday where component owners and reviewers assess their bug backlog, clean up really old bugs that no longer apply and target the remaining bugs for either 8u20 or 9. In the case of bugs that don't have steps or sample code (and otherwise can't be reproduced), we should close them as 'Incomplete and ask nicely for more information: https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report Otherwise, please check the priority and adjust accordingly. Of course, crashes, exceptions and failed functionality tend to rate high. Component Owners: We have bugs that are unassigned or assigned to the wrong person. Component owners are asked to do a pass and ensure that all bugs that are assigned are assigned to owners or reviewers. Of course there will be exceptions and when in doubt, email the list or contact us and we will update the code ownership tables. https://wiki.openjdk.java.net/display/OpenJFX/Code+Ownership Unassigned bugs can stay that way or be assigned. It is likely that Kevin and I will do a pass on the unassigned bugs at a later time but if you know that a bug belongs to a certain person, assign it. This Tuesday is our first milestone and it will be uneventful because of the holidays. However, starting next week, we should have a good idea about the work that lies ahead and how much trouble we are in! Steve and Kevin
Re: Post commit review: [Re: hg: openjfx/8u-dev/rt: RT-35147: [Android, Ensemble8] App should react to hardware buttons on Android]
What ever the decision on this, if there is further action, please enter a JIRA. If not, then the discussion is lost to ether. Steve On 2014-01-13 8:49 AM, Alexander Kouznetsov wrote: Hi Stefan, Thank you for this summary. As an android user I would say that #2 is not a good options for Ensemble. #3 is better than #1. However, it usually responds to the second key press only within a short period of time. About the time a notice message is shown. Best regards, Alexander Kouznetsov (408) 276-0387 On 3 янв 2014 23:43, Stefan Fuchs wrote: Hi, well, the back button is always used to go back one dialog level, until the start screen has be reached. (Dialogs are canceled, browsers go to previous website, etc...) If you press the back button on the start screen of the app, I found three different strategies to handle the back button: 1. Exit the app on first button press (examples: WhatsApp, Google Maps) 2. Hide the app on first button press and let the system kill the application, if system memory is exhausted. (examples: FireFox, Chrome) 3. Exit the app on second button press (note that most apps using this strategy print a notice message, after the first key press, which is currently not implemented for Ensemble8) (examples: Samsungs App Store) Stefan Stephen F Northover wrote: Hi Alex, Samples were changed to support Android. Apparently, hitting escape twice should exit an application and this behavior was coded into EnsembleApp. I'm not an Android guy but if this is standard Android behavior, it should be part of JFX, not the example code. Anyhow, I'll let Stefan or Johan comment on this and they can enter a follow on JIRA. Steve On 2014-01-03 12:32 PM, hang...@oracle.com wrote: Changeset: 6f0901527ad0 Author:snorthov Date: 2014-01-03 12:23 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6f0901527ad0 RT-35147: [Android, Ensemble8] App should react to hardware buttons on Android Reviewed-by: snorthov Contributed-by: Stefan Fuchs snfu...@gmx.de ! apps/samples/Ensemble8/src/app/java/ensemble/EnsembleApp.java ! apps/samples/Ensemble8/src/app/java/ensemble/PlatformFeatures.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/Description.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SamplePageContent.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SourceTab.java ! apps/samples/Ensemble8/src/app/java/ensemble/util/FeatureChecker.java ! modules/base/src/main/java/com/sun/javafx/PlatformUtil.java
Re: Post commit review: [Re: hg: openjfx/8u-dev/rt: RT-35147: [Android, Ensemble8] App should react to hardware buttons on Android]
Fix it. You own the code. If you can test on an Android device, then great. Otherwise, get Stefan or Johan to test your changes. Steve On 2014-01-13 8:46 AM, Alexander Kouznetsov wrote: Hi Steve, In general it looks good but I want to correct some parts of it. How should I proceed in this case? Best regards, Alexander Kouznetsov (408) 276-0387 On 3 янв 2014 21:44, Stephen F Northover wrote: Hi Alex, Samples were changed to support Android. Apparently, hitting escape twice should exit an application and this behavior was coded into EnsembleApp. I'm not an Android guy but if this is standard Android behavior, it should be part of JFX, not the example code. Anyhow, I'll let Stefan or Johan comment on this and they can enter a follow on JIRA. Steve On 2014-01-03 12:32 PM, hang...@oracle.com wrote: Changeset: 6f0901527ad0 Author:snorthov Date: 2014-01-03 12:23 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6f0901527ad0 RT-35147: [Android, Ensemble8] App should react to hardware buttons on Android Reviewed-by: snorthov Contributed-by: Stefan Fuchs snfu...@gmx.de ! apps/samples/Ensemble8/src/app/java/ensemble/EnsembleApp.java ! apps/samples/Ensemble8/src/app/java/ensemble/PlatformFeatures.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/Description.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SamplePageContent.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SourceTab.java ! apps/samples/Ensemble8/src/app/java/ensemble/util/FeatureChecker.java ! modules/base/src/main/java/com/sun/javafx/PlatformUtil.java
Re: OpenGL on Windows
Essentially, OpenGL on Windows would be another platform to support. If you build your own OpenJFX for Windows, it will work but it is completely unsupported. https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX If you run into any problems after you have successfully built (ie. the ES2 code is not there), open a JIRA request for OpenGL support on Windows and we can follow up there. Even if we don't fix the JIRA, we can capture the information for other that might want to do the same thing. Steve On 2014-01-13 1:19 PM, Felix Bembrick wrote: Having watched the presentation from Stephen and Felipe about integrating JavaFX and native technologies such as OpenGL, I am inspired to work on a solution for my own needs for fast rendering of thousands of objects using the techniques in the video which I would then contribute to the community. However, it's quite clear that any OpenGL based solution is not going to work on Windows because OpenGL is not enabled on that platform. Given that I don't want to write code that supports both OpenGL and D3D, could someone answer these questions? 1. Why is OpenGL not enabled on Windows? Is it a performance thing? Is it because of poor text rendering with OpenGL? 2. What's involved in hacking Prism to enable OpenGL? 3. If 2 is not possible, is there some way to develop an abstraction layer on top of both OpenGL and D3D? Thanks, Felix
Re: OpenGL on Windows
At one point there was one or one that had an API close to JOGL. It was slower and bigger that what we have now. I would not be opposed to someone in the community looking into this again, be we wouldn't revisit it. Steve On 2014-01-14 10:43 AM, Tom Schindl wrote: Would it be better to work on a jogl prism pipeline itself? Tom Von meinem iPhone gesendet Am 14.01.2014 um 16:15 schrieb Stephen F Northover steve.x.northo...@oracle.com: It should all just work. The first step is to go and build OpenJFX. If something doesn't work, we can help you through JIRA and this list. Steve On 2014-01-14 6:57 AM, Felix Bembrick wrote: Thanks Stephen. If I were to build an OpenGL-based platform for Windows, would the font rendering technique need to change? That is, could DirectWrite still be used to rasterise the glyphs (if that's what's currently happening) and would there be any reason for the text rendering quality to degrade? You mentioned that ES2 code is not there: was that just an example or will I really have to address this problem? Thanks, Felix On 14 January 2014 06:28, Stephen F Northover steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com wrote: Essentially, OpenGL on Windows would be another platform to support. If you build your own OpenJFX for Windows, it will work but it is completely unsupported. https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX If you run into any problems after you have successfully built (ie. the ES2 code is not there), open a JIRA request for OpenGL support on Windows and we can follow up there. Even if we don't fix the JIRA, we can capture the information for other that might want to do the same thing. Steve On 2014-01-13 1:19 PM, Felix Bembrick wrote: Having watched the presentation from Stephen and Felipe about integrating JavaFX and native technologies such as OpenGL, I am inspired to work on a solution for my own needs for fast rendering of thousands of objects using the techniques in the video which I would then contribute to the community. However, it's quite clear that any OpenGL based solution is not going to work on Windows because OpenGL is not enabled on that platform. Given that I don't want to write code that supports both OpenGL and D3D, could someone answer these questions? 1. Why is OpenGL not enabled on Windows? Is it a performance thing? Is it because of poor text rendering with OpenGL? 2. What's involved in hacking Prism to enable OpenGL? 3. If 2 is not possible, is there some way to develop an abstraction layer on top of both OpenGL and D3D? Thanks, Felix
Re: JavaFX changes in early acess JDK 8 versions
I suppose we could query JIRA for bugs fixed within a certain date range. Steve On 2014-01-13 7:25 PM, Herve Girod wrote: OK, I understand, but thanks for your answer though. Herve 2014/1/14 Kevin Rushforth kevin.rushfo...@oracle.com Unfortunately, this is not currently available, as we don't have a good way to track and tag the bugs as to which build they were fixed in. -- Kevin Herve Girod wrote: Hello, I just noticed that the new JDK 8 build 123 appeared today or yesterday. As usual it include the change list for the JDK. However, how is it possible to know what JavaFX changes (JIRA RT ?) have been applied to each build ? Thanks, Hervé
Re: JavaFx gtk3 support
Hi Ilya, Sorry, just processed the bug today. Can we carry on the conversation there? https://javafx-jira.kenai.com/browse/RT-35264 Steve On 2014-01-15 5:54 AM, Ilya Buziuk wrote: Hello. I'm really interested in high level plans about gtk3 support. Assuming that starting from Luna build eclipse uses gtk3 libs when available on Linux/Unix (https://bugs.eclipse.org/bugs/show_bug.cgi?id=420182 ) , which makes javaFx incompatible, cause it contains hardcoded references to gtk2. I do believe that in a long run compatibility with gtk3 is not only useful, but vital for eclipse / SWT support. So, I have created an issue - https://javafx-jira.kenai.com/browse/RT-35264 . However, I got no feedback yet. I'm also take an interest in javaFx WebView (WebKit). It has loads of cool features indeed! Debugger API is a killer one. So, I guess it's also compiled against gtk2, isn't it? On Wed, Jan 15, 2014 at 1:42 PM, Ilya Buziuk ibuz...@exadel.com wrote: Hello. I'm really interested in high level plans about gtk3 support. Assuming that starting from Luna build eclipse uses gtk3 libs when available on Linux/Unix (https://bugs.eclipse.org/bugs/show_bug.cgi?id=420182 ) , which makes javaFx incompatible, cause it contains hardcoded references to gtk2. I do believe that in a long run compatibility with gtk3 is not only useful, but vital for eclipse / SWT support. So, I have created an issue - https://javafx-jira.kenai.com/browse/RT-35264 . However, I got no feedback yet. I'm also take an interest in javaFx WebView (WebKit). It has loads of cool features indeed! Debugger API is a killer one. So, I guess it's also compiled against gtk2, isn't it? -- Best Regards, Ilya Buziuk
Re: The disableProperty / disabledProperty mess
Funny, this was one of the first things that I asked when I came to FX. I believe we are using the same terminology as the disabled property on DOM nodes. At this point, we cannot change it and I'm not thrilled about adding an alias but let's discuss this in the JIRA. Steve On 2014-01-15 6:43 AM, Randahl Fink Isaksen wrote: I keep thinking we need to fix the disableProperty / disabledProperty mess, so I have created a Jira issue, which I hope you will all vote for: Please see the description below Randahl ——— From https://javafx-jira.kenai.com/browse/RT-35349 I know I am late to the game with this request, but please read this in full – there is a point to this. I have used JavaFX since the early access days, and all the time I keep thinking that the disableProperty and disabledProperty of Node work in a counter-intuitive manner. Like most other developers, I typically use names of boolean properties to express the positive state of something, as in is it complete or is it ready. Usually, JavaFX property names also follow this idea, e.g. is it visible, is it managed, is it pressed and so on. However, one property in JavaFX is reversed, and that leads to confusion. When you decide wether is it enabled for a Node, you do so by controlling the opposite, namely is it disabled. To add to that confusion, there is both disableProperty and a disabledProperty. I suggest improving JavaFX to follow almost all other GUI frameworks (including Swing), by introducing an enabledProperty. Such a property could be implemented in a backwards compatible manner by keeping the existing disableProperty but marking it as deprecated. With an enabledProperty, there are literally thousands of lines of code in my application that would be much more readable. Today I write something like this to make a continue button be enabled when a form is complete: continueButton.disableProperty().bind(form.validProperty().not()); – Note that above my form's validProperty expresses something positive, that the form is valid, while the button's enabled property is expressed as something negative, namely is it NOT enabled using the disableProperty. This requires me to use the not() method. With the new enabledProperty() I could write code, that was more easy to read: continueButton.enabledProperty().bind(form.validProperty()); I hope it is evident to everyone that this line is much more readable, and I think the enabledProperty would make the JavaFX API easier to use – also for newcomers learning to program JavaFX.
Re: Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method]
Hi John,
The goal is not to end the discussion!
It's a trade off. Mailing lists are good because they provide a
threaded discussion. JIRA is bad because it is not threaded. JIRA has
the advantage that it captures data in a single place and provides a
good history of why a decision was made.
There's no right answer here but the policy that the FX committers is
using is to try to capture as much as possible in JIRA.
Steve
On 2014-01-22 5:29 PM, John Hendrikx wrote:
Unfortunately, discussing things in JIRA works very poorly and is a
good way to end a productive discussion IMHO. Mailinglists are much
better suited to the task, as thousands of interesting mailinglists
accross many developer communities will atest to.
Keeping a record is good, aren't these mailinglists archived?
--John
On 22/01/2014 18:47, Daniel Blaukopf wrote:
Hi Martin, Randahl, Tom, Richard, Tomas and Ali,
This is a productive discussion, but once we get to this level of
detail JIRA is the place to have it, so that we don’t lose our record
of it. Would you continue the discussion on
https://javafx-jira.kenai.com/browse/RT-25613 ?
See
https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews#CodeReviews-TechnicalDiscussionsandCodeReviews
Thanks,
Daniel
On Jan 22, 2014, at 7:23 PM, Stephen F
Northoversteve.x.northo...@oracle.com wrote:
If we add this API, I like addListener(InvalidationListener,
boolean) better than ensureListener().
Steve
On 2014-01-22 8:20 AM, Ali Ebrahimi wrote:
I suggest adding another overload for addListener method taking
boolean
parameter duplicateAllowed or duplicateNotAllowed.
On Wed, Jan 22, 2014 at 3:00 PM, Richard
Bairrichard.b...@oracle.comwrote:
The default implementation (for Observable) would look like this:
public default void ensureListener(InvalidationListener listener) {
removeListener(listener);
addListener(listener);
}
subclasses might do something more effective. The same would
apply to
ObservableValue and ChangeListener and Observable[List|Set|Map] and
[List|Set|Map]ChangeListener.
Well this would destroy the order! I expect listeners to be
called in
the correct order not?
That’s a good point :-(
Why doing a remove and not simply check if the
listener has already been added?
Because there is no way to check, except in the implementation.
From the
Observable interface level, there is no way to a) force all
implementations
of the interface to implement the method correctly (without
breaking source
compatibility anyway), or b) to provide a reasonable default
implementation.
Maybe this is one of those things we can’t fix on the Observable
interface
and just have to provide implementations of on our concrete
properties.
Richard
Re: Monocle with VNC for Jenkins
Hi Uwe, You need to ensure that jfxrt.jar is not in the ext directory in your jdk8 install or it will get seen first. I am assuming you have deleted it or you could not have built OpenJFX (at least the last time I tried). Anyhow, it looks like a class loader problem. Let's move this discussion to the JIRA. Steve On 2014-01-23 4:53 AM, Uwe Sander wrote: Stephen F Northoversteve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com , 22/1/2014 5:20 PM: There is a StubToolkit. It is not part of the jar that is shipped with the JDK. You will need to build JFX and test against your build. https://javafx-jira.kenai.com/browse/RT-35010 That's what I did. When I run the SimpleControlLauncher class from your RT 35010 comment with -Djavafx.toolkit=com.sun.javafx.pgstub.StubToolkit, I get the following exception: java.lang.ClassNotFoundException: com.sun.javafx.pgstub.StubToolkit at java.net.URLClassLoader$1.run(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at com.sun.javafx.tk.Toolkit.getToolkit(Unknown Source) at com.sun.javafx.application.PlatformImpl.startup(Unknown Source) at com.sun.javafx.application.LauncherImpl.startToolkit(Unknown Source) at com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(Unknown Source) at com.sun.javafx.application.LauncherImpl.launchApplication(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.launcher.LauncherHelper$FXHelper.main(Unknown Source) Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.launcher.LauncherHelper$FXHelper.main(Unknown Source) Caused by: java.lang.RuntimeException: No toolkit found at com.sun.javafx.tk.Toolkit.getToolkit(Unknown Source) The StubToolkit jar is on the classpath, which I checked by adding Object newInstance = Class.forName(com.sun.javafx.pgstub.StubToolkit).newInstance(); to the SimpleControlLauncher code. No exception is thrown when I run the class without the command line parameter. I use jdk8 b124 under Windows 7. Any idea why this is not working? And is this the correct place to discuss about it or should I add a comment to the Jira issue? Uwe
Re: javafx on android - weird box within regions
Hi Christoph, We don't build or run Android so it's a pain to recreate the problem. Please confirm the bug on a desktop platform. It might likely be the bug David is talking about. Also, on desktop, we can't do more than guess at a problem without code: https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report Thanks, Steve On 2014-01-28 3:15 PM, David Grieve wrote: https://javafx-jira.kenai.com/browse/RT-30479 is probably the issue you are bumping up against. On Jan 28, 2014, at 2:29 PM, Christoph Caks cc...@bestsolution.at wrote: Hi, I have a question regarding regions on android it seems that all regions with a set background have some kind of white box inside (in this case it is gray - its color has to do something with the background (in this case its aqua) look at the attached screenshot it is a very simple application with just one region anybody experienced the same behaviour - or has a workaround for this issue? I'm using these instructions to get a build: https://bitbucket.org/javafxports/android/wiki/Home greetings Christoph
Re: Improperly triaged bugs
Here is a link describing the triage process. If you triage a bug, you need to do this. https://wiki.openjdk.java.net/display/OpenJFX/Triage Steve On 2014-02-05 1:58 PM, Kevin Rushforth wrote: The following is a list of improperly triaged bugs that have been moved out of the new state, and are open with an EMPTY fix version. https://javafx-jira.kenai.com/issues/?filter=14996 This is an invalid state for a bug, so I am going to set all of them to 9 unless I know of a reason it must be fixed sooner. The assignee should feel free to move it to 8u20 if they would like to fix it in that release. -- Kevin
Re: Failure to find any font (probably on Embedded)
Embedding URL's in code ... a recipe for stale URL's. I suppose that we
put URL's in JavaDoc though.
Steve
On 2014-02-12 1:53 PM, Kevin Rushforth wrote:
A more informative message and an earlier detection both sound good.
Not sure about the pointer to the Wiki page, though. We haven't done
that in the past that I am aware of. If we do want to go down that
path, I would suggest a pointer to a single, well-known support page
that could describe various end-user configuration issues that we
might want to document.
-- Kevin
David Hill wrote:
I am chasing a edge case that probably only happens in certain
Embedded configurations. If we don't find *any* fonts, then we
quietly fail and blame it on CSS :-)
I say blame it on CSS because the resulting hard failure is:
Exception in thread JavaFX Application Thread
java.lang.NoClassDefFoundError: Could not initialize class
javafx.scene.CssStyleHelper
This is because CSS needs a font for various calculations.
With Embedded, if libfontconfig is not present (or improperly
configured) you will not find any fonts.
I would like thoughts on my putting a more informative error message
out, and making zero fonts an earlier hard failure.
What I would really like to do is to be able to put a URL to a Fonts
wiki page (like:
https://wiki.openjdk.java.net/display/OpenJFX/Font+Setup) but not
sure how well that would stand up to the test of time.
The code point in FontConfigManager is:
if (anyFont == null) {
if (debugFonts) {
System.err.println(Fontconfig returned no fonts at
all.);
}
fontConfigFailed = true;
return;
OpenJFX Lambda Day, Feb 25th 2014
Hello all, Mark it on your calendar. Feb 25th is OpenJFX Lambda day. On that day, we will lock the code base, lambdify everything in sight, and then open up for business again. One thing that we won't be doing right away is converting our code to use streams and other JDK8 features but this is inevitable (perhaps after 8u20). We are part of the JDK, we ship with the JDK so we will use features from the JDK. Like Lambda's to the slaughter the Android and iOS ports of OpenJFX will be affected. We've been discussing the use of RetroLambda on and off in JIRA for a while and it seems that it will work for both ports. We care about these ports and it is possible that Lambda Day will slip for one reason or another. For one thing, the lambdifying tools blow up some of the source making lambda conversion a somewhat manual process. Hopefully we can get the bugs fixed before the day. On that day, I will be listening to 'The Lambda Lies Down on Broadway all day. Those of you with children might prefer Mary had a little Lambda. Despite being called The Lambda Police, I am and old Lisper and a card carrying member of the Knights of the Lambda Calculus. Look that one up. I know the founder personally but will never tell who it is. Steve
Re: Heads up... changing the rt/build/*sdk/ directory
We are not currently using the gradle plugins for any of the IDE's.
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE
Steve
On 2014-02-14 7:26 PM, Scott Palmer wrote:
Are you guys using the NetBeans Gradle plugin?
Scott
On Fri, Feb 14, 2014 at 2:17 PM, Kevin Rushforth kevin.rushfo...@oracle.com
wrote:
Thanks David.
For NB 7.4 (or 8) users, you should be able to just open up the apps
projects in NB and have it work without needing to do anything extra.
-- Kevin
David Hill wrote:
As part of this Jira https://javafx-jira.kenai.com/browse/RT-35809, we
are trying to make working in rt/apps easier.
To do that, we found that the only way to make the IDEs happy is be able
to provide a common path to host build jfxrt.jar.
Currently we have:
rt/build/${hosttype}-sdk (rt/build/linux-sdk/...)
which requires evaluation that Netbeans does not want to do.
We do need to support cross builds, so here is what we came up with,
explained here in the new improved comment from build.gradle
// The jfxrt task is responsible for creating the jfxrt.jar. A
developer may
// have multiple SDK's on their system at any one time, depending on
which
// cross compiles they have done. For example, I might have:
// build/ios-sdk/rt/lib/ext/jfxrt.jar
// build/armhf-sdk/rt/lib/ext/jfxrt.jar
// and so forth. The default host build will always install into 'sdk'
// allowing for uses where a known sdk path is needed (like IDEs)
// build/sdk/rt/lib/ext/jfxrt.jar
// This arrangement allows for multiple independent SDKs to
// exist on a developer's system.
After you sync, you will probably want to perform a clean build.
And then try out the apps, in the new easier to use format.
Note: for now, you will still need to specify the JDK for ant/nb, like
this:
ant -Dplatforms.JDK_1.8.home=$JAVA_HOME
Re: IMPORTANT: Rampdown / stabilization of 8u20 for milestone M2
Note that changes to IDE files, JavaDoc and other things that do not affect the M2 bits can be released as usual. Having said that, the day before the final freeze would not be a good one to release a billion JavaDoc changes and blow the mind of the release engineers! Steve On 2014-02-14 9:17 AM, Kevin Rushforth wrote: Hi OpenJFX committers, After this coming Monday's FX build, which will go into 8u20-b02, we will start ramping down for our M2 milestone build (aka 8u20-b03). This particular milestone is important for the embedded platform. As a result, you will need to observe the following rules for any commit. 1) Sunday, Feb 16 at 11:00 pm Pacific time: All planned changes for b02 should be in (our test build is scheduled to start at 11pm that day). The usual rules apply for changesets pushed prior to that time. 2) All changesets that are pushed after 11:00 pm Pacific time on Sunday, Feb 16 will need additional scrutiny to go in. In addition to your normal reviewer you must get a +1 from one of the following, even if you would normally do a post-commit review: Daniel Blaukopf Steve Northover Kevin Rushforth Lisa Selle 3) Monday, Feb 17: We will do our usual (In)Sanity Testing and then hand off the bits to release engineering for 8u20-b02. 4) Week of Feb 17 - 14: Bug fixes can go in subject to the extra approval noted above, but please hold off making any risky changes until after M2. 5) Sunday, Feb 23 at 11:00 pm Pacific time: We will do a soft freeze, during which time we will be locked except for critical issues discovered during testing, for b03 (milestone M2). 6) Monday, Feb 24: We will do our usual (In)Sanity Testing, with extra emphasis on testing anything that changed after b02, and then hand off the bits to release engineering for 8u20-b03. 7) I will send a subsequent announcement as to when the repo is open for normal business. Thank you. -- Kevin
Re: where to set properties
JDK8 is not supported with Dalvik. However, JavaFX requires JDK8 in two
different ways:
1) It requires JDK8 syntax (default methods, lambdas, optional use of
final ...)
2) It requires JDK8 class libraries (there are references to classes
that are new in JDK8)
So far, we have limited and worded around 1) and Johan has implemented
the missing classes for 2).
My understanding is that RetroLabmda will be used to fix the problems
associated with 1). Since this works on byte codes, JDK8 will need to
be used to create the byte codes and compile the syntax.
Johan?
Steve
On 2014-02-20 1:49 PM, Felix Bembrick wrote:
Isn't that because they need to use the Dalvik Java classes and JDK 8
is not supported with Dalvik?
On 21 February 2014 05:22, Stephen F Northover
steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com
wrote:
On 2014-02-19 12:46 PM, Johan Vos wrote:
Is there a policy on the location where properties are defined?
I see there are properties on a number of places:
build.properties (e.g. jfx.build.jdk.version=1.8.0)
build.gradle (e.g. ext.JAVA_HOME = JDK_HOME)
buildSrc/(e.g. linux).gradle (e.g. LINUX.compileSwing = true;)
command line properties (e.g. -Djfx.build.jdk.defenders=true)
The reason I'm asking:
for Android/Dalvik, we don't require jfxBuildJdkVersion to be
1.8.0. There
are a number of ways to fix this. The current test is
if (jdkVersion != jfxBuildJdkVersion) {
fail(java version mismatch: ${jdkVersion} must be
${jfxBuildJdkVersion})
}
We build the Android/Dalvik runtime with Java 7, hence this
check fails.
We can either change jfx.build.jdk.version in build.properties
(but not
conditionally), or we can skip the test if
System.getProperty(jfx.build.jdk.defenders) is true, or we
can check if
the OS is Dalvik, or... or...
Is there a reason why you cannot build with 8? You will need to
accept 8 syntax (like lambdas).
I don't want to pollute the build files with too many tests,
so I prefer to
stick to the policy, if there is one.
Thanks,
- Johan
Lambda Day - Lambda Month
Hello all, So we announced Lambda Day rather prematurely. I had not actually ran any of the lambdification tooling and once I did, I found that they all produce lamdified code with compile errors. Most of the lamdified code works, but the odd lamdification does not. Naively, we had assumed that we could flip a switch and walk away lambdified. Silly us. Now that we know code will need to be edited manually, we have decided to lambdify components one at a time over the next month or so to better allow us to control the process. The first component to be lamdified is Samples, Mandelbrot and Ensemble8. But wait, Mandelbrot was already lambdifed so no change there. Since lamdification is such a pervasive change, we'll be announcing on the list when components are going to change and coordinating with the component owners. The JIRA that is tracking the work is https://javafx-jira.kenai.com/browse/RT-35197 The good news is that the lambda flood gates are open in all components. The Android and iOS ports have agreed to use RetroLambda to keep their ports going. Remember though, use of the streams API and other JDK8 library functionality like this will kill these ports so these features cannot be used in shared code. In platform specific Java code, there is no issue. I was so happy and then the wind was taken out of my sails. Software has let me down. Steve
[8u20] Review request: RT-35197: Use Lambda in FX runtime and samples
Hi Martin, Please review the lambdification of the base component. You are welcome to apply the patch, but there are numerous changes and they are all automatic. If you have outstanding changes, please commit them and I will lambdify once more, Jira: https://javafx-jira.kenai.com/browse/RT-35197 Webrev: See patch is in the JIRA Steve
[8u20] Review request: RT-35197: Use Lambda in FX runtime and samples [toys]
Hi Lisa, Please review the lambdification of the toys component. You are welcome to apply the patch, but there are numerous changes and they are all automatic. If you have outstanding changes, please coordinate with me and I will re-lambdify to include the changes. Jira: https://javafx-jira.kenai.com/browse/RT-35197 Webrev: See patch is in the JIRA Steve
Re: [8u20] Review request: RT-35197: Use Lambda in FX runtime and samples [experiments]
Hi Lisa, Please review the lambdification of the experiments component. You are welcome to apply the patch, but there are numerous changes and they are all automatic. If you have outstanding changes, please coordinate with me and I will re-lambdify to include the changes. Jira: https://javafx-jira.kenai.com/browse/RT-35197 Webrev: See patch is in the JIRA Steve
Re: [8u20] Review request: RT-35197: Use Lambda in FX runtime and samples
Hi Anthony, Please review the lambdification of the swing component. You are welcome to apply the patch, but there are numerous changes and they are all automatic. If you have outstanding changes, please coordinate with me and I will re-lambdify to include the changes. Jira: https://javafx-jira.kenai.com/browse/RT-35197 Webrev: See patch is in the JIRA Steve
Re: [8u20] Review request: RT-35197: Use Lambda in FX runtime and samples
Of course I mean Leonid, who is the owner of web, not Anthony ... On 2014-03-04 1:18 PM, Stephen F Northover wrote: Hi Anthony, Please review the lambdification of the web component. You are welcome to apply the patch, but there are numerous changes and they are all automatic. If you have outstanding changes, please coordinate with me and I will re-lambdify to include the changes. Jira: https://javafx-jira.kenai.com/browse/RT-35197 Webrev: See patch is in the JIRA Steve
[8u20] Review request: RT-35197: Use Lambda in FX runtime and samples
Hi Kirill, Please review the lambdification of the base component. You are welcome to apply the patch, but there are numerous changes and they are all automatic. If you have outstanding changes, please commit them and I will lambdify once more, Jira: https://javafx-jira.kenai.com/browse/RT-35197 Webrev: See patch is in the JIRA Steve
Re: [8u20] Review request: RT-35197: Use Lambda in FX runtime and samples
.. of course I mean the media component, not base. I just change the template to say your component ... Steve On 2014-03-05 3:41 PM, Stephen F Northover wrote: Hi Kirill, Please review the lambdification of the base component. You are welcome to apply the patch, but there are numerous changes and they are all automatic. If you have outstanding changes, please commit them and I will lambdify once more, Jira: https://javafx-jira.kenai.com/browse/RT-35197 Webrev: See patch is in the JIRA Steve
Re: CSS Font size in points doesn't match Node.Font.Size
Hi all, To change the Java API now would break the universe. All you can do is add new API. This can be in the form of new methods on Font, however things like Font.getSize() must always return pixels. A new method can be added getPoints() and new constructors that take points added, or perhaps a boolean parameter that says the the double parameter is in points, not pixels. A global mode would be horrible and error prone (unless I am missing something). Steve On 2014-03-05 5:19 PM, Tom Schindl wrote: From my tests the font size generated by CSS is what one gets with the same point size and font using native apps and Qt - my complaint was the font size when using the Java API. Tom Von meinem iPhone gesendet Am 05.03.2014 um 23:03 schrieb Felipe Heidrich felipe.heidr...@oracle.com: The problem is that point size used by Node and point size used by CSS are not the same. One uses a 72 DPI and the other 96. Thus the final pixel sizes are different. I don’t see how to change one or the other without breaking a ton of people. Maybe adding a global font DPI so that Node can be made to match CSS ? Suggestions ? Felipe On Mar 5, 2014, at 12:39 PM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: Hi Tom, Jeff, Felipe... Having bugs stay in to maintain backwards compatibility sounds very weird to me IMHO. If we go down that road aren't we creating a library that will some day have too many glitches and as such less appeal to programmers looking for UI libraries? Thanks, Hi On Mar 4, 2014, at 4:42 PM, Jeff Martin j...@reportmill.com wrote: Thanks Tom! I assume the thread was this one: Font.font() says it is point size but it looks like it are pixels http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-January/012398.html I guess the final word is that CSS assumes 1pt==1/92in, Yes and Nodes convert that to the real world on render? On the printer yes, on the display it assumes 72 (pt=px). And that this is basically a bug, but it can't be fixed due to legacy considerations? Yes Felipe -- Pedro Duque Vieira
Re: [8u20] Review request: RT-35197: Use Lambda in FX runtime and samples
Sorry everyone. The patch is there now. Steve On 2014-03-06 6:04 AM, Anthony Petrov wrote: No, it's not. Sorry. I guess Steve hasn't attached it to the JIRA. -- best regards, Anthony On 3/6/2014 2:12 PM, Anthony Petrov wrote: I believe the base-lambda.patch in JIRA is what you're looking for. -- best regards, Anthony On 3/6/2014 1:49 PM, Kirill Kirichenko wrote: I couldn't find media part in Jira. On 06.03.2014 00:44, Stephen F Northover wrote: ... of course I mean the media component, not base. I just change the template to say your component ... Steve On 2014-03-05 3:41 PM, Stephen F Northover wrote: Hi Kirill, Please review the lambdification of the base component. You are welcome to apply the patch, but there are numerous changes and they are all automatic. If you have outstanding changes, please commit them and I will lambdify once more, Jira: https://javafx-jira.kenai.com/browse/RT-35197 Webrev: See patch is in the JIRA Steve
Re: CSS Font size in points doesn't match Node.Font.Size
It can and should. See my previous post. If there is no JIRA for this, then please create one. Thanks, Steve On 2014-03-05 6:18 PM, Tom Schindl wrote: The question the is why fairly all other toolkits use point in their APIs. Some examples: * Qt: http://qt-project.org/doc/qt-5/qfont.html#QFont-2 * Cocoa: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSFont_Class/Reference/Reference.html#//apple_ref/occ/clm/NSFont/fontWithName:size: * Pango: https://developer.gnome.org/pango/stable/pango-Fonts.html#pango-font-description-set-size * AWT: http://docs.oracle.com/javase/7/docs/api/java/awt/Font.html#Font%28java.lang.String,%20int,%20int%29 * SWT: http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fswt%2Fgraphics%2FFont.html Why can't JavaFX not at least provide a font-API to create fonts with point? Tom On 05.03.14 23:59, David Grieve wrote: Everyone should just accept that there is no such thing as a 'point' in JavaFX. Work in pixels and you will achieve nirvana. On 3/5/14, 5:49 PM, Pedro Duque Vieira wrote: Here is the definition of point: http://www.w3schools.com/cssref/css_units.asp As Jeff is saying it should be 1/72 inch. I think this should be the default. Isn't the introduction of modena potentially going to break more apps than changing the definition of point? Aren't breaking apps making use of a bug that they shouldn't be taking advantage of in the first place? That being said, and if changing the default point definition is not really possible, being able to change this through a global settings property so that node matches CSS, sound like a reasonable workaround. Thanks!
Re: Building and using a debug build of openjfx as the default JavaFX for development
Thanks John. See also: https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE There are several tricky issues around building, running and debugging OpenJFX from within an IDE. The most important thing is to run the code in the IDE rather than jfxrt.jar and the shared libraries that come with Java 8. All of this is described in the link. Steve On 2014-03-09 5:41 PM, John Smith wrote: The easiest thing to do to debug JavaFX is to use a prebuilt JDK 8+ and attach the sources from the JDK to your IDE. Then you can set break-points in the JavaFX source and debug it (i.e. you don't need to checkout and build openjfx at all). This works fine if all you want to do is step through the JavaFX source in the context of debugging your application (I think from your question this is actually what you want). For instructions on how to do this with Intellij Idea, see http://stackoverflow.com/questions/13407017/javafx-source-code-not-showing-in-intellij-idea. I think something like e(fx)clipse will do this step for you automatically (not sure about NetBeans). There is really little difference between the openjfx code and the source shipped with JDK 8. When you download JDK 8 (from https://jdk8.java.net/download.html) you are receiving a pre-built tagged snapshot of software built almost entirely from the openjdk/openjfx codebase. Of course, if you are actually developing and modifying the openjfx source, then the above won't work because your modified openjfx source would get out of sync with the binary JDK8 code. In this case, you would need to check-out the openjfx source, make any modifications you want, build it and then when you run your application, ensure that you run it against your custom openjfx build and have the modified source attached to your application's IDE project (similar to the instructions in the stackoverflow question I linked). JavaFX has both native and Java components. Debugging through the native components as well as the Java components is a more complex task. Perhaps there is more information on debugging openjfx on the openjfx wiki: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX But the wiki is currently offline, so I can't check it at the moment. John -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Kay McCormick Sent: Friday, March 07, 2014 10:15 PM To: openjfx-dev@openjdk.java.net Subject: Building and using a debug build of openjfx as the default JavaFX for development Hi everyone, I've successfully built openjfx. My overall goal is to be able to step through the openjfx code. I have the Oracle JDK installed - do I need to use OpenJDK instead? How would I go about making sure the build produced has debug information and using it for javafx application development. I'm trying to make my way through this process but I don't have all the pieces put together yet, and I'd appreciate any tips that can be offered. Thanks! Kay
Accessibility in OpenJFX: The Saga Continues
Hi all, We've been looking at Accessibility in FX for quite a while now and it has proved a very difficult component to implement. For one reason or another it has simply not made it into the toolkit. Accessibility is a critical component and one that is essential for a number of reasons. I'm pleased to announce that we've been working hard to tame the beast: https://wiki.openjdk.java.net/display/OpenJFX/Accessibility+Exploration The results of this exploration are looking really good. Just like previous accessibility implementations, the plan is to make the code available in OpenJFX, but have it be disabled by default until it is ready. Fortunately, the Accessibility API is small and the code does not run unless triggered by the screen reader. This allows us to include the implementation before it is ready without destabilizing the code base. The idea behind releasing Accessibility now is to allow people to try the code and contribute. It is important to understand that we are at the alpha stage in development. The API is not settled and neither is the implementation, but we have reached the point where we have proved the design with working code. Working code is worth its weight in gold, especially when dealing with the low level details of different operating systems. If not careful, it is quite easy to design an API that cannot be implemented on a particular platform and then be stuck with it. There is nothing official in terms of the release date, but as important dates get closer (8u20, 8u40 and 9), we will be evaluating where we are at. This might mean that the experimental Accessibility API may disappear temporarily only to reappear quickly in the early days of the next release. There will be no API before its time. Please follow along with us in JIRA, on this list and in the wikihttps://wiki.openjdk.java.net/display/OpenJFX/Accessibility You will need to set -Djavafx.accessible=true to enable accessibility (it is disabled by default). Currently only Windows 8 and Mac OSX 10.9 are supported. Of course, Windows 7 and Mac 10.8 need to eventually work too and the brave among you can force the code to run using -Djavafx.accessible.force=true. We are at the point where we're looking for community involvement in testing and implementation. We are not yet ready for third party controls. First, we need to get the built in FX controls working to be accessible and then use what we have learned. Thanks for being so patient with us, Steve
Re: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'
Was this gradle 1.8 or a problem with an EA version of JDK8? In any case, update both. If you can't, doing a clean every time should work but that's not the long term answer. Steve On 2014-03-21 5:49 AM, Kevin Rushforth wrote: Are you using gradle 1.8? This looks like a bug we used to have with prior versions of gradle. -- Kevin Leonid Popov wrote: Hi, I updated my workspace recently, tried to build it and have got the following exception. Any suggestions? FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':web:compileGeneratedWin'. java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'.
Re: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'
We fail on gradle 1.11. I have filed this bug: https://javafx-jira.kenai.com/browse/RT-36330 I suggest that if we can't fix the bug quickly, we print out a message that we require gradle 1.8 and exit. We should let people override this choice in the properties file. Steve On 2014-03-21 7:47 AM, Kevin Rushforth wrote: This was a gradle 1.4 bug that is fixed in 1.8: http://issues.gradle.org/browse/GRADLE-2831 Leonid just happened to be running an older gradle. -- Kevin Stephen F Northover wrote: Was this gradle 1.8 or a problem with an EA version of JDK8? In any case, update both. If you can't, doing a clean every time should work but that's not the long term answer. Steve On 2014-03-21 5:49 AM, Kevin Rushforth wrote: Are you using gradle 1.8? This looks like a bug we used to have with prior versions of gradle. -- Kevin Leonid Popov wrote: Hi, I updated my workspace recently, tried to build it and have got the following exception. Any suggestions? FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':web:compileGeneratedWin'. java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'.
Re: *PropertyBase vs Simple*Property
This looks good. I wonder if we should make this (massive) change
before we lambda graphics and controls? Probably doesn't matter. We'll
need a JIRA and someone assigned to it in order to track the work.
Steve
On 2014-03-21 12:53 PM, Tom Schindl wrote:
Hi Richard,
Coming back to this old thread and now that we are using lamdas all over
I guess we could take one more look into that.
I've prototyped an initial version by introducing a new internal type
named InvalidatedSimpleObjectProperty (not the best name ever!) - see
code pasted below.
And now one can write code like this:
public final ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new InvalidatedSimpleObjectProperty(this, viewport,
(o) - {
invalidateWidthHeight();
impl_markDirty(DirtyBits.NODE_VIEWPORT);
impl_geomChanged();
} );
}
return viewport;
}
instead of
public final ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new ObjectPropertyBaseRectangle2D() {
@Override
protected void invalidated() {
invalidateWidthHeight();
impl_markDirty(DirtyBits.NODE_VIEWPORT);
impl_geomChanged();
}
@Override
public Object getBean() {
return ImageView.this;
}
@Override
public String getName() {
return viewport;
}
};
}
return viewport;
}
Which allows us to get rid of most of the ObjectPropertyBase sublcasses.
Tom
package com.sun.javafx.property;
import java.util.function.Consumer;
import javafx.beans.property.SimpleObjectProperty;
public final class InvalidatedSimpleObjectPropertyT extends
SimpleObjectPropertyT {
private final ConsumerInvalidatedSimpleObjectPropertyT
invalidationConsumer;
/**
* The constructor of {@code ObjectProperty}
*
* @param initialValue
*the initial value of the wrapped value
* @param invalidationConsumer
* the consumer to be called when the bean is
invalidated
*/
public InvalidatedSimpleObjectProperty(T initialValue, final
ConsumerInvalidatedSimpleObjectPropertyT invalidationConsumer) {
super(initialValue);
if( invalidationConsumer == null ) {
throw new IllegalArgumentException(Consumer can not be null);
}
this.invalidationConsumer = invalidationConsumer;
}
/**
* The constructor of {@code ObjectProperty}
*
* @param bean
*the bean of this {@code ObjectProperty}
* @param name
*the name of this {@code ObjectProperty}
* @param invalidationConsumer
* the consumer to be called when the bean is
invalidated
*/
public InvalidatedSimpleObjectProperty(Object bean, String name, final
ConsumerInvalidatedSimpleObjectPropertyT invalidationConsumer) {
super(bean, name);
if( invalidationConsumer == null ) {
throw new IllegalArgumentException(Consumer can not be null);
}
this.invalidationConsumer = invalidationConsumer;
}
/**
* The constructor of {@code ObjectProperty}
*
* @param bean
*the bean of this {@code ObjectProperty}
* @param name
*the name of this {@code ObjectProperty}
* @param initialValue
*the initial value of the wrapped value
* @param invalidationConsumer
* the consumer to be called when the bean is
invalidated
*/
public InvalidatedSimpleObjectProperty(Object bean, String name, T initialValue, final
ConsumerInvalidatedSimpleObjectPropertyT invalidationConsumer) {
super(bean,name,initialValue);
if( invalidationConsumer == null ) {
throw new IllegalArgumentException(Consumer can not be null);
}
this.invalidationConsumer = invalidationConsumer;
}
@Override
protected void invalidated() {
invalidationConsumer.accept(this);
}
}
On 22.01.13 10:30, Richard Bair wrote:
Is the Java8 plan still there if not should the current Simple*Property
subclasses who overload invalidated be changed to PropertyBase?
It is unlikely that we'll be able to do anything major here in Java 8 just
because we don't really have Lambda yet that we can play with, and changing
over every property is a big job. Unless we knew it would be a major win. I
would say, if you encounter a Simple* property that has been subclassed, then
we should fix it up as we go to be a PropertyBase* guy instead.
Re: Gradle 1.11 (and 1.8) will now fail fast with a clear error [was: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin']
Great! There were people getting burned by this at EclipseCon. Luckily,
I remembered this bug and was able to help them but now we don't have to.
Steve
On 2014-03-21 4:15 PM, Kevin Rushforth wrote:
I just pushed a fix for https://javafx-jira.kenai.com/browse/RT-36330
Changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/27390e79b4cf
There is a bug in gradle 1.11 (already fixed in 1.12-rc1) which would
be intrusive to workaround, so 1.11 is now blacklisted.
The logic is this:
if (gradleVersion != 1.8) {
if (gradleVersion 1.8) fail
else if (gradleVersion == 1.11) fail
else warn
}
You can turn the failures into warnings with gradle
-PGRADLE_VERSION_CHECK=false
-- Kevin
Stephen F Northover wrote:
We fail on gradle 1.11. I have filed this bug:
https://javafx-jira.kenai.com/browse/RT-36330
I suggest that if we can't fix the bug quickly, we print out a
message that we require gradle 1.8 and exit. We should let people
override this choice in the properties file.
Steve
On 2014-03-21 7:47 AM, Kevin Rushforth wrote:
This was a gradle 1.4 bug that is fixed in 1.8:
http://issues.gradle.org/browse/GRADLE-2831
Leonid just happened to be running an older gradle.
-- Kevin
Stephen F Northover wrote:
Was this gradle 1.8 or a problem with an EA version of JDK8? In
any case, update both. If you can't, doing a clean every time
should work but that's not the long term answer.
Steve
On 2014-03-21 5:49 AM, Kevin Rushforth wrote:
Are you using gradle 1.8? This looks like a bug we used to have
with prior versions of gradle.
-- Kevin
Leonid Popov wrote:
Hi, I updated my workspace recently, tried to build it and have
got the following exception. Any suggestions?
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':web:compileGeneratedWin'.
java.lang.ClassFormatError: Invalid Constant Pool entry Type 18
* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed
for task ':web:compileGeneratedWin'.
Re: Ability to decorate ChangeListener
I'm pretty sure this discussion has solidified around not flipping the
equals() but this is a good example of something that we wouldn't
change. If you write code that relies on this, it will break in the
future when new code is added in FX that does not follow the pattern.
Steve
On 2014-03-22 10:47 AM, Mario Ivankovits wrote:
The only thing which I ask for is to flip this „if in the *ExpressionHelper
classes:
So, JavaFX does not break anything and it is up to the app developer to take
the risk or not.
if (listener.equals(changeListeners[index])) {
If we flip this to
if (changeListeners[index].equals(listener))
Am 22.03.2014 um 15:42 schrieb Kevin Rushforth
kevin.rushfo...@oracle.commailto:kevin.rushfo...@oracle.com:
If you are talking about a change to the JavaFX API, we are not likely to
accept such a change if it breaks the contract of equals() or hashcode(). In
your own app it may not matter, but it is dangerous to assume it won't matter
to anyone. Martin owns the core libraries and can comment further.
-- Kevin
Mario Ivankovits wrote:
Hi Thomas!
Thanks for your input. Because I want to decorated listeners added by JavaFX
core I can not use the sub/unsub pattern.
Your second proposal is almost what I do right now. In removeListener I consult
a map where the decorated listeners and their undecorated one lives.
Regarding the symmetric doubts. Such listeners will always be removed by
passing in the undecorated object to removeListener.
They should act like a transparent proxy.
Even if this breaks the equals paradigm, in this special case I can perfectly
live with an equals/hashCode implementation like this below.
It won’t break your app; as long as both objects do not live in the same
HashSet/Map …. for sure - but why should they?
@Override
public boolean equals(Object obj)
{
return obj == delegate; // this == obj
}
@Override
public int hashCode()
{
return delegate.hashCode();
}
Regards,
Mario
Am 22.03.2014 um 14:22 schrieb Tomas Mikula
tomas.mik...@gmail.commailto:tomas.mik...@gmail.com:
A simpler and more universal solution is to also override removeListener:
public void removeListener(ChangeListener? super T listener) {
super.removeListener(decorated(listener));
}
And the equals() method on decorated listeners only compares the
delegates (thus is symmetric).
Regards,
Tomas
On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula
tomas.mik...@gmail.commailto:tomas.mik...@gmail.com wrote:
The suspicious thing about your solution is that your smart
implementation of equals() is not symmetric.
In case the observable value is visible only within your project, you
could do this:
interface Subscription {
void unsubscribe();
}
class MyObservableValueT implements ObservableValueT {
public Subscription subscribe(ChangeListener? extends T listener) {
ChangeListenerT decorated = decorate(listener);
addListener(decorated);
return () - removeListener(decorated);
}
}
and use subscribe()/unsubscribe() instead of addListener()/removeListener():
Subscription sub = observableValue.subscribe(listener);
// ...
sub.unsubscribe();
Of course this is not possible if you need to pass the observable
value to the outside world as ObservableValue.
Regards,
Tomas
On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits
ma...@datenwort.atmailto:ma...@datenwort.at wrote:
Hi!
In one of my ObservableValue implementations I do have the need to decorate
ChangeListener added to it.
Today this is somewhat complicated to implement, as I have to keep a map of the
original listener to the decorated one to being able to handle the removal
process of a listener. Because the outside World did not know that I decorated
the listener and the instance passed in to removeListener ist the undecorated
one.
We can make things easier with a small change in
ExpressionHelper.removeListener. When iterating through the listener list, the
listener passed in as argument to removeListener is asked if it is equal to the
one stored
if (listener.equals(changeListeners[index])) {
If we flip this to
if (changeListeners[index].equals(listener)) {
a listener decoration can be smart enough to not only check against itself, but
also against its delegate.
What do you think?
I could prepare a patch for the *ExpressionHelper classes.
Best regards,
Mario
Re: Using JavaFX deploy and having signing issues...
Yes and we'll put them on the OpenJFX wiki. Steve On 2014-03-24 6:39 PM, Mark Fortner wrote: Tony and/or Danno, Would you mind documenting the steps that you had to go through to make a Mac application that was submittable to the Apple Store? I'm sure everyone who's struggling to create applications would appreciate the information. Cheers, Mark On Mon, Mar 24, 2014 at 3:30 PM, Tony Anecito adanec...@yahoo.com wrote: Ok I was able to codesign and submit. The JavaFX deploy task is not creating a info.plist when the jdk is added to the bundle for the jdk. After submission there were some issues related to signing and it now requires a entitlements file for some things in the jre. Regards, -Tony On Monday, March 24, 2014 12:01 PM, Tony Anecito adanec...@yahoo.com wrote: So you have tried codesign with Mavericks OS X? I am getting invalid bundle when the jdk is bundled as required by the Apple Store. You have to codesign the jdk plugin seprately. Yes you can create a pkg or dmg image but I am looking for the correct way get the jdk codesigned else the app codesign fails also. Do you have a working example of codesign the jdk in the bundle? Thanks, -Tony On Monday, March 24, 2014 11:48 AM, Danno Ferrin danno.fer...@oracle.com wrote: You can still deploy apps to the app store using JavaFX. You just cannot use the media library at the moment. You can do it also via non app store distribution and sign it via gatekeeper as well and keep the media libraries in. And it shouldn't matter what version of Mac OSX you use to build it. Tony Anecito adanec...@yahoo.com wrote: Thanks Richard, I know some more now. It seems with Mavericks 10.9 codesign and the bundle format that JavaFX deploy creates is no longer valid. There are starting to appear to be more references to this issue on the internet. So JavaFX apps can no longer be created and work on the Mac at least as far as the Apple Store is concerned. I may have to downgrade my Mac OS X to 10.8 to create Apple Store distributable JavaFX apps for the Mac. -Tony On Monday, March 24, 2014 10:57 AM, Richard Bair richard.b...@oracle.com wrote: One last hurdle, you need to remove the media library for JavaFX (lib/libjfxmedia.dylib) from your bundled JDK. It uses QuickTime and that is being disowned by apple. This may be fixed in a later 8u update, but not in 8.0.0_b132. Oh good grief, Apple! So what should we be using instead? This means I cannot make use of fx media in any app submitted to the app store? Richard
Re: Adding GStreamer plugins
On 2014-03-25 7:00 AM, Kirill Kirichenko wrote: Hi Michael. See my comments inline. On 24.03.2014 04:31, Michael Berry wrote: I'm now a bit further along with this, though struggling to get the matroska plugin to compile (getting a bunch of unresolved external symbol errors for functions it uses in glib - not entirely sure why at the moment, as I said C is not my strong point.) I've also noticed the plugins currently bundled have quite a few changes to the gstreamer version, and I can't quite work out the logic behind why things have been changed the way they have - so even after the compilation issue is resolved I'm now less confident that it will just drop in and work! Again, if someone knowledgeable in this area that's lurking in the shadows could shed any light on any of this, it would be hugely appreciated. We did some changes in existing GStreamer code because it had errors and because we needed to expand some functionality. The changes are not very extensive. However, putting the current problems aside for a bit, the snags I hit up until this point could I think be relatively easily addressed in the documentation. With that in mind could I suggest a few additional points for the wiki? These may be obvious to the majority reading here, but as someone completely new to building JFX they had me stumped for a while! I can give you some directions. There is no wiki. I'd appreciate if you created one. - It turns out that the Gstreamer stuff doesn't compile at all by default, which is why I wasn't seeing any changes on the native level. To ensure GStreamer is actually compiled, you need to copy the gradle.properties.template file to gradle.properties, and uncomment the #COMPILE_MEDIA = true line. (A similar scenario would appear to exist for any webkit alterations as per the line above.) You don't need to comment/uncomment anything. Just add -PCOMPILE_MEDIA=true to the gradle command line. You can however change the properties file too. - As well as the requirements listed, I needed the Windows SDK ( http://www.microsoft.com/en-gb/download/details.aspx?id=8279) installed for GStreamer to compile successfully under Windows (7) - without it cygpath just threw a rather confusing error. You need windows 7.1a SDK and speaking precisely you need only samples from it because samples have BaseClasses at Samples/multimedia/directshow/baseclasses. BaseClasses are used for Oracle direchshowwrapper plugin. - The developer workflow page ( https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow) refers to -Djavafx.ext.dirs - I think this should be -Djava.ext.dirs instead? What are you gonna use it for ? I updated the page and got rid of the BINARY_STUB reference that is no longer needed. I'm happy to make the above changes myself but unsure of if / where you can sign up for an account, so I'm just throwing them here for now - if anyone could point me to the right place then that'd be great! Steve. Can you give an advice ? If you are looking to contribute (when you get to a good place), the process is well known and is followed by the everyone. https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews If I do ever manage to get this working (ha-ha) I'd also like to throw up a wiki page just detailing how to grab a gstreamer plugin and make the necessary changes to it to compile it into openjfx as a stop gap to then perhaps working on one or both of the above JIRA issues and seeing where I get - does this sound reasonable? Only committers can edit the wiki right now. It is possible to become an Author and write to the wiki, but I would be happy to publish your recipe when you are happy with it. It does. On Mar 22, 2014, at 9:26 PM, Michael Berry berry...@gmail.com wrote: However, I'm not sure if I'm going about including the matroska plugin in the right way - I've currently done the following: - Downloaded the latest version of the plugins from here ( http://gstreamer.freedesktop.org/src/gst-plugins-good/), then added the matroska one to the modules/media/src/main/native/gstreamer/plugins/ folder, as well as the modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/ folder (I'm unsure of this - should I add it to both these folders?). Well you see. If you download the latest matroska plugin it potentially can have dependencies on the latest GStreamer platform. We don't have/use the latest gstreamer. The version we use is 0.10.35. And the latest available is 1.x. They are incompatible in some methods. - Added all the C files from the first folder mentioned above to the plugins.vcxproj file - Added the relevant files and directory to Makefile.gstplugins - Called the additional relevant plugin_init() function in gstplugins-lite.c There is one more thing you need to do here for Windows only apart from running gradle with -PCOMPILE_MEDIA=true. Windows build system has files that export symbols 1)
Re: Is Quicktime API calls inside JavaFX?
Apple has a long history of burning developers like this. It's the price of running on their platform. Steve On 2014-03-25 3:30 PM, Phil Race wrote: I see .. so AVFoundation was already there since 10.7, its AVKit that's new in 10.9 but AV Foundation is what FX would use. It looks like Apple starting encouraging migration to AV Foundation about 18 months ago based on the date of this document :- https://developer.apple.com/library/mac/technotes/tn2300/_index.html I suppose we need to learn read the apple seeds and interpret that as a big, urgent, hint. -phil. On 3/25/2014 12:09 PM, David DeHaven wrote: Therein lies The Problem, and why we had to go with QTKit when we supported 10.6... Every two releases they seem to deprecate half-baked APIs in favor of some new half-baked API. At least as of 10.8 that seems to have stabilized somewhat, as we transition more and more to an iOS clone. We had issues with AVFoundation not working the way we needed and it wasn't available on 10.6. It's supposed to work correctly (never had time to confirm) on 10.8 but that still leaves 10.7 out in the cold. So we'll likely have to stick with QTKit for older releases and move to AVFoundation in 10.8 and later. Ideally, the QTKit component would be separate so it could be removed allowing MAS apps to still support A/V playback. I think the QTKit component can be dropped completely in FX 9 but it needs to be there in FX 8. AVKit is a high level component that sits on top of AVFoundation, it doesn't look useful for our purposes at first glance. -DrD- I presume that Apple now want you to use AVKit which is new in 10.9. However I don't understand how you can develop an app that targets 10.8 if its unable to use QTKit since that's all there is on 10.8 or earlier. Does the AppStore really disallow targeting something like half the installed base ?? -phil. On 3/25/2014 9:19 AM, Stephen F Northover wrote: Here is the JIRA that is tracking this: https://javafx-jira.kenai.com/browse/RT-34893 Steve On 2014-03-25 11:46 AM, Tony Anecito wrote: Thanks for the verification. No matter what state Quicktime is in it is no longer accepted by the Apple Store. I am guessing these new rules will soon apply to everything but I could be wrong. Regards, -Tony On Tuesday, March 25, 2014 9:27 AM, David DeHaven david.deha...@oracle.com wrote: Hi All, Apparently the JavaFX includes some libraries that use the obsolete Quicktime. When some submits to the Apple Store a JavaFX app it gets rejected based on JavaFX having the obsolete API. I found out how to fix it from someone else running into the same issue. http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage It uses the now deprecated QTKit to play media. -DrD-
Re: Is Quicktime API calls inside JavaFX?
As I said, Apple does this. It took cocoa (a nice API) years until it had the functionality of carbon (an awful API). Believe me, I have experienced the trail of dead API and the pointless developer rewrites. Steve On 2014-03-25 4:02 PM, David DeHaven wrote: Yes, this is true, but QuickTime (despite it's horrible component architecture) was stable and actually useful for a very long time, then they dropped it and replaced it with what amounts to absolutely nothing useful. Only in 10.8 did they start putting useful bits back in, it's still a long ways to go to catch up to the utility of QuickTime. -DrD- Apple has a long history of burning developers like this. It's the price of running on their platform. Steve On 2014-03-25 3:30 PM, Phil Race wrote: I see .. so AVFoundation was already there since 10.7, its AVKit that's new in 10.9 but AV Foundation is what FX would use. It looks like Apple starting encouraging migration to AV Foundation about 18 months ago based on the date of this document :- https://developer.apple.com/library/mac/technotes/tn2300/_index.html I suppose we need to learn read the apple seeds and interpret that as a big, urgent, hint. -phil. On 3/25/2014 12:09 PM, David DeHaven wrote: Therein lies The Problem, and why we had to go with QTKit when we supported 10.6... Every two releases they seem to deprecate half-baked APIs in favor of some new half-baked API. At least as of 10.8 that seems to have stabilized somewhat, as we transition more and more to an iOS clone. We had issues with AVFoundation not working the way we needed and it wasn't available on 10.6. It's supposed to work correctly (never had time to confirm) on 10.8 but that still leaves 10.7 out in the cold. So we'll likely have to stick with QTKit for older releases and move to AVFoundation in 10.8 and later. Ideally, the QTKit component would be separate so it could be removed allowing MAS apps to still support A/V playback. I think the QTKit component can be dropped completely in FX 9 but it needs to be there in FX 8. AVKit is a high level component that sits on top of AVFoundation, it doesn't look useful for our purposes at first glance. -DrD- I presume that Apple now want you to use AVKit which is new in 10.9. However I don't understand how you can develop an app that targets 10.8 if its unable to use QTKit since that's all there is on 10.8 or earlier. Does the AppStore really disallow targeting something like half the installed base ?? -phil. On 3/25/2014 9:19 AM, Stephen F Northover wrote: Here is the JIRA that is tracking this: https://javafx-jira.kenai.com/browse/RT-34893 Steve On 2014-03-25 11:46 AM, Tony Anecito wrote: Thanks for the verification. No matter what state Quicktime is in it is no longer accepted by the Apple Store. I am guessing these new rules will soon apply to everything but I could be wrong. Regards, -Tony On Tuesday, March 25, 2014 9:27 AM, David DeHaven david.deha...@oracle.com wrote: Hi All, Apparently the JavaFX includes some libraries that use the obsolete Quicktime. When some submits to the Apple Store a JavaFX app it gets rejected based on JavaFX having the obsolete API. I found out how to fix it from someone else running into the same issue. http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage It uses the now deprecated QTKit to play media. -DrD-
Re: Adding GStreamer plugins
https://javafx-jira.kenai.com/browse/RT-18009 This JIRA is covering adding support for more media formats. Since we are just talking about MKV, please open a separate JIRA to cover this work and attach the patch there. We can link to the new JIRA from RT-18009. Steve On 2014-03-25 7:47 PM, Jonathan Giles wrote: Typically in this case you would email the patch to the assigned developer, but it appears RT-18009 is unassigned at present. I think that is the first hurdle that needs to be resolved, but if you email me your patch I will attach it to the jira issue so that it is at least available for others. Thanks! -- Jonathan On 26/03/2014 12:39 p.m., Michael Berry wrote: Hi all, Turns out it was a stupid mistake on my part causing the last few linking errors, I hadn't added one of the C files I needed to the makefile (well I had, but I'd then reverted it again without realising!) Thanks to all for the prods and advice. Once I'd done that, the build went through without a hitch - and then it was just a case of making the relevant additions to the native code to register the MKV type and create a pipeline from it using the plugin. This wasn't hard to work out at all; I've since tried several test files in MKV format (with AAC audio) all of which play in MediaPlayer without a hitch! I mainly wanted to do this as a personal exercise, though I'd imagine this is a useful piece of functionality for many others also - so should I submit a patch of the changes, or is this unlikely to be accepted? (Again, sorry for the perhaps obvious question, I'm rather new to this.) I've had a look at the code review process and it seems to suggest adding a patch to the relevant JIRA issue for those who don't have commit access (in this case 18009), but I don't seem to have permission to do that either? Thanks, Michael On 25 March 2014 17:01, Stephen F Northover steve.x.northo...@oracle.comwrote: On 2014-03-25 7:00 AM, Kirill Kirichenko wrote: Hi Michael. See my comments inline. On 24.03.2014 04:31, Michael Berry wrote: I'm now a bit further along with this, though struggling to get the matroska plugin to compile (getting a bunch of unresolved external symbol errors for functions it uses in glib - not entirely sure why at the moment, as I said C is not my strong point.) I've also noticed the plugins currently bundled have quite a few changes to the gstreamer version, and I can't quite work out the logic behind why things have been changed the way they have - so even after the compilation issue is resolved I'm now less confident that it will just drop in and work! Again, if someone knowledgeable in this area that's lurking in the shadows could shed any light on any of this, it would be hugely appreciated. We did some changes in existing GStreamer code because it had errors and because we needed to expand some functionality. The changes are not very extensive. However, putting the current problems aside for a bit, the snags I hit up until this point could I think be relatively easily addressed in the documentation. With that in mind could I suggest a few additional points for the wiki? These may be obvious to the majority reading here, but as someone completely new to building JFX they had me stumped for a while! I can give you some directions. There is no wiki. I'd appreciate if you created one. - It turns out that the Gstreamer stuff doesn't compile at all by default, which is why I wasn't seeing any changes on the native level. To ensure GStreamer is actually compiled, you need to copy the gradle.properties.template file to gradle.properties, and uncomment the #COMPILE_MEDIA = true line. (A similar scenario would appear to exist for any webkit alterations as per the line above.) You don't need to comment/uncomment anything. Just add -PCOMPILE_MEDIA=true to the gradle command line. You can however change the properties file too. - As well as the requirements listed, I needed the Windows SDK ( http://www.microsoft.com/en-gb/download/details.aspx?id=8279) installed for GStreamer to compile successfully under Windows (7) - without it cygpath just threw a rather confusing error. You need windows 7.1a SDK and speaking precisely you need only samples from it because samples have BaseClasses at Samples/multimedia/directshow/baseclasses. BaseClasses are used for Oracle direchshowwrapper plugin. - The developer workflow page ( https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow) refers to -Djavafx.ext.dirs - I think this should be -Djava.ext.dirs instead? What are you gonna use it for ? I updated the page and got rid of the BINARY_STUB reference that is no longer needed. I'm happy to make the above changes myself but unsure of if / where you can sign up for an account, so I'm just throwing them here for now - if anyone could point me to the right place then that'd be great! Steve. Can you give an advice
Re: Glass Robot and getSCreenCapture
Hi David,
Sorry to be getting to this so late. An uninitialized pixel is normally
considered to be black. If you throw an exception, clients will need to
either catch the exception or perform the same test that you are
performing before they call the API. Since this is not pubic API, no
client will be affected so even if we make the change to throw the
exception and then decide not to do this later, we can change it.
What is happening now? Who is being affected by this bug? Is it easy
to change the implementations to return black? This seems better to me
than throwing the exception.
As I say, if we throw the exception, then we will only break ourselves,
not clients of FX API. Have we ensured that the exception will not
break SQE tests.
Again, sorry to be getting to this so late and apologies if all of this
has been discussed in another thread that I missed,
Steve
On 2014-03-25 2:46 PM, David Hill wrote:
On 3/21/14, Mar 21, 12:53 PM, David Hill wrote:
Having heard a little feedback, here is my proposal in the form of a
review request :-)
My recommendation would be modify the JavaDoc contract to specify
that the x,y and x+width, y+height must be within the screen bounds,
with an IllegalArgumentException if out of bounds. This would be
checked in Robot, prior to calling the native impls.
This code is internal API, so I expect the real impact would be on
SQE.
I really like the idea of adding a bounds restriction - so that the
requested bounds must be within the Screen.
It seems the simplest solution to my issue of handling the odd edge
case of out of bound pixels, with the least likely impact.
This means that existing code in the implementations are not affected.
I suspect that there will we little if any impact on SQE tests, given
that most of us would avoid asking for a screen capture with undefined
pixels. I do expect that we will encounter a few exceptions to this
when tests are run on smaller displays (like embedded).
I also added bounds checking to Robot.getPixelColor() for consistency,
and because Embedded passes this call through to common code for
screen capture.
I did a grep through the JavaFX code base, and don't see any JavaFX
use cases. I expect any golden image test code could be affected.
I separated out this internal API changes from my embedded changes so
we have a clear and easy thing to review.
Jira: https://javafx-jira.kenai.com/browse/RT-36382
Patch: is inline in the Jira, but also here:
diff -r bb72bd2fa889
modules/graphics/src/main/java/com/sun/glass/ui/Robot.java
--- a/modules/graphics/src/main/java/com/sun/glass/ui/Robot.java Tue
Mar 25 14:21:26 2014 -0400
+++ b/modules/graphics/src/main/java/com/sun/glass/ui/Robot.java Tue
Mar 25 14:41:37 2014 -0400
@@ -144,9 +144,20 @@
protected abstract int _getPixelColor(int x, int y);
/**
* Returns pixel color at specified screen coordinates in IntARGB
format.
+ *
+ * If the requested pixel is not contained by the actual Screen
+ * bounds an IllegalArgumentException will be thrown.
+ *
+ * @param x The screen X of the requested capture (must be =0)
+ * @param y The screen Y of the requested capture (must be =0)
*/
public int getPixelColor(int x, int y) {
Application.checkEventThread();
+Screen s = Screen.getMainScreen();
+if (x 0 || y 0 ||
+x = s.getWidth() || y s.getHeight()) {
+ throw new IllegalArgumentException(Capture out of bounds);
+}
return _getPixelColor(x, y);
}
@@ -162,13 +173,27 @@
* will result in a Pixels object with dimensions (20x20).
Calling code
* should use the returned objects's getWidth() and getHeight()
methods
* to determine the image size.
- *
+ *
* If (@code isHiDPI) is {@code false}, the returned Pixels
object is of
* the requested size. Note that in this case the image may be
scaled in
* order to fit to the requested dimensions if running on a HiDPI
display.
+ *
+ * If the requested capture bounds is not contained by the actual
Screen
+ * bounds an IllegalArgumentException will be thrown.
+ *
+ * @param x The screen X of the requested capture (must be =0)
+ * @param y The screen Y of the requested capture (must be =0)
+ * @param width The of width the requested capture (must be =1
and fit on the screen)
+ * @param height The of width the requested capture (must be =1
and fit on the screen)
+ * @param isHiDPI return HiDPI if available
*/
public Pixels getScreenCapture(int x, int y, int width, int
height, boolean isHiDPI) {
Application.checkEventThread();
+Screen s = Screen.getMainScreen();
+if (x 0 || y 0 ||
+x + width s.getWidth() || y + height s.getHeight()) {
+ throw new IllegalArgumentException(Capture out of bounds);
+}
return _getScreenCapture(x, y, width,
Re: macosx fullscreen and window manager
It doesn't hurt to enter a JIRA for this. Even if we don't get to it ourselves, any sort of solution that you might come up with (even Mac only) can be tracked there. Steve On 2014-03-31 11:03 AM, Jasper Potts wrote: Hot corners and screen saver could just be turned off in system preferences. Then the cursor set to empty. If you need dynamic then you might be able to use something like JNA or JNIWrapper to make native call need to disable those things. Jasper On Mar 29, 2014, at 2:08 AM, Erik Colson e...@ecocode.net wrote: Hi, Is it possible to use JavaFX for developping a fullscreen macosx application that skips the window manager ? I have currently an app that does fullscreen but : - the 'hot corners' still work, letting the user switch to another app - the screensaver is still working - the mouse pointer is still shown The app is ment to become something like a Slideshow. Therefor those 3 points need to be solved. This is what I have for now: Screen screen = Screen.getPrimary(); primaryStage.initStyle(StageStyle.UNDECORATED); primaryStage.setResizable(false); primaryStage.setIconified(false); primaryStage.setFullScreenExitHint(); primaryStage.setFullScreen(true); primaryStage.setScene(scene); primaryStage.toFront(); // not really needed I think primaryStage.centerOnScreen(); primaryStage.show(); thanks ! -- erik colson
Re: Why is com.sun.glass.ui.swt part of graphics-module
Hi Tom, This is an experimental SWT implementation of Glass that is used for debugging, benchmarking etc. purposes. It's unlikely that we will ever ship it as part of FX. You are right that it can't be part of jfxrt.jar and should it ever become more than that, it would need to be in a separate jar, perhaps part of swtfx.jar. Steve On 2014-04-02 3:43 AM, Tom Schindl wrote: Hi Steve others, Why is com.sun.glass.ui.swt part of the graphics module? Should it go into the swt one? I think it should be shipped with swtfx.jar not else we get back to classloader hell because the extension classloader tries to load classes from swt which it naturally can not find. Tom
[8u20] Review request: RT-35197: Use Lambda in FX runtime and samples
Hi Kevin, Please review the lambdification of the graphics component. You are welcome to apply the patch, but there are numerous changes and they are all automatic. If you or any of the team have outstanding changes, please coordinate with me in the JIRA and I will re-lambdify after you have released your changes. Jira: https://javafx-jira.kenai.com/browse/RT-35197 Webrev: See patch is in the JIRA Steve
Re: Expected frame rates for a full-screen blur
Hi Mike,
I'm sorry that I've been unable to get to this until now. I can
recreate the problem you are seeing on my Mac by running
ColorfulCirclesApp. Please enter a JIRA for the problem. Thanks. Also
try this:
Try this:
PerformanceTracker tracker = PerformanceTracker.getSceneTracker(scene);
Timeline timeline = new Timeline(
new KeyFrame(Duration.seconds(1), t - {
System.out.println(::FPS = + tracker.getAverageFPS());
}));
timeline.setCycleCount(Timeline.INDEFINITE);
timeline.play();
Steve
On 2014-04-04 4:33 PM, Mike Hearn wrote:
OK, now I'm really puzzled - I watched the JavaFX performance talk from
2011 and learned about PeformanceTracker. It's too bad that's not public
API, but it works. I used it like so:
PerformanceTracker tracker = PerformanceTracker.getSceneTracker(scene);
tracker.setOnRenderedFrameTask(new Runnable() {
long lastTimestamp = System.currentTimeMillis();
@Override
public void run() {
final long now = System.currentTimeMillis();
long delta = now - lastTimestamp;
if (delta 1000)
System.out.println(Frame took + delta + msec);
lastTimestamp = now;
}
});
The 1000 thing is just to avoid printing a nonsense timestamp when the UI
hasn't been touched for a while.
The deltas I see are consistently between 10-20msec which would be between
50 and 60fps, i.e. the vsync of the screen. But the wacky thing is, this
doesn't change when I increase the size of the window, even though the
animation is noticeably more choppy. It still says there's a 10-20msec gap
between frames even though my eyes tell me otherwise. Even when I shrink
the window size right down and get super smooth animation, the above code
prints the same kind of deltas.
This makes me think that whatever is going on, the regular JavaFX drawing
thread isn't the issue. It seems to be churning through the scene at the
same totally acceptable rate no matter what. So I'm thinking the issue must
be something to do with how fast the GPU drains the command queue or
something.
BTW I tried doing -Dprism.order=j2d to see what would happen, and the GUI
hangs before rendering anything. I'll file a bug on that later.
On Thu, Apr 3, 2014 at 11:54 AM, Mike Hearn m...@plan99.net wrote:
How does the OS tank?
All the OS animations hit the same frame rate as the app itself does. For
instance, opening Mission Control is normally smooth, but when a maximized
JFX app is animating, it's not.
It feels like the GPU is being overworked but as I'm not a GPU expert at
all, I'm not sure where to begin - I am not even sure how to find out the
frame rate so I know when tweaks are improving things! Is there a way to
get this data from the system?
Re: Building OpenJFX on Mac OS X 10.9.2 / XCode 5.1 / XCode 4.3.3
Put this in your gradle.properties file: MACOSX_SDK_PATH = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk We need to document this on the wiki. Will do that Monday. Gotta go now. Steve On 2014-04-04 5:31 PM, Philipp Dörfler wrote: Hi, just out of curiousity I wanted to build OpenJFX, but although I followed the instructions at https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX I can’t get it to work. gradle 1.8 fails when building :fxpackage:compileLauncher as follows: :fxpackager:compileLauncher clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk' /Users/phi/Documents/workspace/OpenJFX8-rt/modules/fxpackager/src/main/native/launcher/mac/main.m:26:9: fatal error: 'Cocoa/Cocoa.h' file not found #import Cocoa/Cocoa.h ^ 1 error generated. :fxpackager:compileLauncher FAILED I do not have a 10.7 SDK on my 10.9 Mac, but I do have a 10.8 and 10.9: $ ls /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ MacOSX10.8.sdk MacOSX10.9.sdk According to „the internet™“ I would have to find an old version of Xcode (apparently 4.3.3) because that’s the only way to find an old SDK. As I’m sure that you guys have valid reasons to stick to 10.7 I think it would not hurt to mention this on the wiki page mentioned above stating that one needs XCode not newer than 4.3.3 and that old XCode versions can be downloaded on the Apple Developer website. I would add it myself but as I’m not a contributor I don’t have the required permissions, so all I can do is to ask here for inclusion of that. Thanks! May that be the only obstacle in building JFX8.
