Threading and Node.lookup

Philipp Dörfler phdoerfler at
Wed Mar 20 04:59:03 PDT 2013

Oh, turns out I had no idea that CSS selectors can be that complex! Yes, I certainly don't want to replicate this. Might be a good exercise, though.

~ philipp

Am 20.03.2013 um 12:43 schrieb Tom Schindl <tom.schindl at>:

> On 20.03.13 12:27, Philipp Dörfler wrote:
>> So in order to reliably lookup a node, one has to:
>> 1. Create a Scene with that scenegraph in it
>> 2. Attach that Scene to a Stage
>> 3. Show that Stage
>> 4. OR alternatively (does not help always), call this without a Scene, but in Platform.runLater
>> This this a bit too arcane for my taste. I can see that due to limitations one has to create a Scene and place nodes in there. I can't say I'm exceptionally happy with that, but it'll do for now. Those restrictions are probably there for a reason.
>> However - I don't entirely understand why sometimes it is necessary to actually _show_ a Stage with your nodes to have CSS lookups work (As indicated by John. I ran into this, too). Any chance that this might change? I'm not talking about querying CSS attributes unknown to that point. Only thing I want to do are simple lookups.
>> Is it because of Skin and that it is unknown how exactly the scene graph is composed without evaluating all Control's skins, thus creating more nodes which then might in turn have CSS style-classes (or IDs for that matter) assigned? Is this only possibly by showing a stage?
>> Assuming that this is not going to change any time soon: Is it possible to re-invent the wheel, thus manually traversing the scene graph and querying each and every node for it's id and style class and so on or would that need to be attached to a Scene (and thus runLater...) and/or need to be shown, too?
> As long as you are only using simple selectors I think this could work but like I said in my reply the API allows to pass in complex CSS-Selectors (e.g. you can do a query like this "#myId > * > .myclass") and you don't want to replicate something like this, I guess ;-)
> Tom

More information about the openjfx-dev mailing list