Enhance interface to allow reading from VectorOf*

[whitequark]

No description provided.

[kali]

Hi ! Glad to get some help with this nightmare.

I just found myself with a lot of time in my hands, so I started a refactoring of the binding generators. Good news is, I'm working on them, and will get us a huge lot of additional coverage. Bad news is, I can't merge this PR as is.

I've pushed my current working branch here. https://github.com/kali/opencv-rust/tree/wip Don't try it yet, it does not even compile.

I have no issue with the include path inclusion. As a matter of fact, upgrading my mac to the latest osx beta did similar breakage on my side.

As for the VectorOf item access, I went a different way:
0602a9a#diff-27763819753470636f5b15e6da27ac42R644

It allows borrowing access, and you can still call to_vec() on the slice. What do you think ?

Also, that specific commit should not be too broken, if you want to try.

So basically, I suggest we wait till I get somewhere and see what we still need to merge from this PR.

Finally, could you tell me what part of opencv you're using ? It would be nice to get a few more runnable programs in examples because that's basically all I have to test. The face detection example lead me to this huge refactoring when I saw I could not draw a rectangle... When I'll get this one to work, I'll probably move with new examples around features, knn, flann and homography because this is the part I actually know and need. So if you're using a widely different area of the library, even porting a trivial but relevant c++ example to rust could help a lot. Or at least tell me about it :)

[whitequark]

Bad news is, I can't merge this PR as is.

That's OK. I am not very fond of it myself. I took the easy route out and piled more stuff on top of it, instead of refactoring everything properly, and given that we would have collided, it's for the better.

It allows borrowing access, and you can still call to_vec() on the slice. What do you think ?

That's perfectly fine. I didn't know std::vector::data() exists, or I'd do the same.

Finally, could you tell me what part of opencv you're using ?

There's the face detection example, but I don't actually need it, I just wanted to play with it. The thing that I do need is calcOpticalFlowPyrLK and estimateRigidTransform, which... checks... would work as they currently are anyway.

Let me file another issue with my improvement wishlist.