it would be nice to start deprecating grabFrame() and idleMovie() (but maybe wait a couple years to actually remove them) , and change the examples to only use update() and isFrameNew().
I am not a fan of removing these at the moment to keep backwards compatibility. There's alot of code in books and in the world that use the older functions.
I just think we should provide good documentation for those functions -- at the moment, the documentation doesn't prioritize the update, and I think it would be about adding some lines there. Right now, it just says update() calls grabFrame(). We could add some lines that these are legacy, and people should use update.
I am also very much against bool update() as with some functions bool loadImage() it's clear, this failed or didn't fail. but there instances w/ objects like ofVideoPlayer::update() that stuff is happening that is not true / false, like giving quicktime time to think. I don't think it makes as much sense to return a bool here, as I would read that as the act of updating failed, not "is there a new frame?"
yeah, let's definitely prioritize the documentation + use of update() in the examples; and in the header files just say that grabFrame() and idleFrame() are 'legacy' -- that's all i meant by 'deprecate'.
i re-read my issue and agree with what you said about bool update() being a bad idea, so i removed that.
this could be handled the same way as the ofxVec/ofVec transition, isn't it?
but ofxVec gives you a warning because the warning is in the header file. i'm not sure how you would mark a single method as deprecated and cause a warning. but if that's possible, that would be ideal.
Yes it is possible to mark single functions deprecated. with a little ifdef trickery, it's even cross-platform.
What's best, apparently this only warns when the function is used, not if it's just declared/defined. Sounds like just wha we need!
"The deprecated attribute results in a warning if the function is used anywhere in the source file. This is useful when identifying functions that are expected to be removed in a future version of a program. The warning also includes the location of the declaration of the deprecated function, to enable users to easily find further information about why the function is deprecated, or what they should do instead. Note that the warnings only occurs for uses"
There is also a `#pragma deprecated' macro. I'm not sure which one would be better.
if i read that correctly, pragma deprecated is MSVC only. the ifdef is necessary to have a cross-compiler solution. i think we also need to figure out what LLVM uses to have a completely cross-compiler deprecation macro.
i checked to see if poco indicates deprecation in a cross-platform way, but it just indicates deprecation in the documentation.
OK. the ifdef is no problem, since the finished cross-platform code is posted in the answer to the SO question I linked to, at least for gcc and msvc.
LLVM - no idea.
I have pretty much no knowledge about LLVM, but (this)[http://clang.llvm.org/docs/LanguageExtensions.html#deprecated] indicates to me that LLVM uses the same mechanism as gcc. Correct?
looks like it does, but i also have 0 llvm experience :)
fixing this would also fix #676
676 also indicates that #warning actually doesn't compile with MSVC, which would make the issue more serious.
Because the question turned up during the IRC session: I think it's possible to deprecate ofEvent vs. ofEvent() (changed in 68a9805) .
According to http://ohse.de/uwe/articles/gcc-attributes.html#func-deprecated, "The `deprecated' attribute can also be used for variables and types", so for gcc this should work. The visual studio pages documentation also indicates that this should work.
Does anyone have input regarding LLVM?
Is there still interest in a proper deprecation mechanism? If yes I could have a go at it, but I'll be needing other people for testing on platforms/configs I don't have access to.
Please continue a deprecation implementation discussion in #1216, don't want to derail this further.
OK, so we have a proper deprecation mechanism now. This means we can deprecate grabFrame().
Affected examples are meshFromCamera, opencvExample, multiTextureShaderExample, lutFilterExample, polylineBlobsExample, asciiVideo, videoGrabberExample. Do we simply replace calls of grabFrame() by calls of update()?
Has idleFrame already been kicked out? I can't find any mention anywhere in the repo...
i say go for it :)
idleFrame() was wrong, i meant idleMovie()
Add changelog entry. Update examples. Test deprecation triggering and proper operation on opencvExample. Relevant issue: #484
Deprecate ofVideoGrabber::grabFrame(). Update affected examples. Closes
Tested on ofVideoGrabberExample.