On 07/09/2013 10:59 PM, David Grieve wrote:
Since there is already a "requestLayout()" which defers to the next
pulse, what about "demandLayout()"? Or why can't getBoundsInParent()
or getBoundsInLocal() do this?
Even with this function, there is still the problem where the
dimensions of a node won't be right if called before the node is added
to the scene.
Button button = new Button("Hello World!");
root.getChildren().add(button);
button.demandLayout();
double width0 = button.getWidth();
Scene scene = new Scene(root);
button.demandLayout();
double width1 = button.getWidth();
Note that width0 != width1 because the layout at width0 has no css
styles until the button is in the scene-graph, which doesn't happen in
this example until 'new Scene(root)'. Should the "validate" throw an
exception if the node isn't in the scene-graph?
I guess it should.
I still think it is worth holding out for something like 'public
static Bounds getBounds(Scene scene, Parent parent, Node child)' which
would return the Bounds of the child if it were a child of the given
parent in the given scene.
While I agree this is something that would be useful, I don't think it
should replace the "validate" method. Such method shouldn't probably
change CSS/layout on place and everything would have to be recomputed
separately. This would require additional methods for CSS and layout.
-Martin
On Jul 8, 2013, at 1:01 PM, Richard Bair <richard.b...@oracle.com
<mailto:richard.b...@oracle.com>> wrote:
So this was also my first desire. I wanted to actually make it so
that nobody would ever have to invoke a CSS pass manually, but
instead we would just do it lazily on first request as needed. If
this is possible then we can only think of the layout problem in
isolation. In this case, just reusing the existing layout() method
seems like the right thing to do.
I can't remember on this Monday morning why I decided it wasn't
possible to handle CSS lazily in this manner. But it is *really* what
I want to do if it is possible. I'm sure there are lots of
possibilities for strange performance issues with this approach when
you bind certain properties.
Richard
On Jul 8, 2013, at 9:52 AM, David Grieve <david.gri...@oracle.com
<mailto:david.gri...@oracle.com>> wrote:
I'm wondering why this "validate" can't just be implicit in any call
that uses or returns layout bounds. Surely we can tell from the
dirty bits whether or not something needs layout and/or css.
On Jul 8, 2013, at 12:31 PM, Richard Bair <richard.b...@oracle.com
<mailto:richard.b...@oracle.com>> wrote:
OK, just throwing something wild out there. Right now we have a
layout pass and a css pass. Can they be combined? Can we combine
them just into something that happens during layout? And can the
existing "layout()" method be the thing that kicks it all off?
Wild and crazy but just throwing it out there (personally I'm
uncomfortable conflating CSS and layout as I believe there will be
use cases to do one and not the other at times).
Richard
On Jul 8, 2013, at 9:27 AM, Scott Palmer <swpal...@gmail.com
<mailto:swpal...@gmail.com>> wrote:
Since CSS is implicitly tied to layout, validateLayout() seems to
be enough.
I don't like "verify" or "check" - To me, these imply a method that is
doing checks only and not changing state. A "verify" method would be
something that returns a boolean or throws an exception.
Scott
On Mon, Jul 8, 2013 at 9:07 AM, Ali Ebrahimi
<ali.ebrahimi1...@gmail.com <mailto:ali.ebrahimi1...@gmail.com>>wrote:
just my suggestions:
validation is a side effect free concept. but your validate
contains css &
layout processing for Node, so validate is very poor name in
this case.
May be better use computeBounds instead.
But alternates for validate( 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.com
<mailto:martin.slade...@oracle.com>>wrote:
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 like to avoid method name that's too
descriptive
(like validateLayoutAndCSS()) if possible.
I think the most important thing about the method is that it
validates
the
bounds/metrics of the Node, so maybe validateBounds() ?
-Martin
On 07/08/2013 01:52 PM, Anthony Petrov wrote:
+1
The validate()/isValid() in AWT/Swing are often overridden by
user apps
for tasks that have nothing to do with the layout. And this
causes a
lot of
problems.
--
best regards,
Anthony
On 07/08/13 15:20, Pavel Safrata wrote:
Hello,
one more discussion topic: perhaps the "validate" name is too
general?
Maybe we can come up with more descriptive name? There are all
kinds of
nodes and sometimes this name can be misleading (not ringing
the layout
bell at all). 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-31133<
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 with this change, Parent.layout() will be deprecated.
In my current implementation, validate() method works only if
the Node
is in a Scene. To make it work without a Scene, we'd need to
do do
some small adjustments to CSS (doesn't work with getScene()
== null).
But I'm not sure if such feature would be useful.
Regards,
-Martin
