Hi Werner,
I didn't realize you are writing an API as opposed to an application
where you'd have control over your controls :-)
In this case I indeed don't see any straightforward solution right now.
Perhaps it might make sense for us to mark the "skin/control-internal"
nodes somehow. It may be useful in any situation where user traverses
the scenegraph and doesn't want to mess with the control implementation.
Jonathan, what do you think?
Pavel
On 28.5.2013 18:42, Werner Lehmann wrote:
Hi Pavel,
I like marking those controls with a property. UserData I would leave
for external usage. I think it is a property anyway.
The main problem here is that this is a container for arbitrary nodes,
including other containers. I can watch for changes in my list of
immediate children but won't know about new children added to those. I
can watch the subgraph with many listeners for
Parent.childrenUnmodifiable and Parent.parent but still cannot
generically know if a child node belongs to a skin or not: Pane
children would be marked, ScrollPane children should not be marked.
The other option, adding all kinds of listeners directly on the nested
child controls, has the same problem: I don't know when somebody adds
a label to a vbox contained in my control so I cannot add listeners to
the label.
Seems as if there is just no way of having centralized mouse/key/drag
event filters for all (nested) non-skin child nodes. Unless I
introduce an explicit observable list of those nodes. This would be
redundant and I cannot force users to actually keep it up-to-date.
Maybe I require a marker interface or annotation on child nodes
instead. Forcing users to subclass each label, textfield, etc. I would
have preferred to keep this as unobtrusive and versatile as possible.
Werner
On 27.05.2013 16:25, Pavel Safrata wrote:
Hi Werner,
so you need to distinguish "your" controls from "system" controls. Can
you mark your controls somehow? For instance by node property or style
or perhaps even userData or id?
Regards,
Pavel
