I have some questions related to the spec. I think some of this has been addressed in the PR but not in the documentation.
- The spec discusses the focused property but what should happen with the focusVisible and focusWithin flags? I don’t think it’s a good idea to have these properties and related CSS pseudo-classes be the same across a node and all of its delegates. That would dictate that all of the nodes show their focus indicators in unison. - How should the accessible attributes be set up in the focus owner and delegate(s)? Can the accessibility frameworks deal with multi-level delegate chains? - In a delegate chain which node responds to input method requests? We can pass events through multiple nodes but there can only be one IM caret. Keep in mind that in macOS the caret is used for more than Asian language input. When the user toggles Caps Lock or changes the keyboard layout the system briefly displays an indicator near the caret. (The spec could say that delegating focus also delegates IM events and input request processing and leave it at that. The behavior is easier to implement than to describe.) - This spec goes through some trouble to ensure that the target of a KeyEvent is the ComboBox/Spinner and not its TextField. But we don’t do that for mouse events. When clicking on a ComboBox (or Button or whatever) the event’s target is set to whatever object the user clicked on even if it’s an undocumented piece in the control’s skin. I would like to see a discussion on why we’re trying to hide the use of composition here when we don’t elsewhere. To satisfy my curiosity I briefly looked at how a few other toolkits do this. On macOS a ComboBox is a subclass of a TextField. Internally it’s using composition but that’s not visible at the API level. GTK 3.0 uses a similar class structure (no idea what it’s doing under the hood). JavaFX does this in some cases e.g. a Button does not contain a label but is derived from Labeled. In Windows Presentation Foundation a ComboBox is a composite control but it doesn’t create a complicated multi-focus state in the scene graph. When an editable ComboBox is given focus it transfers focus to its TextBox. Only the TextBox is considered focused by the system (in JavaFX terms it is the focus owner and is the only control with the focused property set). When a key event is processed the target is the ComboBox but there’s an additional field in the event args so you can easily discover that the original target was the TextBox. WPF does this for all events e.g. if you click on a ComboBox the event target is set to the ComboBox but the original target is set to whatever sub-element you clicked on. Martin > On Feb 10, 2025, at 5:12 AM, Martin Fox <martinfox...@gmail.com> wrote: > > >> I guess that's just the way I made it work. Implementing this in >> Control is not something I've thought about a lot. > > It was really my thought experiment to begin with. Not sure it’s even > possible to do this without involving Scene and Scene knows nothing about > Controls. Don’t give it another thought. > >> I see no reason why a control shouldn't dynamically change what it >> returns from getFocusDelegate(). However, there's no notification >> mechanism that would indicate when something has changed. Would you >> need something like Scene.focusOwner(), but instead of containing the >> outermost focused node (like ComboBox), it contains the last node in >> the current delegation chain (TextField)? > > > I’ll go think about the implementation and get back to you. For now I just > needed to clarify that a Node’s focus delegate can change dynamically and > that there might be a chain of delegates (which is the tricky part).
