Repository: napari/napari

Issue:
Launch of `0.4.0rc0` hangs on mac until matplotlib is installed
## 🐛 Bug

Both @kevinyamauchi and I have now observed that the command line launch of napari from a clean install of `0.4.0rc0` hangs, unless you first install skimage.

See more in [zulip discussion here](https://napari.zulipchat.com/#narrow/stream/215289-release/topic/0.2E4.2E0/near/214723034)

## To Reproduce

Steps to reproduce the behavior:

1. conda create -n napari-test python=3.7
2. conda activate napari-test
3. pip install --pre napari
4. pip install pyqt5==5.14.2
5. napari

When I try to open just the viewer via napari in the command line, I get the logo, but the GUI never opens. However, I installed scikit-image to run some of our examples and after that, I can open via the napari CLI.


## Expected behavior

The sequence above works with the napari 0.3.8

## Environment

- Mac OSX



Discussion:
These are the packages that get installed when I run `pip install scikit-image`, which allows the `napari` CLI to work:

```
Installing collected packages: networkx, cycler, kiwisolver, matplotlib, PyWavelets, scikit-image
```
Okay, just installing matplotlib (`pip install matplotlib`) after installing napari is sufficient to get `napari` CLI to work.

napari info:
```
napari: 0.4.0rc0
Platform: Darwin-18.7.0-x86_64-i386-64bit
Python: 3.7.9 (default, Aug 31 2020, 07:22:35) [Clang 10.0.0 ]
Qt: 5.14.2
PyQt5: 5.14.2
NumPy: 1.19.2
SciPy: 1.5.3
Dask: 2.30.0
VisPy: 0.6.5

GL version: 2.1 INTEL-12.10.22
MAX_TEXTURE_SIZE: 16384

Plugins:
- napari_plugin_engine: 0.1.8
- svg: 0.1.4
```
Ok, nice work `matplotlib` is necessary and sufficient - napari hangs when I uninstall it from my test env
I also tested with `pyside2` and it is the same behavior.
Disable welcome screen fix this 

in:
https://github.com/napari/napari/blob/ac1712617d5e379719cae7d8d1fe6171872c9fba/napari/viewer.py#L108

add `welcome=False` 

magic functions for add layers was a big problem during debugging this... (complicate tracing execution..) 

I have no idea what happens there. 
Maybe delay of its initialization to showEvent may help. 



> magic functions for add layers was a big problem during debugging this... (complicate tracing execution..)

hmm yeah, i can imagine that. I wonder if we want to do runtime generation generate *.py files instead, as mentioned in #1713
maybe it is enough to overwrite docstring using `func_name.__doc__ = docstring from class`. Without generating whole function. 
Ok found it

```python
self.node.cmap = 'gray'
```

vs 

```python
self.node.cmap = 'grays'
```

Vispy is looking for the wrong colormap. I think @kevinyamauchi that we've seen this problem in other places too.

Great detective work identifying the WelcomeVisual as the problem @Czaki, thanks so much!!!

I will make PR to fix now
Thanks, @Czaki  and @sofroniewn !

Resolving patch:
diff --git a/napari/_vispy/vispy_welcome_visual.py b/napari/_vispy/vispy_welcome_visual.py
--- a/napari/_vispy/vispy_welcome_visual.py
+++ b/napari/_vispy/vispy_welcome_visual.py
@@ -29,13 +29,12 @@ def __init__(self, viewer, parent=None, order=0):
         self.node = ImageNode(parent=parent)
         self.node.order = order
 
-        self.node.cmap = 'gray'
+        self.node.cmap = 'grays'
         self.node.transform = STTransform()
 
         self.text_node = Text(
             pos=[0, 0], parent=parent, method='gpu', bold=False
         )
-        # self.text_node.blending = 'additive'
         self.text_node.order = order
         self.text_node.transform = STTransform()
         self.text_node.anchors = ('left', 'center')


Test patch: