Add screenshot function to canvas
This is a long overdue implementation of https://github.com/smathot/OpenSesame/issues/318. I've followed your instructions in that issue as close as I could. I tested the functionality in a simple experiment and it seems to work with all backends. Yet, I still have some reservations, and I would like to hear your thoughts on the following points:
- The xpyriment and psycho backend only allow to take a screenshot of the currently active back buffer, so they need to redraw the canvas each time before a screenshot is created. This is done by mimicking the
show()function, but ommitting the flip or update action of the display, so the back buffer is never drawn to the screen. This feels quite 'hacky', but I can't think of a better solution, even after endlessly searching for alternatives. - Related to the previous point, I'm not sure if I need to clear, or otherwise clean, the back buffer after it has been drawn to by the screenshot function. My preliminary tests show no problems if you skip this step, but I reckon there are situations in which 'residual' elements.
- I think we should guard for permission errors and the like when trying to create subfolders with
os.makedirs()(https://github.com/smathot/OpenSesame/commit/4cbc7cea8c57ff0766aa14d77133fc7f9a82370b#diff-f2dce170dbe3213bf48dee492214299eR503), but I don't know what's the best way to do this that fits OpenSesame. Should I catch IOErrors or OSErrors here and raise an osexception instead? How do I make sure the relevant traceback is shown then? Any advice on the best way to go at this? - I was planning on writing unit tests for this function, but then of course I realised we are working with graphical elements again here, which always makes it more difficult. Do you have any ideas on how to we could best approach this, or if unit testing the screenshot function is really necessary?
Thanks, I'll take a look at it soon!
This looks good in principle, but because it introduces new functionality I'll postpone merging (and real checking) until 3.3.0.
I don't know if you ever would want to merge this, but otherwise we can close this PR?
This has gone off the rader, bit it's still not a bad idea, so I'll leave it open :-)
Closing due to inactivity.