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(Liste
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
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
O
On 22.01.14 11:07, Martin Sladecek 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 tha
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 v
On 01/22/2014 11:27 AM, Tom Schindl wrote:
On 22.01.14 11:07, Martin Sladecek 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.
On 01/22/2014 11:38 AM, Randahl Fink Isaksen wrote:
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
app
>> 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
>> Observabl
I respect your point of view. Thank you for a thorough response.
Randahl
On 22 Jan 2014, at 12:18, Martin Sladecek wrote:
> On 01/22/2014 11:38 AM, Randahl Fink Isaksen wrote:
>> Hi Martin
>>
>> Then I respectfully disagree with this design decision. In my point of view,
>> choosing perform
On Wed, Jan 22, 2014 at 11:27 AM, Tom Schindl
wrote:
> On 22.01.14 11:07, Martin Sladecek 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 dupl
On 01/22/2014 12:30 PM, Richard Bair wrote:
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 wou
Hi,
I'm interested in headless testing, too. I tried to use StubToolkit for
including TestFX tests in a headless build, but all I got was a CNFE. If anyone
is interested to give me a hand on this, details can be found at
http://stackoverflow.com/questions/21137039/how-to-use-stubtoolkit-instead
Hi Randahl,
I'm curious about an example where you would take advantage of the behavior
where multiple addListener(listener) calls add the listener just once.
Anyway, here [1] are helper classes InvalidationSubscriber and
ChangeSubscriber that allow you to do that:
InvalidationSubscriber subscri
On 01/22/2014 12:30 PM, Richard Bair wrote:
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 wou
[...]
> Actually even when you would rely on the order, in situations when you
> call ensureListener, you don't really know if the listener is already
> there. So you might really expect that listener would be added at this
> point as the last. It's just that will always be the outcome if the
> de
Hi Tomas
Great idea! I can see how the InvalidationSubscriber idea would work – but it
is just a concept right? There is no official API for this, right?
Randahl
On 22 Jan 2014, at 13:34, Tomas Mikula wrote:
> Hi Randahl,
>
> I'm curious about an example where you would take advantage of
Hi Tomas
About the example you request: Say you and I implemented a computer game with
spaceships on screen, and lets imagine that these spaceships attacked in
groups. Everytime a spaceship was added to a group, we wanted to listen to a
property of that spaceship from that point in time and unt
I suggest adding another overload for addListener method taking boolean
parameter "duplicateAllowed" or "duplicateNotAllowed".
On Wed, Jan 22, 2014 at 3:00 PM, Richard Bair wrote:
> >> The default implementation (for Observable) would look like this:
> >>
> >> public default void ensureListener
There is no official API. You are free to copy-paste the code from the link
I posted to your project.
On Wed, Jan 22, 2014 at 1:59 PM, Randahl Fink Isaksen wrote:
> Hi Tomas
>
> Great idea! I can see how the InvalidationSubscriber idea would work – but
> it is just a concept right? There is no o
Thanks for an example. I imagined something analogous to your example, but
the part I'm curious about is this
"We still wanted to listen to a property of the spaceship, but now it was
no longer part of the group."
Why would you want to keep listening to that spaceship after removal from
the group
Well it is just an fictive example. But for instance, there could be game rules
that required us to listen to the energyPoints of all spaceships that had ever
been part of the group. Perhaps the group would dissolve if more than 10
spaceships that had ever been part of the group where shot down.
Hi David,
please review:
http://cr.openjdk.java.net/~msladecek/rt-35462/webrev
https://javafx-jira.kenai.com/browse/RT-35462
Thanks,
-Martin
Hi Tom,
You have it right. Currently the VNC server is always running on port 5901, but
feel free to open a JIRA to change that.
If you want to test this today you need to build OpenJFX yourself
(https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX). We don’t have
snapshots of 8u20 o
Hi Uwe,
On Jan 22, 2014, at 2:19 PM, Uwe Sander wrote:
> Hi,
>
> I'm interested in headless testing, too. I tried to use StubToolkit for
> including TestFX tests in a headless build, but all I got was a CNFE. If
> anyone is interested to give me a hand on this, details can be found at
> http
https://javafx-jira.kenai.com/browse/RT-35473
On 2014-1-22 14:41, Daniel Blaukopf wrote:
Hi Tom,
You have it right. Currently the VNC server is always running on port 5901, but
feel free to open a JIRA to change that.
If you want to test this today you need to build OpenJFX yourself
(https
Thanks John! I agree that in an IoT environment where you can have many
devices, a central gateway and a fast local network, a solution based on remote
display could work well.
Daniel
On Jan 22, 2014, at 1:07 AM, John Smith wrote:
> Monocle is a very interesting and exciting development for t
Changeset: aa08f837ac40
Author:Daniel Blaukopf
Date: 2014-01-22 15:49 +0200
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/aa08f837ac40
RT-35443 Provide a headless glass implementation integrated with our JUnit tests
Reviewed-by: snortho, anthony
! build.gradle
Thanks for your answer, Daniel.
If there's still a use case for StubToolkit, I'd like to know why I get a CNFE
when I'm trying to use it in a simple JavaFX application (see the link in my
previous message). Has anyone succeeded in building and using it (outside
Oracle)?
Cheers,
Uwe
Daniel
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
Steve
On 2014-01-22 11:14 AM, Uwe Sander wrote:
Hi Steve,
Thanks for your answer.
Let me ask another questio
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,
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.
Changeset: 2e23e1f2b922
Author:lisa.se...@oracle.com
Date: 2014-01-22 13:04 -0500
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/2e23e1f2b922
Initial push for RT-35243 - prism should use Monocle's platform detection code.
Creates a new prism es2 port (prism-es-monocle) whic
Changeset: a9a442d98304
Author:hudson
Date: 2014-01-22 08:44 -0800
URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a9a442d98304
Added tag 8.0-b125 for changeset 3e1c456afa4c
! .hgtags
Changeset: f7e4bebcf795
Author:Felipe Heidrich
Date: 2014-01-22 07:49 -0800
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f7e4bebcf795
RT-35487: build files should use IS_COMPILE_PANGO (instead of COMPILE_PANGO)
! buildSrc/armv6hf.gradle
! buildSrc/armv6sf.gradle
! buildSr
Changeset: cbe1008fbea3
Author:flar
Date: 2014-01-22 11:25 -0800
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/cbe1008fbea3
Fix RT-25249: ImageInput effect not updated when WritableImage is updated
Reviewed by Felipe and Chien
! modules/graphics/src/main/java/javafx/scene/
Changeset: 3943d4344924
Author:flar
Date: 2014-01-22 13:39 -0800
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/3943d4344924
Fix RT-33294: Canas PixelWriter can be very slow
Reviewed by Felipe and Chien
! modules/graphics/src/main/java/com/sun/javafx/sg/prism/GrowableDataBu
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 thes
The point is that we'd rather have quick reference to the historical
discussion without having to cross-reference between jira and the
mailing list archives (which isn't automatically done). Once you add
yourself as a watcher to the jira issue you are notified of every
change, in much the same way
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
Changeset: a46ffa89a080
Author:jgiles
Date: 2014-01-23 12:54 +1300
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a46ffa89a080
RT-35141: [TableView] TableView Column Reordering sometimes fails and often
doesn't match the visual feedback
!
modules/controls/src/main/java/com
40 matches
Mail list logo
