After installing Jupyter Notebook into a conda env on Linux (KDE, but this applies to GNOME too), nothing appears in the application menu. A newcomer has no way to discover how to launch it short of knowing to activate the env and type jupyter notebook in a terminal.
The frustrating part: the launchers do exist. The packages ship jupyter-notebook.desktop and jupyterlab.desktop into /share/applications/, but nothing ever copies or links them into ~/.local/share/applications/, so no desktop environment ever sees them. And even if you copy them manually they’re broken as shipped, because Exec=jupyter-notebook %f assumes the env’s bin is on PATH (it isn’t outside an activated shell), and Icon=notebook isn’t resolvable outside the env’s icon theme dir.
Workaround that gives you a working menu entry (adjust the env path):
ENV=$HOME/miniconda3/envs/notebook-env # your env here
cat > ~/.local/share/applications/jupyter-notebook.desktop <<EOF
[Desktop Entry]
Name=Jupyter Notebook
Comment=Run Jupyter Notebook
Exec=$ENV/bin/jupyter-notebook %f
Path=$HOME
Terminal=false
Type=Application
Icon=$ENV/share/icons/hicolor/scalable/apps/notebook.svg
StartupNotify=true
MimeType=application/x-ipynb+json;
Categories=Development;Education;
Keywords=python;jupyter;
EOF
update-desktop-database ~/.local/share/applications
Same recipe works for JupyterLab (jupyter-lab, icon jupyterlab.svg).
Suggestion for the maintainers: either register the launchers at install time (the way menuinst does on Windows, where conda installs do get Start Menu shortcuts), or template the absolute paths into the shipped .desktop files and document one command that installs them. First-run discoverability on Linux is currently zero, and the gap between “shipped but never registered” feels like a bug rather than a policy choice.