Responding to Nir's questions in this thread. > I'd like to understand the focus and event handling problem better. If I have > a focused TextField, all key events go to it. If I have a Spinner, which is a > TextField with 2 Buttons, it is focused as a single unit and consumes key > events whether they are aimed at the text field or the buttons (I assume the > buttons handle arrow up/down keys?). If I have a ClolorPicker, it is not > focused as a single unit - it has sliders, buttons, text fields and other > things, which can be focused individually. > > What I'm trying to find out is what is "the primitive" in the focus/event > handling plan. A TextField and a Spinner are treated as primitives, but a > ColorPicker and a DatePicker are not. Where does the line pass? If I'm a > controls author, can I create a Spinner that allows focusing/event-handling > the text field and the buttons separately, like ColorPicker allows? In this > case, Spinner is not a "primitive" control.
I would say that the line is wherever you draw it. Some controls are monoliths, some are composites, some are a mixture of both. Think of Button: it has a user-configurable `graphic` property that accepts any Node, and both are independently focusable. You can imagine creating a control that is mostly a monolith (like Spinner), but has a "hole" that can be filled with any content by users. The proposed focus delegation API allows you to do any of that.
