grabFrame/idleMovie deprecation #484

Closed
kylemcdonald opened this Issue Feb 20, 2011 · 14 comments

Projects

None yet

3 participants

@kylemcdonald
Contributor

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().

@ofZach
Contributor
ofZach commented Feb 20, 2011

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?"

@kylemcdonald
Contributor

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.

@bilderbuchi
Member

this could be handled the same way as the ofxVec/ofVec transition, isn't it?

@kylemcdonald
Contributor

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.

@bilderbuchi
Member

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!

http://stackoverflow.com/questions/295120/c-mark-as-deprecated

"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.

@kylemcdonald
Contributor

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.

@bilderbuchi
Member

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.

@bilderbuchi
Member

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?

@kylemcdonald
Contributor

looks like it does, but i also have 0 llvm experience :)

@bilderbuchi
Member

fixing this would also fix #676
676 also indicates that #warning actually doesn't compile with MSVC, which would make the issue more serious.

@bilderbuchi
Member

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.

@bilderbuchi bilderbuchi was assigned Apr 24, 2012
@bilderbuchi
Member

Please continue a deprecation implementation discussion in #1216, don't want to derail this further.

@bilderbuchi
Member

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...

@kylemcdonald
Contributor

i say go for it :)

idleFrame() was wrong, i meant idleMovie()

@bilderbuchi bilderbuchi added a commit to bilderbuchi/openFrameworks that referenced this issue Jul 27, 2012
@bilderbuchi bilderbuchi Deprecate ofVideoPlayer::idleMovie().
Add changelog entry. Update examples. Test deprecation triggering and proper operation on opencvExample. Relevant issue: #484
855f9e2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment