On Fri, Mar 4, 2011 at 4:44 AM, Greg Brown <[email protected]> wrote:
> I had a similar thought. Unfortunately, making a Window focusable will > break apps that currently call window.requestFocus() to focus the content > component. Those apps would have to change to call > window.getContent().requestFocus(). That's not out of the question, but > seems wrong - container focusability was added primarily to support > composite components like Spinner rather than layout or navigation > components, or windows. > Would it be reasonable for Window#requestFocus to attempt to set focus to its child, and if that failed, to take it itself? I'd be surprised if this is actually a common issue in practice, though. In > most applications, some component generally has the focus, so key strokes > will be propagated to the window. What is the use case for sending key > strokes to a window when nothing is focused? How would we know which window > to send them to? > In the case of top-level windows, it's pretty clear where to send them. The use case is that there are plenty of useful windows that don't contain check boxes, text inputs, or other obviously focusable components. And even for windows that do have them, I might not want to explicitly focus one of them when I open a window, lest a keystroke have unintended action (e.g., I want the user to explicitly click on a checkbox, or at least type a Tab to tell me they're using keyboard navigation and to focus the first component).
