Proposed fix for issue #46

[int3ll3ct]

The way the freshroastsr700 package is designed, there is the ability to speicfy a callback function associated with the freshroastsr700's time_remaining countdown reaching zero. This callback is called from a child process spawned by freshroastsr700.

This has a number of significant design implications for users of freshroastsr700, the major one being, the callback functions you supply will be called from a different process. To do this, Python will make a copy of whatever object is the parent of the callback, at the time the child process is launched. The state of your object's state variables in the callback context are therefore the state they were at at process launch time. These callback functions can only correctly communicate back to the rest of your application via process-safe means. Anything your freshroastsr700 callbacks touch need to be designed to do IPC.

In Openroast, openroast.roaster (a freshroastsr700 instance) sets up callbacks into a Recipe object. These callbacks do not produce the desired behavior because Recipe is not designed for multiprocessing.

To fix issue #46, the Recipe object had to be completely re-factored to store all its information in shared memory, thereby allowing both Openroast and the freshroastsr700's child processes to properly access the Recipe state throughout a roast.

In addition to this, openroast.roaster calls back into openroast.recipe which, in that callback, also then attempted to call back into the RoastTab itself. For similar reasons, this does not work, and to solve this problem, a simple process-safe flag is now set up as the sole communication means from openroast.roaster back into RoastTab. This flag causes an asynchronous refresh of the new recipe step's fan and targetTemp info.

This makes Openroast fully functional (for the base use case...) on Ubuntu 14.04. Tested with Python 3.4 on a Dell XPS 9343.

It would be important to verify that this pull request does not break functionality in the Windows and Mac versions. I am not set up to test that.

[int3ll3ct]

Well, travis build is failing, but I don't see where PyQt5 is installed as part of running the tests, so not sure how to move past this hurdle right now.

[int3ll3ct]

I give up. Getting PyQt5 properly installed on Travis CI is a complete nightmare. Not sure where to go from here.

[int3ll3ct]

I've looked at the TravisCI whitelisted packages for trusty (14.04), and most Qt5-related stuff is not there. python3-qt5 certainly isn't. This is why this travis setup will not work without a great deal of effort.

[betterengineering]

Thanks for putting this together! The unittests for this application are rather underdeveloped (roasting pun intended). It looks like they are only testing instantiation and are not actually running any tests. We can do one of two things. We can remove the tests that require pyqt, since we will definitely know if the main window has been created or not 😊. Or we can remove Travis integration since the tests are not really serving their purpose anyways.

[int3ll3ct]

I suggest we remove the Travis integration, as the result is not CI - it doesn't spit out an installable application nor a deployment, which is what I'd expect out of Travis/Jenkins etc. Since TravisCI can't build PyQt5 apps, based on my research, I suggest we add build scripts for Windows and Mac to the project so that there is a repeatable way to generate installable versions of the app. For Linux, IMO it's sufficient to ask someone to simply perform a development installation (although we could eventually add a .deb packaging script at some point).

I'll add yet another commit that removes the travis file. I'll put in a separate feature request for the build script. I want to turn my attention back to freshroastsr700 for a bit.