Manuel Unterhofer
02/17/2023, 2:58 PMvide
02/17/2023, 6:05 PMRuckus
02/17/2023, 6:46 PMManuel Unterhofer
02/18/2023, 7:18 AMRuckus
02/23/2023, 4:55 PMThe problem is that there might be special key handlers...What do you mean by this? If you're talking about a list view that you create, you could just extract the handlers into functions and call them from both the list or the input depending on who has focus. If you're talking about arbitrary composables, that's a whole different can of worms. A workaround I've used in other UI toolkits is to grab a reference to the target node (e.g. the list) and call it's event handler directly passing in either the event captured from the input, or a new event I constructed for more fine grained control. However, considering UI nodes are functions instead of objects in Compose, I'm not sure what the correct way to go about doing that is.
Manuel Unterhofer
02/23/2023, 4:56 PMRuckus
02/23/2023, 4:59 PMManuel Unterhofer
02/23/2023, 4:59 PMRuckus
02/23/2023, 5:00 PMManuel Unterhofer
02/23/2023, 5:00 PMRuckus
02/23/2023, 5:06 PMSiblings have an orderThat's my point, the order often isn't as clear as it may seem. The obvious example is whatever order they are defined in the code, but that might not line up with many users expectations, such as what is visible on the screen, or where elements appear on the screen. But all of this is arguably beside the point, as the fundamental idea of having multiple elements focused is problematic, as that kind of defeats the whole point of focus in the first place, and can be fairly easily worked around using the methods I mentioned earlier, without having to answer any of these questions.
Manuel Unterhofer
02/23/2023, 5:08 PMRuckus
02/23/2023, 5:09 PMManuel Unterhofer
02/23/2023, 5:10 PMRuckus
02/23/2023, 5:12 PMbut that doesn’t compose ... I want to be able to plug any component into a list entry and the component should be able to query the focus API just like any otherI don't understand what you mean by "query the focus API just like any other". I think you may be conflating the focus with the selection, but I could be wrong. Can you elaborate?
Manuel Unterhofer
02/23/2023, 5:13 PMRuckus
02/23/2023, 5:14 PMNone of them actually need to be active at the same timeYes, that's exactly my point.
Manuel Unterhofer
02/23/2023, 5:14 PMRuckus
02/23/2023, 5:16 PMManuel Unterhofer
02/23/2023, 5:17 PMRuckus
02/23/2023, 5:20 PMManuel Unterhofer
02/23/2023, 5:20 PMRuckus
02/23/2023, 5:22 PMManuel Unterhofer
02/23/2023, 5:30 PMRuckus
02/23/2023, 5:31 PMManuel Unterhofer
02/23/2023, 5:33 PMRuckus
02/23/2023, 5:38 PMMultiFocus
composable that can handle any such use cases inside it and dispatch accordingly. You would need to come up with a good way of representing to the user what elements are and are not in focus, as well as how to add or remove elements (or just assume everything in it is always focused I guess), but it could be cool. Instead of the completion in an IDE (which I think still fits into the tightly coupled world), this would be more akin to multiple cursors in an IDE.Manuel Unterhofer
02/23/2023, 5:50 PM