hg: openjfx/8u-dev/rt: RT-37395: TreeTableView's selectedItems reports changes that include null items when when a TreeItem is collapsed.
Changeset: 784974feb001 Author:jgiles Date: 2014-06-06 12:40 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/784974feb001 RT-37395: TreeTableView's selectedItems reports changes that include null items when when a TreeItem is collapsed. ! modules/controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewTest.java
hg: openjfx/8u-dev/rt: Fix RT-36016: Dirty region (actually clipping) problems on blurs with large radii
Changeset: e2d745ffbf0a Author:flar Date: 2014-06-05 16:22 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e2d745ffbf0a Fix RT-36016: Dirty region (actually clipping) problems on blurs with large radii Reviewed by: kcr ! modules/graphics/src/main/java/com/sun/scenario/effect/impl/state/BoxRenderState.java
hg: openjfx/8u-dev/rt: Fixed RT-37209) [Printing] NPE when showing print dialog
Changeset: d9e26c986af1 Author:prr Date: 2014-06-05 15:57 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d9e26c986af1 Fixed RT-37209) [Printing] NPE when showing print dialog Reviewed-by: kcr ! modules/graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinter.java ! modules/graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinterJob.java
[8u] Review Request: RT-37408: [ScrollPane] incorrect preferred size when viewport pref size is specified and bar is present
Martin, Please review the patch attached to https://javafx-jira.kenai.com/browse/RT-37408.
Re: FXMLLoader checking code conventions too much?
Guillaume, if you feel strongly about this, please file a JIRA. Thanks!
Steve
On 2014-06-05, 4:29 PM, Martin Sladecek wrote:
Maybe some special tags can solve the problem, like
abc
abc
They could be used in cases where the class name violates the
restrictions we have for property/object tags. FXML version and SB
will have to be update though, which means such fxml will not be
compatible with older versions. This is definitely something we should
do only on major release (9).
-Martin
On 5.6.2014 22:21, Stephen F Northover wrote:
Seems like we can't/shouldn't fix this. We can at least make sure it
is documented.
Steve
On 2014-06-05, 4:19 PM, Martin Sladecek wrote:
Currently, we use case to distinguish between newly created objects
(upper-case class name) and properties (lower-case). Otherwise, it
would not be clear when there's e.g. a text property and text class
if we should set a property called text or create new text object
and try to assign it to the default property. The same problem with
static setters.
Is "hello.text.text" a fully qualified name of text class in or
"text" static setter of a hello.text class?
I guess we could define some order in which we would try out this
options in the current context, but SB will have a problem since
they use static mode which can be used without having the classes on
the cp.
-Martin
On 5.6.2014 20:57, Stephen F Northover wrote:
I see no reason why we should enforce this. Martin, any idea?
Steve
On 2014-06-05, 12:05 PM, Guillaume Anctil wrote:
Hi,
on a project I work on, the code convention does not follow the Java
standard and class names start with a lower case 'c':
"cSomeClass.java"
In the parsing of the FXMLLoader, the loadType
function looks
like this:
int i = name.indexOf('.');
int n = name.length();
while (i != -1
&& i < n
&& Character.isLowerCase(name.charAt(i + 1))) {
i = name.indexOf('.', i + 1);
}
if (i == -1 || i == n) {
throw new ClassNotFoundException();
}
String packageName = name.substring(0, i);
String className = name.substring(i + 1);
This causes a ClassNotFoundException on our custom controls
because of the
lowercase check.
I was wondering if a simple:
int i = name.lastIndexOf('.');
Instead of the lowercase check could be viable. The
ClassNotFoundException
would still be thrown later on, when trying to actually load the
class.
Is there a reason that I don't see why the convention _must_ be
upheld in
this case?
Thanks.
Re: FXMLLoader checking code conventions too much?
In that code "i < n" is a tautology. It's purpose seems to be to
prevent the following "i+1"s from overflowing the string length, but
then it should be "i < n-1" or "n" should just be initialized to
name.length()-1 (and be called "max" or something to make its purpose
clear)...
...jim
On 6/5/14 9:05 AM, Guillaume Anctil wrote:
Hi,
on a project I work on, the code convention does not follow the Java
standard and class names start with a lower case 'c': "cSomeClass.java"
In the parsing of the FXMLLoader, the loadType function looks
like this:
int i = name.indexOf('.');
int n = name.length();
while (i != -1
&& i < n
&& Character.isLowerCase(name.charAt(i + 1))) {
i = name.indexOf('.', i + 1);
}
if (i == -1 || i == n) {
throw new ClassNotFoundException();
}
String packageName = name.substring(0, i);
String className = name.substring(i + 1);
This causes a ClassNotFoundException on our custom controls because of the
lowercase check.
I was wondering if a simple:
int i = name.lastIndexOf('.');
Instead of the lowercase check could be viable. The ClassNotFoundException
would still be thrown later on, when trying to actually load the class.
Is there a reason that I don't see why the convention _must_ be upheld in
this case?
Thanks.
hg: openjfx/8u-dev/rt: 2 new changesets
Changeset: c5cfd184a714 Author:Anthony Petrov Date: 2014-06-06 00:39 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c5cfd184a714 RT-37406: [SwingNode]:swing component in swingnode lost foucs when keycode up(Arrow Up) Summary: consume() KeyEvents for UP and DOWN arrows, in addtion to already consumed LEFT and RIGHT ones ! modules/swing/src/main/java/javafx/embed/swing/SwingNode.java Changeset: d04c6e8ba00a Author:shemnon Date: 2014-06-05 14:44 -0600 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d04c6e8ba00a RT-37217: [Bundlers] mac packaging fails when RUNTIME option is passed Summary: Add runtime sanity check, requiring the jvm shared libraries or rt.jar to show up in the runtime bundle arg. ! modules/fxpackager/src/main/java/com/oracle/tools/packager/AbstractBundler.java ! modules/fxpackager/src/main/java/com/oracle/tools/packager/linux/LinuxAppBundler.java ! modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacAppBundler.java ! modules/fxpackager/src/main/java/com/oracle/tools/packager/windows/WinAppBundler.java ! modules/fxpackager/src/test/java/com/oracle/tools/packager/linux/LinuxAppBundlerTest.java ! modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppBundlerTest.java ! modules/fxpackager/src/test/java/com/oracle/tools/packager/windows/WinAppBundlerTest.java
hg: openjfx/8u-dev/rt: RT-37341: Ensemble8: TextField can not change its color
Changeset: 36f4864a04e8 Author:David Grieve Date: 2014-06-05 16:30 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/36f4864a04e8 RT-37341: Ensemble8: TextField can not change its color ! modules/graphics/src/main/java/javafx/scene/Node.java
RFR: Fix RT-37209: NPE showing print dialog
https://javafx-jira.kenai.com/browse/RT-37209 http://cr.openjdk.java.net/~prr/rt-37209/
Re: FXMLLoader checking code conventions too much?
Maybe some special tags can solve the problem, like
abc
abc
They could be used in cases where the class name violates the
restrictions we have for property/object tags. FXML version and SB will
have to be update though, which means such fxml will not be compatible
with older versions. This is definitely something we should do only on
major release (9).
-Martin
On 5.6.2014 22:21, Stephen F Northover wrote:
Seems like we can't/shouldn't fix this. We can at least make sure it
is documented.
Steve
On 2014-06-05, 4:19 PM, Martin Sladecek wrote:
Currently, we use case to distinguish between newly created objects
(upper-case class name) and properties (lower-case). Otherwise, it
would not be clear when there's e.g. a text property and text class
if we should set a property called text or create new text object and
try to assign it to the default property. The same problem with
static setters.
Is "hello.text.text" a fully qualified name of text class in or
"text" static setter of a hello.text class?
I guess we could define some order in which we would try out this
options in the current context, but SB will have a problem since they
use static mode which can be used without having the classes on the cp.
-Martin
On 5.6.2014 20:57, Stephen F Northover wrote:
I see no reason why we should enforce this. Martin, any idea?
Steve
On 2014-06-05, 12:05 PM, Guillaume Anctil wrote:
Hi,
on a project I work on, the code convention does not follow the Java
standard and class names start with a lower case 'c':
"cSomeClass.java"
In the parsing of the FXMLLoader, the loadType function
looks
like this:
int i = name.indexOf('.');
int n = name.length();
while (i != -1
&& i < n
&& Character.isLowerCase(name.charAt(i + 1))) {
i = name.indexOf('.', i + 1);
}
if (i == -1 || i == n) {
throw new ClassNotFoundException();
}
String packageName = name.substring(0, i);
String className = name.substring(i + 1);
This causes a ClassNotFoundException on our custom controls because
of the
lowercase check.
I was wondering if a simple:
int i = name.lastIndexOf('.');
Instead of the lowercase check could be viable. The
ClassNotFoundException
would still be thrown later on, when trying to actually load the
class.
Is there a reason that I don't see why the convention _must_ be
upheld in
this case?
Thanks.
Re: FXMLLoader checking code conventions too much?
Seems like we can't/shouldn't fix this. We can at least make sure it is
documented.
Steve
On 2014-06-05, 4:19 PM, Martin Sladecek wrote:
Currently, we use case to distinguish between newly created objects
(upper-case class name) and properties (lower-case). Otherwise, it
would not be clear when there's e.g. a text property and text class if
we should set a property called text or create new text object and try
to assign it to the default property. The same problem with static
setters.
Is "hello.text.text" a fully qualified name of text class in or "text"
static setter of a hello.text class?
I guess we could define some order in which we would try out this
options in the current context, but SB will have a problem since they
use static mode which can be used without having the classes on the cp.
-Martin
On 5.6.2014 20:57, Stephen F Northover wrote:
I see no reason why we should enforce this. Martin, any idea?
Steve
On 2014-06-05, 12:05 PM, Guillaume Anctil wrote:
Hi,
on a project I work on, the code convention does not follow the Java
standard and class names start with a lower case 'c': "cSomeClass.java"
In the parsing of the FXMLLoader, the loadType function
looks
like this:
int i = name.indexOf('.');
int n = name.length();
while (i != -1
&& i < n
&& Character.isLowerCase(name.charAt(i + 1))) {
i = name.indexOf('.', i + 1);
}
if (i == -1 || i == n) {
throw new ClassNotFoundException();
}
String packageName = name.substring(0, i);
String className = name.substring(i + 1);
This causes a ClassNotFoundException on our custom controls because
of the
lowercase check.
I was wondering if a simple:
int i = name.lastIndexOf('.');
Instead of the lowercase check could be viable. The
ClassNotFoundException
would still be thrown later on, when trying to actually load the class.
Is there a reason that I don't see why the convention _must_ be
upheld in
this case?
Thanks.
Re: FXMLLoader checking code conventions too much?
Currently, we use case to distinguish between newly created objects
(upper-case class name) and properties (lower-case). Otherwise, it would
not be clear when there's e.g. a text property and text class if we
should set a property called text or create new text object and try to
assign it to the default property. The same problem with static setters.
Is "hello.text.text" a fully qualified name of text class in or "text"
static setter of a hello.text class?
I guess we could define some order in which we would try out this
options in the current context, but SB will have a problem since they
use static mode which can be used without having the classes on the cp.
-Martin
On 5.6.2014 20:57, Stephen F Northover wrote:
I see no reason why we should enforce this. Martin, any idea?
Steve
On 2014-06-05, 12:05 PM, Guillaume Anctil wrote:
Hi,
on a project I work on, the code convention does not follow the Java
standard and class names start with a lower case 'c': "cSomeClass.java"
In the parsing of the FXMLLoader, the loadType function
looks
like this:
int i = name.indexOf('.');
int n = name.length();
while (i != -1
&& i < n
&& Character.isLowerCase(name.charAt(i + 1))) {
i = name.indexOf('.', i + 1);
}
if (i == -1 || i == n) {
throw new ClassNotFoundException();
}
String packageName = name.substring(0, i);
String className = name.substring(i + 1);
This causes a ClassNotFoundException on our custom controls because
of the
lowercase check.
I was wondering if a simple:
int i = name.lastIndexOf('.');
Instead of the lowercase check could be viable. The
ClassNotFoundException
would still be thrown later on, when trying to actually load the class.
Is there a reason that I don't see why the convention _must_ be
upheld in
this case?
Thanks.
Re: FXMLLoader checking code conventions too much?
I see no reason why we should enforce this. Martin, any idea?
Steve
On 2014-06-05, 12:05 PM, Guillaume Anctil wrote:
Hi,
on a project I work on, the code convention does not follow the Java
standard and class names start with a lower case 'c': "cSomeClass.java"
In the parsing of the FXMLLoader, the loadType function looks
like this:
int i = name.indexOf('.');
int n = name.length();
while (i != -1
&& i < n
&& Character.isLowerCase(name.charAt(i + 1))) {
i = name.indexOf('.', i + 1);
}
if (i == -1 || i == n) {
throw new ClassNotFoundException();
}
String packageName = name.substring(0, i);
String className = name.substring(i + 1);
This causes a ClassNotFoundException on our custom controls because of the
lowercase check.
I was wondering if a simple:
int i = name.lastIndexOf('.');
Instead of the lowercase check could be viable. The ClassNotFoundException
would still be thrown later on, when trying to actually load the class.
Is there a reason that I don't see why the convention _must_ be upheld in
this case?
Thanks.
Re: How to scale control properly?
Thanks for advice. I know this trick with wrapping in a Group, but as i wrote on stackoverflow, there is dropshadow effect after moving mouse over the control. This effect extends group's layoutBounds for a while. And when mouse leaves out the control, then group's layoutBounds shrink. I found the sources/css for this control: https://bitbucket.org/controlsfx/controlsfx/src/96f40eb0b579277139192e2398fbbaf7fd01f91e/controlsfx/src/main/resources/org/controlsfx/control/rating.css?at=default -- Rafal 2014-06-05 16:12 GMT+02:00 Martin Sladecek : > Hi Rafal, > you can wrap the control in a Group. That way, it's (actually Group's) > layoutBounds will be the same as it's transformed bounds (boundsInParent). > Alternatively you can use css styling, but I don't know much about how to > do it properly, maybe Jonathan can help you there. > > -Martin > > > On 06/05/2014 01:13 AM, Rafal Leibzig wrote: > >> Hi, >> >> Sorry for disturbing you, but I have a question and no one answered me on >> other forums. >> >> My question is rather simple: >> >> http://stackoverflow.com/questions/23997115/how-to- >> scale-control-and-layout-it-properly-in-javafx >> >> >> Thanks in advance. >> You are the experts. :) >> >> >> >
FXMLLoader checking code conventions too much?
Hi,
on a project I work on, the code convention does not follow the Java
standard and class names start with a lower case 'c': "cSomeClass.java"
In the parsing of the FXMLLoader, the loadType function looks
like this:
int i = name.indexOf('.');
int n = name.length();
while (i != -1
&& i < n
&& Character.isLowerCase(name.charAt(i + 1))) {
i = name.indexOf('.', i + 1);
}
if (i == -1 || i == n) {
throw new ClassNotFoundException();
}
String packageName = name.substring(0, i);
String className = name.substring(i + 1);
This causes a ClassNotFoundException on our custom controls because of the
lowercase check.
I was wondering if a simple:
int i = name.lastIndexOf('.');
Instead of the lowercase check could be viable. The ClassNotFoundException
would still be thrown later on, when trying to actually load the class.
Is there a reason that I don't see why the convention _must_ be upheld in
this case?
Thanks.
hg: openjfx/8u-dev/rt: RT-37373 [Unit Tests] - Intermittent failure in com.sun.glass.ui.monocle.input.RotateTest
Changeset: eb7ab0261393 Author:Elina Kleyman Date: 2014-06-05 17:41 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/eb7ab0261393 RT-37373 [Unit Tests] - Intermittent failure in com.sun.glass.ui.monocle.input.RotateTest ! tests/system/src/test/java/com/sun/glass/ui/monocle/input/RotateTest.java
hg: openjfx/8u-dev/rt: RT-37396: [CSS] pseudo-class state not taking effect
Changeset: 2a1db2fff116 Author:David Grieve Date: 2014-06-05 10:15 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/2a1db2fff116 RT-37396: [CSS] pseudo-class state not taking effect ! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java
Re: How to scale control properly?
Hi Rafal, you can wrap the control in a Group. That way, it's (actually Group's) layoutBounds will be the same as it's transformed bounds (boundsInParent). Alternatively you can use css styling, but I don't know much about how to do it properly, maybe Jonathan can help you there. -Martin On 06/05/2014 01:13 AM, Rafal Leibzig wrote: Hi, Sorry for disturbing you, but I have a question and no one answered me on other forums. My question is rather simple: http://stackoverflow.com/questions/23997115/how-to-scale-control-and-layout-it-properly-in-javafx Thanks in advance. You are the experts. :)
