Fix get_engine options agreement#303
Conversation
|
I am a bit unsure about this. The reason is that "auto" is supposed to mean: pick a reasonable default. The trouble is that "reasonable" is quite ambiguous. Maybe the solution would be to add more unambiguous backends -- say an "offscreen" backend or a "ui" backend? Are you thinking that "auto" is just another name for "ui"? Thoughts? |
|
Indeed "reasonable" is not well defined. So it would be helpful to check some case studies. For example: should the reasonable engine on the last line be an Engine (i.e. on screen) and not an OffScreenEngine? |
|
Hmm, I think if offscreen is false, it should pop-up a view but then again, since there is already an off screen engine ready, technically it could use the same off screen engine. OK, so if offscreen is not set, one should not get an offscreen engine. So in your case, one should get a non-offscreen engine depending on the backend. Is this what happens with your PR? |
Indeed this PR is aiming at this. |
Fix get_engine options agreement
offscreenon, gets an OffScreenEngine created and registered, then switchesoffscreenoff again,get_enginewould still returnOffScreenEngineif `backend=="auto". This doesn't make sense (or should it?). So here I implemented a fix for this special case.get_engineis made more robust by usingassertIsinstead ofassertIsInstanceas NullEngine, EnvisageEngine, OffScreenEngine are all subclass of Engine (so only L40 of the mastertest_engine_manager.pyis dubious). But this is a crucial distinction for the new test added in this PR