[DavidBJaffe]

Add example illustrating:

1. Display a tooltip message in a Canvas.
2. Make a Canvas change based on pushing a Button.
3. Show that a Canvas is stil performant even when it has a large number of objects in it.

[TheRittler]

@13r0ck I saw, that here the author included the Cargo.lock file and a gitignore file. How do you want to proceed here? Include both files or leave them out?

I didn't include one in #1 and prefer leaving them out since

1. the lock file is generated anyway
2. if anyone wants to use an example, this person might want to have it's own gitignore file. And since examples are not executed and re-committed frequently, IMO having no gitignore is not a problem and keeps the repo clean.

[13r0ck]

@TheRittler yep, I agree. I still like the idea of having a .gitignore just to help prevent people from accidentally committing their /target, what do you think about having one gitignore at the root for the repo?

[TheRittler]

@TheRittler yep, I agree. I still like the idea of having a .gitignore just to help prevent people from accidentally committing their /target, what do you think about having one gitignore at the root for the repo?

I'd like that!

[DavidBJaffe]

The reason I included Cargo.lock is that theoretically, dependent crates could be updated and somehow break the example. But I totally defer to you all. Please just let me know!

[13r0ck]

@DavidBJaffe That is a good point. I do lean towards removing cargo.lock for neatness, but also I would rather have an example fail to run in the repo, so that the issue can be fixed as "upstream" as possible, rather than someone not being able to reproduce the functionality in their project because of a slightly different cargo.lock. What do you think?

[DavidBJaffe]

Ah interesting, I hadn't thought of that! So are we in agreement to kill Cargo.lock and .gitignore?

[13r0ck]

Yep. I have a few small changes to request in your two PRs that I will get to late this afternoon/tomorrow morning. Then we can get your PRs merged!