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
I'm thinking applyCSS would just call impl_processCSS(true) and then we should
work towards removing impl_processCSS(boolean) if possible, so that we're all
just using applyCSS() all the time (once impl_processCSS(boolean) can be
removed and all bugs sorted out, then we could just move impl_proc
There is Node#impl_processCSS() that is the normal css processing path
(Scene#doCSSPass -> Node#processCSS -> Node#impl_processCSS() ->
CssStyleHelper#transitionToState) .
impl_processCSS(boolean) was left in because it is a way of forcing the reapply
in cases where CSS was needed to be process
My thought was that applyCSS could for now just call impl_processCSS(true) --
so it is "Thor's Hammer" and will just hammer everything to be updated. Not
necessarily fast. Then in subsequent releases we could maybe tune it up. Do we
*need* the boolean? I know it is sometimes false (TreeView, Tab
I hesitate to mention Node#impl_processCSS(boolean) which is very very close to
your notion of applyCss(); impl_processCSS(boolean) is a thorn in my side, but
is used in certain places in controls code to ensure CSS is applied before
layout in order to ascertain a node's dimensions. What it doe
>> Is there any reason why I might want to measure a node independent of the
>> layout of its parent? If I have a Button in a StackPane, is there a time I
>> might want to measure the Button independent of the StackPane? I suppose so,
>> if for example I wanted to get snapshots of it at its min
> 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
convenient wrapper that did whatever w
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
The thing is that in order to compute the layout correctly, you have to
start from the layout root. The concept of layout roots is not
documented well in the API ( we use the term in few place, but never
define it) and people would have to know how to identify the layout root
and also know that
I don't agree. It's pretty clear that when you call applyCSS(), then
CSS is applied. The rest of the JFX API works exactly as expected and
as documented. The programmer has precise control over what happens,
when it happens and where it happens.
Can you summarize what "validate" does? Is i
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 "validate" call would be more convenient and less error-prone.
-Martin
On 07/12/2013 12:02 AM, steve.x.northo...@oracle.com wr
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 it the way y
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
>> 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
On 11/07/2013 3:16 AM, Martin Sladecek wrote:
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 t
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 pu
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 vali
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 nod
+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 09.07.13 22:59, David Grieve wrote:
> Since there is already a "requestLayout()" which defers to the next pulse,
> what about "demandLayout()"?
then I would go for forceLayout()
Tom
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
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 wrote:
OK, j
I think there would be a problem with property invalidation at least. A
property (like layoutBounds or any property set by CSS) would change on
get() although there was no invalidation notification (unless we'd
invalidate all affected properties on CSS/layout change - but most of
them would NOT
On 07/08/2013 06:29 PM, Richard Bair wrote:
But that is by far not the only thing the method will do. It will also make
sure all the CSS properties are applied. For example you can see what the
background of a Region will be, or any other property that can be set from CSS.
You are right, it's
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 reusin
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 wrote:
> OK, just throwing something wild out there. Right
I say validate should also not change state, otherwise computeBounds would
be better name for method.
Consider validate in input validation.
On Mon, Jul 8, 2013 at 8:57 PM, Scott Palmer wrote:
> Since CSS is implicitly tied to layout, validateLayout() seems to be
> enough.
>
> I don't like "ver
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 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 combin
But that is by far not the only thing the method will do. It will also make
sure all the CSS properties are applied. For example you can see what the
background of a Region will be, or any other property that can be set from CSS.
Is the reason you want to avoid validateLayoutAndCSS is that it mi
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 ou
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,
On Mon, 2013-07-08 at 14:20 +0200, Martin Sladecek 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
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()
ve
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 th
x-dev-boun...@openjdk.java.net] On Behalf Of Pavel Safrata
Sent: Monday, 8 July 2013 21:21
To: openjfx-dev@openjdk.java.net
Subject: Re: [API Review]: Node validation
Hello,
one more discussion topic: perhaps the "validate" name is too general?
Maybe we can come up with more descriptive name? There ar
+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
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
Without tests, there are actually only 2 in graphics (Parent, Text) and
2 in controls (XYChart).
XYChart seems to invoke the layout of both axes during the layout of the
chart. Not sure if this is necessary. The layout() method of children
should be normally called after the layoutChildren() of
Why does layout() need to be deprecated? Find Usages from IntelliJ reports 481
usages (139 in controls 2 in designTime, 339 in Graphics, including tests and
such). We should only deprecate the method if it should not be used anymore by
anybody for any reason, in which case we need to replace all
I think SceneBuilder would like this, and I know printing would love it :-)
-phil.
On 7/3/13 7:03 AM, Kevin Rushforth wrote:
+1
This would allow apps to dispense with the following workaround when
taking a snapshot:
// create a dummy scene so layout and CSS will work
new Scene(new Gro
+1
This would allow apps to dispense with the following workaround when
taking a snapshot:
// create a dummy scene so layout and CSS will work
new Scene(new Group(node));
node.shapshot(...)
-- Kevin
David Grieve wrote:
Hi Martin,
With regard to having this work without a Scene…
Thank you David for your insight.
You are right with the use-case for scene-less layoutbounds query, but I
think this is a completely different API, so I'd leave the validate to
support only the cases where a Scene is present.
-Martin
On 07/03/2013 03:23 PM, David Grieve wrote:
Hi Martin,
W
Hi Martin,
With regard to having this work without a Scene…
I think having a method that would layout a node without the node actually
having to be part of the scene-graph would be _very_ useful. Often times,
developers will do the show-hide trick or add-remove trick to get a node's
bounds be
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
44 matches
Mail list logo
