Make full screen optional

[JohnGriffiths]

Following idea from @pellet - this is a tiny PR to make the use of full screen optional.

This is particularly useful for debugging, because it allows to both see and switch to a terminal while the psychopy window is up, and allows to retain control via the terminal upon a crash, for e.g. to view the stack trace or enter a debugger.

This is done by providing a use_fullscr Bool argument in the experiment init, and setting it to a modifiable attribute of the Experiment object.

A modifiable attribute is also added for window_size, although this is not added as an input argument upon init.

I think it would probably be a good idea to move some other parameters such as the monitor type into modifiable object attributes in the future also.

Example usage:

from eegnb.experiments.visual_n170.n170 import VisualN170
expt = VisualN170(duration=10, use_fullscr = False)
exp.window_size = [1200,500]
exp.run()

[pellet]

Looks good @JohnGriffiths.

I previously achieved this by passing in the entire window object like so:
window: Union[visual.Window, rift.Rift] = None link - this allowed for the monitor or vr display to be initialized with the correct parameters upon creation.
Downside to this approach is that it is tightly coupled to PsychoPy and relies on the user to learn how to create the PsychoPy/PsychXR objects.

A third option could be to encapsulate the window settings in a new EEG-ExPy window class which could be passed in to the BaseExperiment constructor or accessed via exp.window.use_fullscr for example. Something similar could be done for the trial parameters to keep them all separately in one place and reduce the number of parameters passed directly into the BaseExperiment constructor. Downside would be needing to refactor the way the BaseExperiment is currently initialized in all of the actual Experiment sub-classes.

These are just some ideas for further iterations, I think your PR looks good to merge.

[pellet]

The size was previously [1600,900]

[JohnGriffiths]

I think it's fine.

[JohnGriffiths]

thanks Ben.

As discussed, I think these ideas are all good ones to consider as we go, in the context of concrete use cases and improvements.

For now the current PR is a very simple and concrete one, so let's keep it as-is.

Merging.