vsgQt::Viewer constructor default behavior changed, no longer automatically sets up QtTimer for rendering

[robertosfield]

Hi All,

I've been working on client VSG/Qt application this week and hit upon a problem with vsgQt::Viewer by default setting up it's own QTimer to do continuous rendering - if the application already has it's own mechanism for controlling rendering of the frame you end up with two, potentially inconsistent mechanism that are doing a redraw of the frame.

I toyed with a few different approaches for resolve this conflict and ended up deciding that having vsgQt::Viewer by default setting up a QTimer to call the vsgQt::Viewer::render() method is poor choice for user controlability. Rather than have the timer be assigned by default I feels this is better done explicitly by the application.

The changes I went for were the to add a msecTimerInerval parameter to vsgQt::Viewer constructor that defaults to 0, and if an application passes in a value greater than zero then it calls the vsgQt:Viewer::setInterval(msecTimerInterval) which then sets up the QTimer for the application , or the application can create the Viewer and then call setInterval(..) directly.

The changes checked into vsgQt master should illustrate this:

https://github.com/vsg-dev/vsgQt/pull/36/files

The changes are pretty minor, but as the default behavior is now different it's worth being aware of incase your VSG/Qt application now doesn't rendering continously like it once did. If you hit up against this just pass in something like 8 (ms) to the vsgQt::Viewer constructor or call Viewer::setInterval(8).

To make it possible to check for these changes a compile time I have bumped the vsgQt version to 0.3.0 and created a release for it:

https://github.com/vsg-dev/vsgQt/releases/tag/v0.3.0