This might work for CSS, but won't for layout. The second example won't
work because you'd just do layout of the node itself. It might get a
different size from it's parent during the next layout pass (and the
parent from it's parent, etc...). So the layout will look different
after the next pulse. This is why we need more than layout() call and
it's not just about adding the CSS.
Regards,
-Martin
On 07/10/2013 08:25 PM, steve.x.northo...@oracle.com wrote:
Hi Martin,
How about exposing the concept of applying CCS to the programmer?
Let's say we add applyCSS() that does exactly what it says (applies
CSS when called).
Here are a few use cases:
1) Positioning a popup:
node.applyCSS()
node.autosize();
// width and height are now valid
node.applyCSS();
// pref width and height are now valid
2) Taking a snapshot:
node.applyCSS();
node.autosize();
node. layout()
// take the snapshot (when talking multiple snapshots, don't need
to reapply CSS)
3) Find the location of a child control:
node.applyCSS();
node.autosize();
node.layout();
// find the child control by id, the bounds are valid
Richard had talked about applying the CSS automatically so that when
you ask for the width etc., if the width is not calculated, it gets
calculated and returned. There is nothing in the applyCSS() API the
precludes us from writing this automatic code in the future. In that
case, applyCSS() would become a hint or a no-op.
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" as it combines layout and other
CSS
information.
Scott
On Mon, Jul 8, 2013 at 12:31 PM, Richard Bair
<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> 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
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>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