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

Improved the select example. #501

Merged
merged 1 commit into from
Sep 21, 2020
Merged

Improved the select example. #501

merged 1 commit into from
Sep 21, 2020

Conversation

LunarEclipse363
Copy link
Contributor

Introduction

This PR is an effect of my initial confusion with the intended way of handling Callbacks, and aims to help prevent that from happening to others in future.

Story time!

I wanted to add custom keybindings to a SelectView, so I looked through the examples and found the select example which looked like exactly what I needed. After replicating the OnEventView wrapper part of the code, the keybindings worked as far as navigating the SelectView went, but I noticed all the callbacks set with SelectView.on_select() were ignored with the custom keybindings but worked with the default arrow ones.
I started reading into the documentation, and noticed the SelectView.select_up() method returned a Callback, and the documentation said it should be ran on the Cursive. I couldn't figure out how to get a reference to Cursive inside the closure in OnEventView.on_event_inner() to run it like the documentation example has shown (something along the lines of callback(&mut siv) ), so I tried using OnEventView.on_event(), then getting a referece to the SelectView by name, and using Cursive.cb_sink() to send the Callbacks but apparently they weren't Sync so that didn't work out.

Not until having found #433 and this comment in particular did I realize that I should look at the documentation of EventResult, which, in turn, made me realize that I can just pass the Callback inside the EventResult.

Summary

I thought it would be a good idea to create this small PR to hopefully help other Cursive beginners be less confused :)
It effectively doesn't change anything in this example as far as functionality goes, but it helps bring attention to this important way of handling Callbacks.

Now the `OnEventView.on_pre_event_inner()` calls return
`Some(EventResult::Consumed(Some(Callback)))` instead of
`Some(EventResult::Consumed(None))`.
This follows the guidelines from documentation of methods returning a
`Callback`, which say that it should be ran on the `Cursive`.
While in this example this doesn't make a difference, the previous
version created confusion for new users who might not realize you can
pass the `Callback`s to the `Cursive` this way.
@gyscos
Copy link
Owner

gyscos commented Sep 21, 2020

Hi, and thanks for the PR!
Indeed, it's probably best practice to always forward the event result here, even if the example itself does not make use of it.

@gyscos gyscos merged commit 7b579a7 into gyscos:main Sep 21, 2020
TianyiShi2001 pushed a commit to TianyiShi2001/cursive that referenced this pull request Oct 9, 2020
Now the `OnEventView.on_pre_event_inner()` calls return
`Some(EventResult::Consumed(Some(Callback)))` instead of
`Some(EventResult::Consumed(None))`.
This follows the guidelines from documentation of methods returning a
`Callback`, which say that it should be ran on the `Cursive`.
While in this example this doesn't make a difference, the previous
version created confusion for new users who might not realize you can
pass the `Callback`s to the `Cursive` this way.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants