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 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.
On Jul 8, 2013, at 1:01 PM, Richard Bair <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> 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> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>>
>
