I'm sorry, but I can't. We decided to keep the discussion there internal.
-Martin
On 02/25/2014 01:36 PM, Tom Schindl wrote:
Can you make the bug public?
Tom
On 25.02.14 12:48, hang...@oracle.com wrote:
Changeset: 876e334f748a
Author:Martin Sladecek martin.slade...@oracle.com
Date
Looks good, please file the request into JIRA, so it won't get lost.
Thanks,
-Martin
On 02/18/2014 06:25 PM, anton nashatyrev wrote:
Hello All,
I'd like to add my 2 cents to lambdafication of JavaFX:
Recently I was working on a fix in the JFX and used convenient JFX
beans feature -
Jonathan,
please review:
https://javafx-jira.kenai.com/browse/RT-23528
http://cr.openjdk.java.net/~msladecek/rt-23528/webrev.00/
Thanks,
-Martin
Hi Jonathan,
please review the following:
https://javafx-jira.kenai.com/browse/RT-23406
http://cr.openjdk.java.net/~msladecek/rt-23406/webrev.00/
https://javafx-jira.kenai.com/browse/RT-21664
http://cr.openjdk.java.net/~msladecek/rt-21664/webrev.00/
Thanks,
-Martin
The rule of thumb in case you modify content during the layout is that
content should depend on layout pane size, not the other way around. It
means that changing the content won't modify the min/pref/max size of
the pane as that would trigger another layout pass (possibly falling
into a
Jonathan,
please review:
https://javafx-jira.kenai.com/browse/RT-35180
http://cr.openjdk.java.net/~msladecek/rt-35180/webrev.00/
Thanks,
-Martin
Hi Jonathan,
please review:
https://javafx-jira.kenai.com/browse/RT-21091
http://cr.openjdk.java.net/~msladecek/rt-21091/webrev/
Thanks,
-Martin
Anthony,
please review:
https://javafx-jira.kenai.com/browse/RT-35437
http://cr.openjdk.java.net/~msladecek/rt-35437/webrev.00/
Thanks,
-Martin
Anthony,
please review:
https://javafx-jira.kenai.com/browse/RT-35570
http://cr.openjdk.java.net/~msladecek/rt-35570/webrev.00/
Thanks,
-Martin
Jonathan, David,
please review the following.
Webrev: http://cr.openjdk.java.net/~msladecek/rt-32090/webrev.00/
JIRA: https://javafx-jira.kenai.com/browse/RT-32090
Thanks,
-Martin
Hi,
please review:
https://javafx-jira.kenai.com/browse/RT-28978
http://cr.openjdk.java.net/~msladecek/rt-28978/webrev.00/
Thanks,
-Martin
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
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
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
-Djavafx.debug=true.
Regards,
-Martin
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
Hi David,
please review:
http://cr.openjdk.java.net/~msladecek/rt-35462/webrev
https://javafx-jira.kenai.com/browse/RT-35462
Thanks,
-Martin
Related JIRA issue: https://javafx-jira.kenai.com/browse/RT-17646
Uni-directional binding is possible using ${path.to.property} syntax
(see
http://docs.oracle.com/javafx/2/api/javafx/fxml/doc-files/introduction_to_fxml.html#expression_binding)
-Martin
On 01/20/2014 08:42 PM, Richard Bair
Hello,
here's a changeset for RT-35237 (When a Bidirectional binding fails, old
value restoration may cause an exception hiding the real cause),
if anybody's interested.
http://hg.openjdk.java.net/openjfx/8u-dev/graphics/rt/rev/f487abfe1990
Thanks,
-Martin
Jim, Jonathan,
please review:
http://cr.openjdk.java.net/~msladecek/rt-35015/webrev.00/
JIRA: https://javafx-jira.kenai.com/browse/RT-35015
Thanks,
-Martin
Hi John,
the reason why the logging was introduced is that when selectBinding is
evaluated and there's a null along the way, you don't know where the
actual (null) value comes from. E.g.
Bindings.selectString(insertedMedia, title) might be null if
insertedMedia.get() == null ||
Jim,
please review
JIRA: https://javafx-jira.kenai.com/browse/RT-34928
Webrev: http://cr.openjdk.java.net/~msladecek/rt-34928/webrev.00/
Thanks,
-Martin
Hi Jim,
please review the following: https://javafx-jira.kenai.com/browse/RT-34882
webrev: http://cr.openjdk.java.net/~msladecek/rt-34882/webrev.00/
Thanks,
-Martin
Hi Kevin,
please review: https://javafx-jira.kenai.com/browse/RT-29816
webrev: http://cr.openjdk.java.net/~msladecek/rt-29816/webrev.00/
Thanks,
-Martin
Jonathan,
please review:
JIRA: https://javafx-jira.kenai.com/browse/RT-34142
webrev: http://cr.openjdk.java.net/~msladecek/rt-34142/webrev.00/
http://cr.openjdk.java.net/%7Emsladecek/rt-34142/webrev.00/
Thanks,
-Martin
Hi David, Eva,
please review:
JIRA: https://javafx-jira.kenai.com/browse/RT-34609
Webrev: http://cr.openjdk.java.net/~msladecek/rt-34609/webrev.00/
http://cr.openjdk.java.net/%7Emsladecek/rt-34609/webrev.00/
Thanks,
-Martin
Hi Jonathan,
please review the following:
JIRA: https://javafx-jira.kenai.com/browse/RT-34513
webrev: http://cr.openjdk.java.net/~msladecek/rt-34513/webrev.00/
http://cr.openjdk.java.net/%7Emsladecek/rt-34513/webrev.00/
Thanks,
-Martin
Jonathan,
please review the following.
Webrev: http://cr.openjdk.java.net/~msladecek/rt-34450/webrev.00/
JIRA: https://javafx-jira.kenai.com/browse/RT-34450
Thanks,
-Martin
Jim, Chien,
please review:
webrev: http://cr.openjdk.java.net/~msladecek/rt-34128/webrev.00/
http://cr.openjdk.java.net/%7Emsladecek/rt-34128/webrev.00/
JIRA: https://javafx-jira.kenai.com/browse/RT-34128
Thanks,
-Martin
Webrev: http://cr.openjdk.java.net/~msladecek/rt-27775/webrev.00/
http://cr.openjdk.java.net/%7Emsladecek/rt-27775/webrev.00/
JIRA: https://javafx-jira.kenai.com/browse/RT-27775
Thanks,
-Martin
Hi,
please review the following change.
webrev: http://cr.openjdk.java.net/~msladecek/rt-33776/webrev.00/
http://cr.openjdk.java.net/%7Emsladecek/rt-33776/webrev.00/
JIRA: https://javafx-jira.kenai.com/browse/RT-33776
Thanks,
-Martin
webrev: http://cr.openjdk.java.net/~msladecek/rt-34271/webrev.00/
http://cr.openjdk.java.net/%7Emsladecek/rt-34271/webrev.00/
JIRA: https://javafx-jira.kenai.com/browse/RT-34271
Thanks,
-Martin
Hello,
Please review the fix for:
https://javafx-jira.kenai.com/browse/RT-32692#comment-367554
available here:
http://cr.openjdk.java.net/~msladecek/rt-32692/webrev.00/
http://cr.openjdk.java.net/%7Emsladecek/rt-32692/webrev.00/
Thanks,
-Martin
It depends on what you need to recompute. If you invalidate some
properties and the internal layout depends on these properties, then
also your pref/min size depends on these properties.
The layout (simplified) usually works in 3 steps: 1)compute the layout
using min/pref/max size of children
On 11/06/2013 07:31 PM, John Hendrikx wrote:
On 5/11/2013 20:10, Jonathan Giles wrote:
You're right in that controls don't tend to use ScenePulseListener. This
may be due to an oversight on our part, or just that our requirements
differ (I don't honestly know).
You're also right that it is
Hi Mario,
this is definitely a bug. Can you file this to JIRA, preferably with
some test case that fails for you?
Thanks,
-Martin
On 11/07/2013 11:48 AM, Mario Ivankovits wrote:
Hi JavaFX-Devs!
I do have a situation where the GridPane prevents the refreshing of parts of a
scene.
Unhappily
This is something different. When properties depends on each other
(using bindings), the binding computation is deferred to the first query
(get() call) of the dependant. That means, if q depends on p, you can
call p.set() as many times you want, but the recomputation will be
triggered just
On 11/07/2013 03:18 PM, Tomas Mikula wrote:
Hi Martin,
On Thu, Nov 7, 2013 at 2:32 PM, Martin Sladecek
martin.slade...@oracle.com wrote:
This is something different. When properties depends on each other (using
bindings), the binding computation is deferred to the first query (get()
call
On 11/07/2013 04:03 PM, Tomas Mikula wrote:
On Thu, Nov 7, 2013 at 3:34 PM, Martin Sladecek
martin.slade...@oracle.com wrote:
On 11/07/2013 03:18 PM, Tomas Mikula wrote:
Hi Martin,
On Thu, Nov 7, 2013 at 2:32 PM, Martin Sladecek
martin.slade...@oracle.com wrote:
This is something different
That would work, except you need to hard-ref the binding otherwise it
might get GCed.
-Martin
On 10/01/2013 02:53 PM, anton nashatyrev wrote:
Hi Pedro,
you may try the following code:
Bindings.select(node.sceneProperty(), window,
showing).addListener(new ChangeListenerBoolean() );
Hi,
I would like to change FXMLLoader load() and load(InputStream).
Both are returning Object (i.e. require a cast), while the static load()
methods are generified by T.
A simple change would allow us to avoid casts, but keeping the ABI
unchanged:
public T T load();
public T T
Hello,
FXMLLoader contains a number of protected (non-final) fields that were
made 'protected' probably just by accident. I'm going to make these
fields private. If there's somebody who is working on a FXMLLoader
subclass, let me know if you need some of the fields, so we could turn
them
Hi,
I propose to support Property handlers that are similar to
ChangeListener (used to listen on property changes) and accept
(ObservableValue, T, T), where T can be of any class. Failure to provide
a class that is a the same or supertype/interface of the real class will
result in CCE (as
around instead of having things in the wrong place the first time,
only to be moved around the next pass.
Richard
On Sep 3, 2013, at 9:50 PM, Martin Sladecek
martin.slade...@oracle.com mailto:martin.slade...@oracle.com
wrote:
Maybe the USE_COMPUTED_BASELINE_OFFSET should
Hi,
related JIRA issue: https://javafx-jira.kenai.com/browse/RT-31006
I propose to add constant public static final double
USE_COMPUTED_BASELINE_OFFSET to Node class.
This would be returned by the default Node implementation of
getBaselineOffset. Currently, the layout bounds are returned,
Hi Tomas,
unfortunately, this is not possible.
I have filed a JIRA issue https://javafx-jira.kenai.com/browse/RT-32655
for the setAll method with range.
The subList doesn't return an ObservableList, as the sublists become
invalid once there's some structural change on the list. That would
can enable sorting just be wrapping it into a
SortedList before passing it to the TableView.
Regards,
-Martin
On 08/16/2013 11:04 AM, Jonathan Giles wrote:
This is a FilteredList issue that Martin Sladecek is looking into.
-- Jonathan
Sent from a touch device. Please excuse my brevity.
Martin
Sounds like a plan.
I'll retarget RT-31133 (validate) to Van Ness in case it would be
required later.
I will change the layout processing so that it uses flags instead of
dirty root lists. That way, getRoot().layout() will trigger a complete
layout pass or both Scenes and SubScenes.
Means
wrote:
I don't think I understand the answer. Are you saying that what we
are suggesting is wrong conceptually or hard to implement or ...?
Steve
On 11/07/2013 1:23 PM, Martin Sladecek wrote:
No, I will change the dirty roots to dirty flags on every node. With
them, it's possible to use
validate does? Is it sent to a leaf or the
root node or does it matter?
Steve
On 12/07/2013 6:36 AM, Martin Sladecek wrote:
What you suggest would be quite hard to use. Actually I think most of
the developers will not know how to use it properly in order to get
the right measurement.
Simple
On 07/12/2013 04:49 PM, Richard Bair wrote:
The thing is that in order to compute the layout correctly, you have to start
from the layout root.
I think where you start the computation from depends on what you are trying to do. I
think that validate or whatever we would call it would just be a
.
Steve
On 10/07/2013 2:50 AM, Martin Sladecek wrote:
+1
-Martin
On 07/09/2013 05:06 PM, Pavel Safrata wrote:
To me this sounds best so far. Perhaps updateVisuals() would be even
better?
Pavel
On 8.7.2013 18:45, Scott Palmer wrote:
validateVisuals() ?
Or something with the word visual
No, I will change the dirty roots to dirty flags on every node. With
them, it's possible to use it the way you suggest (applyCSS layout on
nearest layout root), but it's much more convenient if we could identify
the layout root of the subtree and apply the layout from there
downwards. I think
( if method is a side effect free):
verify()
verfifyNode()
verifyBounds()
checkNode()
checkBounds()
best Regards
Ali Ebrahimi
On Mon, Jul 8, 2013 at 4:50 PM, Martin Sladecek
martin.slade...@oracle.comwrote:
The plan is to have a final validate() method.
Anyway, does anybody have a better suggestion
()
best Regards
Ali Ebrahimi
On Mon, Jul 8, 2013 at 4:50 PM, Martin Sladecek
martin.slade...@oracle.com
mailto:martin.slade...@oracle.comwrote:
The plan is to have a final validate() method.
Anyway, does anybody have a better suggestion? The validate
should do
both
CSS and layout and I would
). For example TextField.validate() may look like validating
the input. Also I wouldn't be surprised if users run into problems with
custom nodes having their validate methods for different purposes.
Pavel
On 3.7.2013 14:33, Martin Sladecek wrote:
Hi,
JIRA: https://javafx-jira.kenai.com/browse/RT
Hi,
JIRA: https://javafx-jira.kenai.com/browse/RT-31133
I propose a single method public final void validate() to be added to
Node class. The validate method would ensure that the metrics (layout
bounds) of the Node are valid with regards to the current scenegraph
(CSS layout).
Together
this work on the CSS side would
require decoupling the 'css graph' from the scene-graph. RT-30894 touches on
that.
On Jul 3, 2013, at 8:33 AM, Martin Sladecek martin.slade...@oracle.com wrote:
Hi,
JIRA: https://javafx-jira.kenai.com/browse/RT-31133
I propose a single method public final void
On 06/11/2013 03:01 PM, Tom Eugelink wrote:
I know I'm reiterating, but just to keep the point alive; personally I
would still prefer to have such information placed in an explicit
layout constraint class.
node.setMargin(x); layout.getChildren().add(node);
vs
layout.add(node, new
JavaFX should not fail in these cases, but doesn't consider that a valid
state, so it always prints a warning on the stderr, for the developer to
see something went wrong.
Regards,
-Martin
On 5.6.2013 21:38, John Hendrikx wrote:
Hi List,
I'm getting some log messages sometimes (see at the
Hi John,
the problem you described is most likely caused by something else as the
layout pass occurs BEFORE the actual rendering.
Also, you bind managed and visible of the entire VBox, not just the
title. So it's strange that you see Label correctly laid-out, but not
the content.
Can you
After some discussion in the JIRA issue, the change will be much simpler:
null comparator will mean UNSORTED, not natural order (i.e. using
Comparable) as it does now.
The natural order can be done by passing Comparator.naturalOrder() to
the SortedList.
-Martin
On 05/31/2013 08:25 AM, Martin
Hi Mick,
I would like to introduce similar call, see
https://javafx-jira.kenai.com/browse/RT-30363
I called it requestParentLayout. There's an implementation in the
attached diff :
https://javafx-jira.kenai.com/secure/attachment/37081/rt-30363.diff
Regards,
-Martin
On 05/22/2013 04:18 PM,
101 - 162 of 162 matches
Mail list logo
