-
Notifications
You must be signed in to change notification settings - Fork 4
Add descriptive comments to camera device and properties headers #35
Conversation
This is what I added so far. Still in draft, so need to take a look yet, but wanted to make sure something was visible. |
@aliddell: While this is not complete, I cleaned up the header comments I added, so this should be ready for review. I'm not completely confident on all the definitions here (and deliberately used non-confident language in those cases), so if you can check them against your understanding, and make corrections and edits, that would be great! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This lgtm
/// @details This is not guaranteed to wait or block until any pending | ||
/// frames have been acquired or the camera is actually stopped. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is important context. Is this due to a particular implementation, like Spinnaker, or was this always part of the design?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I wrote this because Spinnaker gave no solid guarantees about its behavior for ICameraBase::EndAcquisition
, which was surprising/unsettling to me, so I reflected the uncertainty here. We could just omit this. Or if we think this should always wait/block, then we should ensure that all implementations (including Spinnaker) do so if possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reader needs to know what they need to guarantee in an implementation. In this case, the camera should be signaled to stop, may block, and should be restartable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated the details here to reflect the comment directly above.
I think this is probably good to merge now unless there are objections from @nclack ? |
This adds some missing header doc comments and updates other to clarify what some struct members are more exactly.
Closes #27