Re: JavaFX (1.7.0_45) and Applet: problem with layout
Could you provide a screen shot? R. On 19 Sep 2014, at 12:07, Fabrizio Giudici fabrizio.giud...@tidalwave.it wrote: On Tue, 16 Sep 2014 11:55:26 +0200, Fabrizio Giudici fabrizio.giud...@tidalwave.it wrote: Hello. A customer submitted me a problem concerning a Java WebStart applet made with JavaFX (JDK 1.7.0_45): the thing works, but at the beginning the rendering in the browser is such that a number of pixels are off the rendered area at the right and bottom borders. The problem happens with Internet Explorer and Firefox on Windows 8, even though by different pixel amounts. Just clicking with the mouse anywhere cause a re-computation of the layout so everything is ok. I can't review all of the code, so I focused on the FXML and worked on it by removing unneeded stuff and making sure that PREFERRED_SIZE is used whenever it makes sense. But the problem is always there. At this point, I think that a reasonable workaround would be to force a layout re-computation just after the initialization... but how am I supposed to do that? On a second instance, I'd like to understand what's wrong. Bump... anyone on this? Thanks. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Does JavaFX lack a public Property.getObservable() method?
I have noticed the lack of a getObservable() method of the property class, and I have come across a use case which might justify such a method, so I would like to discuss whether posting a new Jira issue for this is justified. I have implemented a simple toggle button with two states, on and off. The toggle button has a SimpleBooleanProperty value, and when the user switches the toggle button the value is negated. Now, in some cases I would like to bind the valueProperty to some observable boolean in my app, so that whenever that observable boolean is true, the button reflects that by switching to on. However, the problem is that if I bind the SimpleObjectProperty value to an observable boolean value, and then click the button to toggle it, a JavaFX exception tells me that I cannot negate the boolean value, since it is now bound. In such cases, I think it makes sense to have my toggle button change the state of the value it is bound to instead. But since the SimpleBooleanProperty does not have a getObservable() method, I have no way of accessing the value observed. Does this justify adding a public getObservable method to class Property? Yours Randahl
Re: Does JavaFX lack a public Property.getObservable() method?
Thank you both of you for some good tips. I will try those approached instead.
Randahl
On 12 Sep 2014, at 14:37, Tomas Mikula tomas.mik...@gmail.com wrote:
Hi Randahl,
if on button click you only want to update an external boolean
property, bidirectional binding suggested by Martin should be all you
need.
If the problem is more complex, it might be useful to recognize that
your toggle button serves two distinct functions:
1. It reflects the state (on/off) of an external object.
2. It manipulates an external object.
Treat these functions separately, i.e. on button click, don't change
the button value (and thus appearance) directly, but manipulate the
observed object.
// observe external object
button.valueProperty().bind(externalObject.stateProperty());
// manipulate external object
button.setOnAction(event - {
if(button.getValue()) {
externalObject.turnOff();
} else {
externalOBject.turnOn();
}
});
Your original button behavior of just changing the value (and thus
appearance) is achieved by
button.setOnAction(event - button.setValue(!button.getValue()));
Best,
Tomas
On Fri, Sep 12, 2014 at 1:08 PM, Martin Sladecek
martin.slade...@oracle.com wrote:
Hi Randahl,
why don't you use bidirectional binding for this purpose?
-Martin
On 09/12/2014 01:04 PM, Randahl Fink Isaksen wrote:
I have noticed the lack of a getObservable() method of the property class,
and I have come across a use case which might justify such a method, so I
would like to discuss whether posting a new Jira issue for this is
justified.
I have implemented a simple toggle button with two states, on and off. The
toggle button has a SimpleBooleanProperty value, and when the user switches
the toggle button the value is negated.
Now, in some cases I would like to bind the valueProperty to some
observable boolean in my app, so that whenever that observable boolean is
true, the button reflects that by switching to on. However, the problem is
that if I bind the SimpleObjectProperty value to an observable boolean
value, and then click the button to toggle it, a JavaFX exception tells me
that I cannot negate the boolean value, since it is now bound.
In such cases, I think it makes sense to have my toggle button change the
state of the value it is bound to instead. But since the
SimpleBooleanProperty does not have a getObservable() method, I have no way
of accessing the value observed.
Does this justify adding a public getObservable method to class Property?
Yours
Randahl
Randahl Fink Isaksen
Inventor / Software architect / Java expert
Owner of ROCK IT
Mobile +45 26 25 88 84
Skype randahl
Twitter @r4nd4hl
Is JavaFX keyboard event handling too rigid?
I have noticed that quite many developers are having trouble avoiding triggering of focus navigation occurring when a user presses the UP and DOWN arrow keys. From a number of different forum posts I have seen how people are jumping through hoops to avoid this. I myself have the challenge, that I need to use the UP and DOWN keys for changing the selected autocompletion in a text field, and it seems that no matter how greedily I try to consume or filter out these KeyEvents, JavaFX still insists on moving the focus from one field to the next. This got me thinking: Why is JavaFX keyboard event handling so rigid? If you implement a control which listens for keyboard events on itself and does some cool stuff, that is fine. But once you implement a subclass that wishes to replace some of that behaviour you are in trouble, because once the EventHandlers are registered, there is no public API to replace them. Is this a conscious design decision? Is it something that I should file a feature request on, or have I overlooked a part of the API which could be used here? Randahl
Double skin addition
I have noticed that if I create a skin which adds a label like this
public MySkin(MyControl control) {
super(control);
pane.getChildren().add(label);
getChildren().add(pane);
}
the label is actually added twice in my application. I suspect this is because
I am switching style sheets during startup, which means my createDefaultSkin
method might be invoked twice.
I found out, I can easily solve this by changing my code to using a
getChildren().setAll(label) rather than getChildren().add(label), but I am
surprised that JavaFX would not by itself clear the control’s children when
applying a new skin.
Has anyone else experienced this?
Thanks
Randahl
New skinning in FX8 – where do the style classes go
Hi everybody I am a bit puzzled by the changes to the Skinnable API. With FX2 I created a couple of SkinBase based skins, and back then SkinBase was a descendant of Control. So I had Control ◀︎—— SkinBase ◀︎—— MySkin Now SkinBase is just a descendant of Object, which means I need to rewrite my code to represent Object ◀︎—— SkinBase ◀︎—— MySkin —— MySkinControl (Of course I am curious why this change was made – has anyone seen any documentation about this?) One problem is, whenever I have a control MyControl using a skin class MySkin I used to be able to change the style class of MyControl and those changes would automatically be reflected by MySkin. Now with FX8 when I change the style class of MyControl, nothing happens. Am I supposed to bind the styleClass property of my MySkinControl instance to the styleClass of my MyControl instance? The API documentation is a bit scarce so any pointers in the right direction would be much appreciated. Thanks Randahl
Backwards compatibility broken: Why was Color made final
After upgrading to FX8, the framework I have been developing since the early access release of JavaFX three years ago is now broken. My framework has some really cool features for working with color, which relies on our own class PaletteColor which extends javafx.scene.paint.Color. Why would you, after three years, make the Color class final, thereby breaking backwards compatibility? I would really like to know the thoughts behind that decision. Yours Randahl
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
Hi Martin
While I agree your proposed solution would work, I still don’t understand why
JavaFX should keep on supporting duplicates in listener collections. Can anyone
come up with just 1 example of an application that might be depending on having
two listeners on the same Observable? E.g. this kind of code:
myObservable.addListener(myChangeListener); //add it
myObservable.addListener(myChangeListener); //add it again
In what kind of situation would this sort of code make any sense?
If we all feel confident that the presence of duplicates listeners is always an
error, I warmly recommend changing the API to be duplicate free.
Yours
Randahl
On 22 Jan 2014, at 11:07, Martin Sladecek martin.slade...@oracle.com wrote:
Hi all,
I would like to start discussion about an addition to API in Observable,
ObservableValue and all Observable collections.
There were multiple requests for a way how to avoid duplicates in listeners
lists. The way RT-25613 solves this is that it introduces public boolean
hasListener(ListenerType listener) which would return true if the provided
listener is already registered.
This has one significant drawback that all of Observable* are actually
interfaces. Means we can only add hasListener as a defender method. The
problem is with the default implementation. We cannot return anything
meaningful, so we have to throw an UnsupportedOperationException. The problem
is that this might blow up unexpectedly when some older Observable
implementation is used. Also, it might be easy to miss when implementing the
interface, since the IDE might not force you to implement it.
So as an alternative solution, I propose adding something like:
ensureListener(ListenerType listener)
which would make sure the listener is on the list and if a listener is
already present, the number of times listener is registered on the Observable
will NOT grow after this call.
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.
What do you think?
JIRA link: https://javafx-jira.kenai.com/browse/RT-25613
-Martin
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
Hi Martin
Then I respectfully disagree with this design decision. In my point of view,
choosing performance over ease of use is rarely a good idea. Here, the
performance choice has put us in a situation where no one knows how many JavaFX
apps have duplicate listener bugs, and such bugs can be very hard to debug.
Have anyone done any tests that prove that avoiding listener duplicates would
lead to a severe performance impact?
I understand, that if all observables had thousands of listeners and we
searched for a possible duplicate using an inefficient linear search, we would
have a problem. But if reality is that very few observables have more than 20
listeners and these could be stored in a map for efficient duplicate checking,
then what is the problem?
Yours
Randahl
On 22 Jan 2014, at 11:26, Martin Sladecek martin.slade...@oracle.com wrote:
The reason why this was decided this way is simple : performance. You usually
don't (try to) add a listener twice, so in most cases it doesn't make sense
to check for duplicates every time a listener is added. So we currently leave
the burden of avoiding duplicates on the developer.
-Martin
On 01/22/2014 11:23 AM, Randahl Fink Isaksen wrote:
Hi Martin
While I agree your proposed solution would work, I still don’t understand
why JavaFX should keep on supporting duplicates in listener collections. Can
anyone come up with just 1 example of an application that might be depending
on having two listeners on the same Observable? E.g. this kind of code:
myObservable.addListener(myChangeListener); //add it
myObservable.addListener(myChangeListener); //add it again
In what kind of situation would this sort of code make any sense?
If we all feel confident that the presence of duplicates listeners is always
an error, I warmly recommend changing the API to be duplicate free.
Yours
Randahl
On 22 Jan 2014, at 11:07, Martin Sladecek martin.slade...@oracle.com wrote:
Hi all,
I would like to start discussion about an addition to API in Observable,
ObservableValue and all Observable collections.
There were multiple requests for a way how to avoid duplicates in listeners
lists. The way RT-25613 solves this is that it introduces public boolean
hasListener(ListenerType listener) which would return true if the provided
listener is already registered.
This has one significant drawback that all of Observable* are actually
interfaces. Means we can only add hasListener as a defender method. The
problem is with the default implementation. We cannot return anything
meaningful, so we have to throw an UnsupportedOperationException. The
problem is that this might blow up unexpectedly when some older
Observable implementation is used. Also, it might be easy to miss when
implementing the interface, since the IDE might not force you to implement
it.
So as an alternative solution, I propose adding something like:
ensureListener(ListenerType listener)
which would make sure the listener is on the list and if a listener is
already present, the number of times listener is registered on the
Observable will NOT grow after this call.
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.
What do you think?
JIRA link: https://javafx-jira.kenai.com/browse/RT-25613
-Martin
