You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The cursor API could be friendlier, especially the part where we make people call set_cursor on every frame.
It would be nice if the active cursor could be part of the widget's state (living in the WidgetPod, probably). When a widget sets the cursor, that will be the cursor that gets shown when the widget is hot.
There's one little wrinkle related to multiple widgets setting the cursor. Probably the least confusing policy is for the child widget to "win", but having this work correctly also requires a notion of "unsetting" the cursor. That is, in order to resolve conflicts you need to be able to explicitly say that you don't care what the cursor is anymore.
This is related to #112, although that one's mainly about the druid->druid-shell interaction and this is just about druid's API.
The text was updated successfully, but these errors were encountered:
A quick solution I just thought of, it might not be ideal.
There is one global cursor stack, and a widget can push/pop something on/off this stack. When a widget gains focus it can call ctx.set_cursor(cursor)(push) and when it loses focus it can ctx.unset_cursor()(pop). Whatever is on the top of the stack is the cursor.
I think this stack should go in the window state, that way is it window-specific and the user doesn't have to worry about it.
In #1433, I'm trying out an API will less user-visible state than what you suggested, @JAicewizard. My thinking is that it will be harder for the user to mess up (i.e. no need to match pushes and pops). Let me know what you think.
The cursor API could be friendlier, especially the part where we make people call
set_cursor
on every frame.It would be nice if the active cursor could be part of the widget's state (living in the WidgetPod, probably). When a widget sets the cursor, that will be the cursor that gets shown when the widget is hot.
There's one little wrinkle related to multiple widgets setting the cursor. Probably the least confusing policy is for the child widget to "win", but having this work correctly also requires a notion of "unsetting" the cursor. That is, in order to resolve conflicts you need to be able to explicitly say that you don't care what the cursor is anymore.
This is related to #112, although that one's mainly about the druid->druid-shell interaction and this is just about druid's API.
The text was updated successfully, but these errors were encountered: