Expose additional mouse::Interaction cursors
#2551
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Also maybe we have to wait until the |
|
I also would love to add another cursor, being the I'm porting a Conky like project of mine, from GTK to Iced. Iced feels like a more direct toolkit than using the GTK Rust wrapper. The use case is when I hover my cursor over some labels, I show a Since this is a dashboard, the UI should be kept very simple. So I felt like a cursor was the best way to go. |
hecrj
approved these changes
Sep 13, 2024
hecrj
changed the title
mouse::Interaction cursors
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a few more common mouse interaction cursors to
interaction.rs, namely:Since the
Cellselector is a bit niche, here is a screenshot of what it looks like in Excel. My use case is building a spreadsheet app, so users would expect this cursor to be there.I take it
ZoomOutandMoveare pretty standard and need no specific use case.There's an argument to be made that
icedcould just expose all of the cursors fromwinitand let the users figure it out, even if some of the cursors are very unusual. I'm not making that argument so I have only added those cursors whose inclusion was more immediately defensible IMHO but open to suggestions.Admittedly I have not tested the specific resizing cursors because I'm on MacOS and they don't work, but naturally everything compiles and runs fine. They just default to the standard cursor, but I tested other cursors from
winitand they were fine (including, for example, sizing westward, which is not in this PR) so I'm confident nothing's wrong with the code per se.FYI this
winitissue is being tracked here: rust-windowing/winit#3724