Console refactoring / improvements / bug fixes

❓ Questions and Help

Following some work from @shanaxel42 in #784 to better manage our console resources it is worth raising some additional questions around the expected behavior of the console in interactive environments like when napari is launched from IPython or Jupyter.

Right now if launched from IPython the button to open the console is there but pressing it does nothing and the console is not created. I think we should remove the button and stick with the principle that if launching from IPython you do not need a built-in console in napari. How does @jni feel about this?

Right now if launched from Jupyter we actually create a console and sync it with the jupyter notebook, but there is a weird issue where you now have to press shift-enter in the console to get things to execute. This is very confusing I think, and I’m not sure that we should provide a console in this case either. I propose we remove both the console and the console button when launching from jupyter.

Finally when launching from a script that contains two napari.Viewer() like calls strange things happen where both consoles get connected to the same kernal, typing in either though only makes output appear in the 2nd created one and the viewer variable gets overwritten so only the 2nd create Viewer is referred too. This is very strange, but I’m not sure how to improve it and very open to suggestions

In general there also might be an opportunity for @shanaxel42 to remove some unneeded code from QtConsole depending on how we resolve these questions, and potentially come up with a cleaner fix for #618 at the same time

[tlambert03]

for what it’s worth, I agree with all these things. no need for icon when launching from ipython or jupyter (or at the very least no shift-enter if possible when launching from jupyter… remove altogether if not possible). and don’t clober viewer variable, but do something like create a second variable name if viewer is in globals() and emit a warning…

[sofroniewn]

The remaining work to still address in this issue is now captured by #1530 and #1531 and this issue can be closed