Week 4

What I Worked On

All of the work I did this week once again focused on refactoring existing plugin classes to work with the freeseer framework's Config class, and can be seen here (https://github.com/Freeseer/freeseer/pull/589). The overview of items I worked on is as follows:

• Finished with the audiomixer package by refactoring the MultiAudio plugin.
• Refactored all of the videoinput plugins: DesktopLinuxSrc, FirewireSrc, UsbSrc, and VideoTestSrc.
• Made the new ChoiceOptionFunction class a bit more robust in handling cases where the choice function returns no options.
• Spent quite a bit of time debugging an issue related to plugins not finding any compatible devices (described below) and the Config class' strong objections to such cases.

Issues 

In Freeseer's master branch, plugin configurations are persisted to file (plugin.conf) when the user makes any changes to the plugin's settings from inside the configuration windows, or when the user simply opens that plugin's configuration widget even if no changes are made. I wanted to fully duplicate this behavior in my branch with the new Config classes, but ran into an interesting issue while working on the firewire plugin. 

My laptop has no firewire, so naturally initializing the firewire plugin produces no selectable options for video. While the master branch handles this particular case by creating a default but fictional "/dev/fw1" entry to save in the plugin.conf file, the Config files I am working with in my branch are much stricter. Saving the plugin settings to file with a missing configuration option throws an OptionValueNotSetError. Saving to file with a fictional default value (like on master branch) throws an InvalidOptionValueError.

This same issue is causing some failures on the Travis CI tests, as some of the other plugins (PulseAudioSrc and UsbSrc) that are now using the Config files are also not detecting any compatible devices available on the Travis test VM. Since no compatible device is available, the Config file can't have a real value for that particular configuration option, and so throws the OptionValueNotSetError when the plugin's initialization code tries to read the device.

What I'll be Working On

I'll first revisit the issue I described above: I was considering extending the Options code to have an Options.NoneAvailable type as well as the existing Options.NotSpecified. This will let us explicitly record the fact that there are no compatible devices detected for a configuration. 

I'll need to review the plugins' init methods and make sure they can handle the cases where some needed option ends up being NoneAvailable. It's possible we should also alert the user when some chosen plugin finds no compatible devices, since the current code doesn't do that.

I still need to refactor the PIP (picture-in-picture), and the VideoPassthrough video plugins.

Finally, I need to start writing up a spec for the configuration system's REST api, although this task may get pushed back a week since I'm still dealing with the above plugin issues this week.