Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve cursor api #1368

Closed
jneem opened this issue Nov 3, 2020 · 3 comments
Closed

Improve cursor api #1368

jneem opened this issue Nov 3, 2020 · 3 comments
Labels
enhancement adds or requests a new feature

Comments

@jneem
Copy link
Collaborator

jneem commented Nov 3, 2020

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.

@cmyr cmyr added the enhancement adds or requests a new feature label Nov 3, 2020
@JAicewizard
Copy link
Contributor

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.

@jneem
Copy link
Collaborator Author

jneem commented Nov 27, 2020

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.

@jneem
Copy link
Collaborator Author

jneem commented Dec 21, 2020

Closed by #1433

@jneem jneem closed this as completed Dec 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement adds or requests a new feature
Projects
None yet
Development

No branches or pull requests

3 participants