Open-ended design question: should IViewDrawable be able to support any kind of input, and if so, what kinds and how?
This came up when one new user was trying to implement a tooltip property and click event on a HUD element. Other Stardew mods like UI Info Suite do have clickable and/or hoverable HUDs, so this isn't a totally esoteric use case. However, Stardew UI doesn't handle it; drawables only draw, because the entire normal event loop is part of IClickableMenu.
It's not possible to have every aspect of a view "just work" in drawable mode, not with any amount of effort, because some attributes and events are just incoherent. Focus and focusability are an obvious example; button events are another. Keyboard input is theoretically possible but probably extremely difficult and error prone. Any widget that tries to open an overlay is going to have a bad time. The list goes on.
Another issue is that the position isn't known by the drawable itself, only the layout; callers decide the draw position in the Draw method. However, that's potentially solved by either accepting a position argument in whatever method theoretically drives the limited event loop, or just using the last draw position. (User input logically and by definition lags the drawing by at least a frame, since the user has to respond to what he is seeing, although putting this assumption in code could very well run into unexpected issues since it's not consistent programmatically).
In spite of all the issues, there might be a use case for very limited input, specifically mouse input, hover and click related.
If we do this, need to provide clear errors/warnings in the console for when views do things that aren't supported in drawable mode: non-pointer events, properties that don't do anything (focusable etc.), attempts to open an overlay without a menu host (or open a dummy menu underneath it to compensate), and so on. The work would not be simply adding an API method to drive a pointer event loop, it would be adding all the sanity checking to other parts of the framework, knowing what the "host" of a view is actually capable of and responding accordingly, which crosses the Framework and goes into the Core Library.
Don't know if this is really truly useful given that the actual use case that prompted this was literally just a single icon that could be clicked on, and the much simpler workaround for that is to just not use StardewUI for the HUD icon itself, only the menu that it subsequently opens. Is there a case for more complex HUD, with multiple distinct hoverable and clickable elements? Don't know - devs probably shouldn't be encouraged to design that way because it's hard to navigate with a gamepad, but right-stick pointer movement is the norm during world interaction so it's not impossible.
All in all, I'd like to understand more about possible use cases before pursuing the feature, but I'm starting the issue and leaving it up as a placeholder to collect any future feedback or ideas, from either myself or API users.
Open-ended design question: should
IViewDrawablebe able to support any kind of input, and if so, what kinds and how?This came up when one new user was trying to implement a
tooltipproperty andclickevent on a HUD element. Other Stardew mods like UI Info Suite do have clickable and/or hoverable HUDs, so this isn't a totally esoteric use case. However, Stardew UI doesn't handle it; drawables only draw, because the entire normal event loop is part ofIClickableMenu.It's not possible to have every aspect of a view "just work" in drawable mode, not with any amount of effort, because some attributes and events are just incoherent. Focus and focusability are an obvious example; button events are another. Keyboard input is theoretically possible but probably extremely difficult and error prone. Any widget that tries to open an overlay is going to have a bad time. The list goes on.
Another issue is that the position isn't known by the drawable itself, only the layout; callers decide the draw position in the
Drawmethod. However, that's potentially solved by either accepting a position argument in whatever method theoretically drives the limited event loop, or just using the last draw position. (User input logically and by definition lags the drawing by at least a frame, since the user has to respond to what he is seeing, although putting this assumption in code could very well run into unexpected issues since it's not consistent programmatically).In spite of all the issues, there might be a use case for very limited input, specifically mouse input, hover and click related.
If we do this, need to provide clear errors/warnings in the console for when views do things that aren't supported in drawable mode: non-pointer events, properties that don't do anything (focusable etc.), attempts to open an overlay without a menu host (or open a dummy menu underneath it to compensate), and so on. The work would not be simply adding an API method to drive a pointer event loop, it would be adding all the sanity checking to other parts of the framework, knowing what the "host" of a view is actually capable of and responding accordingly, which crosses the Framework and goes into the Core Library.
Don't know if this is really truly useful given that the actual use case that prompted this was literally just a single icon that could be clicked on, and the much simpler workaround for that is to just not use StardewUI for the HUD icon itself, only the menu that it subsequently opens. Is there a case for more complex HUD, with multiple distinct hoverable and clickable elements? Don't know - devs probably shouldn't be encouraged to design that way because it's hard to navigate with a gamepad, but right-stick pointer movement is the norm during world interaction so it's not impossible.
All in all, I'd like to understand more about possible use cases before pursuing the feature, but I'm starting the issue and leaving it up as a placeholder to collect any future feedback or ideas, from either myself or API users.