Yes, that's another good way. I have some shortcuts like that I've used for years, but I haven't made one for Leo yet.
On Wednesday, October 15, 2025 at 10:19:06 PM UTC-4 rengel wrote: > This inspired me to add a shortcut to the properties dialog of my Leo > icon. Now I can start Leo just by clicking: *Ctrl+Shift+L*. > > [image: LeoStart.png] > > The complete *Target *is: > > C:\Windows\System32\cmd.exe /c "C:\venvs\leo\run_leo.bat" > > As *Run* is *Minimized*, the command window doesn't show up. > > The complete *run_leo.bat* is: > > @echo off > echo Activating virtual environment... > call C:\venvs\leo\Scripts\activate > echo Launching Leo... > leo > if %ERRORLEVEL% NEQ 0 ( > echo Error: Failed to launch Leo. Check the error message above. > pause > ) > echo Deactivating virtual environment... > deactivate > On Wednesday, October 15, 2025 at 5:49:02 PM UTC+2 [email protected] > wrote: > >> Another easy way to start Leo is to use the Run dialog you get by typing >> <Windows key>+R. After you have done this once, the command is remembered >> and available in the dialog - scroll up or down a step or two if it's not >> there at the beginning. In my case, here's the command I use; it launches >> a batch file that starts Leo using the version in my Git repository: >> >> py-leo-git --theme=tbp_dark >> >> I find it easier to start Leo this way than by clicking on an icon, but >> of course YMMV. >> On Wednesday, October 15, 2025 at 10:36:58 AM UTC-4 rengel wrote: >> >>> @tbp1... >>> >>> Thanks for your detailed comments about the finer details of pip. As I >>> said, I settled for the venv solution; and up to now it runs flawlessly. >>> I'm on a single-user machine in my private home. So no one else will ever >>> install anything on this machine. My main Python installation doesn't >>> contain PyQt6. Everything is localized in the venv. >>> >>> For me it is important that I can start Leo from the taskbar. For that, >>> the batch file is needed. The last part of my conversation with Grok was >>> mainly about debugging the batch file that Grok initially suggested. As >>> you might have seen, the final version of this batch file does contain the >>> 'call' command, because the first version indeed stopped after the first >>> line. And the answer to my last question of the conversation helped me to >>> get that clickable Lion icon on the taskbar faster, than I could have done >>> on my own, because those pesky details slip may memory way too fast. >>> >>> Thanks again! >>> Reinhard >>> >>> On Wednesday, October 15, 2025 at 3:09:34 PM UTC+2 [email protected] >>> wrote: >>> >>>> Some of the things that the chatbot suggested aren't really the best, >>>> and in some cases seem to be wrong, even though you succeeded. For >>>> example, >>>> suggested batch file run_leo.bat isn't necessary in a venv. On install Leo >>>> creates a launcher in the Scripts directory. After activation, typing >>>> "leo" will launch it. What is helpful to to have a batch file in your path >>>> that both activates the venv and launches Leo. That way you don't have to >>>> type the path the the activate script. >>>> >>>> Another mistake is that py -m leo won't launch leo. The right command >>>> is py -m leo.core.runLeo (there are other possibilities too). But as I >>>> said, once the venv has been activated, a simple leo is enough. >>>> >>>> Here's a minimal batch file that will activate the venv and run Leo. >>>> It assumes that the name of the venv is "leo" Just change the path to >>>> suit >>>> your own location: >>>> >>>> setlocal >>>> call c:\tom\venvs\leo\Scripts\activate >>>> py -m leo.core.runLeo %* >>>> endlocal >>>> >>>> You need the "call" command in Windows because without it the script >>>> will stop after that line. On linux, replace"call" with "source". The >>>> setlocal/endlocal (Windows only) remove path and other environmental >>>> variable changes that may happen during the activation and Leo session >>>> (which probably wouldn't be a problem for you but it's good practice >>>> anyway). >>>> >>>> Another thing that can happen, and can cause version conflicts and >>>> unexpected behavior when a program or packages are removed. It's the >>>> distinction between installing into the main Python location and the >>>> user's >>>> location. The user location is specific to each user, and you install >>>> into >>>> it using the "--user" option: py -m pip install --user leo. With a >>>> venv, there is no distinction. "--user" isn't allowed, and all installs >>>> go >>>> into the venv. The chatbot's suggestions didn't use "--user". Usually >>>> it's >>>> considered better to install most things with "--user". In case something >>>> in the system-level Python locations gets used for system purposes, >>>> keeping >>>> other installs in the user's locations can prevent version conflicts and >>>> the like. This is more important on Linux than Windows but it's still a >>>> good practice to use "--user" when possible. >>>> >>>> Now what will happen if you install one program that uses, say, PyQt6 >>>> as user, and install another program that also uses PyQt6 without the >>>> "--user" option? You might end up with different versions of PyQt6 in the >>>> two locations. Python sets up the paths to search the user's locations >>>> first. So if you use Pip to uninstall PyQt6, and then run Python, it will >>>> still use the other version of PyQt6. Or fail to, if the other install >>>> becomes broken somehow. >>>> >>>> In other words, there can be hidden and unexpected results if sometimes >>>> one installs using "--user" and sometimes one doesn't. I have done this to >>>> myself more than once. Using a venv makes this kind of problem go away. It >>>> also prevents errors that happen when the pip command runs a different >>>> version of Python than what you expected. That can happen, for example, >>>> when you have multiple versions of Python installed. It is recommended to >>>> launch Pip using py -m pip to >>>> prevent this problem. With a venv, the right versions are always run >>>> and this issue doesn't come up. >>>> On Wednesday, October 15, 2025 at 5:59:04 AM UTC-4 rengel wrote: >>>> >>>>> I used Grok extensively to help me solving this issue. In case >>>>> somebody is interested in the dialog, here is the link: >>>>> >>>>> >>>>> https://grok.com/share/c2hhcmQtMg%3D%3D_abe479b8-59c3-46db-b21a-35be3f2be2dc >>>>> >>>>> It is rather long, but it leads from describing the issue to clean >>>>> starting Leo from the Windows taskbar. >>>>> (It also shows my lack of experience in these matters; but that's >>>>> another topic...) >>>>> >>>>> On Wednesday, October 15, 2025 at 11:32:14 AM UTC+2 rengel wrote: >>>>> >>>>>> @lewis, @tbp1 >>>>>> >>>>>> Thank you both for chipping in. I tried both your suggestions. >>>>>> Deleting old relics of PyQt6* and a fresh reinstall of PyQt6 in the >>>>>> main Python installation solved all the problems; >>>>>> and using a venv with a simple 'pip install leo' worked as well. >>>>>> Finally I settled for the venv solution! >>>>>> Thanks again! >>>>>> Reinhard >>>>>> >>>>>> On Wednesday, October 15, 2025 at 1:29:53 AM UTC+2 [email protected] >>>>>> wrote: >>>>>> >>>>>>> That's one reason to try to install to a new venv. There won't be >>>>>>> any left-over bits to confuse the installer. >>>>>>> >>>>>>> On Tuesday, October 14, 2025 at 5:00:12 PM UTC-4 lewis wrote: >>>>>>> >>>>>>>> After updating to Python 3.14 I had the same problem starting Leo. >>>>>>>> >>>>>>>> >>>>>>>> *File "N:\git\leo-editor\leo\core\leoQt.py", line 6, in <module> >>>>>>>> from PyQt6 import QtCore, QtGui, QtWidgets* >>>>>>>> >>>>>>>> *ModuleNotFoundError: No module named 'PyQt6.sip'* >>>>>>>> >>>>>>>> I needed to uninstall packages PyQt6 and PyQt6_sip, then reinstall. >>>>>>>> Leo then worked fine. Both my desktop PC and laptop had the same issue. >>>>>>>> >>>>>>>> There have been other packages which did not work correctly >>>>>>>> with Python 3.14 and a package reinstall was needed. >>>>>>>> >>>>>>>> On Wednesday, October 15, 2025 at 2:17:14 AM UTC+11 rengel wrote: >>>>>>>> >>>>>>>>> [image: ModuleNotFoundError.png] >>>>>>>>> >>>>>>>>> >>>>>>>>> A correction: The installation from github did install >>>>>>>>> launchLeo.py. But starting 'python launchLeo.py' still results in the >>>>>>>>> error: >>>>>>>>> ModuleNotFoundError: No module named 'PyQt6.sip'. (I did install >>>>>>>>> the requirements.) >>>>>>>>> >>>>>>>>> On Tuesday, October 14, 2025 at 5:00:37 PM UTC+2 rengel wrote: >>>>>>>>> >>>>>>>>>> Thank you for your answers! >>>>>>>>>> I waited for a couple of days to install the latest version of >>>>>>>>>> leo. But in vain. I tried both the pip install and the install from >>>>>>>>>> github. >>>>>>>>>> But in both cases I get the same error shown in my original post. >>>>>>>>>> Upon >>>>>>>>>> closer inspection, I noticed that neither launchLeo.py nor PyQt6.sip >>>>>>>>>> have >>>>>>>>>> been installed. And the installation didn't install a Leo home >>>>>>>>>> directory >>>>>>>>>> for me. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thursday, October 9, 2025 at 11:08:55 PM UTC+2 >>>>>>>>>> [email protected] wrote: >>>>>>>>>> >>>>>>>>>>> I just installed Python 3.14 on Windows 11. Then I created a new >>>>>>>>>>> virtual environment and pip-installed Leo into it. PyQt6.sip got >>>>>>>>>>> installed >>>>>>>>>>> and Leo ran normally. Something went wrong when @rengel tried >>>>>>>>>>> installing >>>>>>>>>>> Leo, I think, because PyQt6 didn't install normally. >>>>>>>>>>> >>>>>>>>>>> I'd suggest creating a venv like I did and trying it that way. >>>>>>>>>>> >>>>>>>>>>> On Thursday, October 9, 2025 at 4:48:45 PM UTC-4 Thomas Passin >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> I don't think that's it - PyQt6.sip normally gets installed >>>>>>>>>>>> during a PyQt6 installation. >>>>>>>>>>>> >>>>>>>>>>>> On Thursday, October 9, 2025 at 2:52:51 PM UTC-4 >>>>>>>>>>>> [email protected] wrote: >>>>>>>>>>>> >>>>>>>>>>>>> @rengel, >>>>>>>>>>>>> >>>>>>>>>>>>> rengel schrieb am Donnerstag, 9. Oktober 2025 um 16:43:08 >>>>>>>>>>>>> UTC+2: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> yesterday I updated my machine from Windows 10 to Winddos 11. >>>>>>>>>>>>> Today, I completely removed all my old Python installations and >>>>>>>>>>>>> then >>>>>>>>>>>>> installed the new Python 3.14. From Python I did a fresh install >>>>>>>>>>>>> of Leo >>>>>>>>>>>>> from PyPi (`python -m pip install leo`) as described on the Leo >>>>>>>>>>>>> website. >>>>>>>>>>>>> During the install I got the following WARNING: >>>>>>>>>>>>> [image: leo-warning.png] >>>>>>>>>>>>> When I start leo, I get the following error:[image: >>>>>>>>>>>>> leo-error.png] >>>>>>>>>>>>> The environment contains the correct paths to Python and >>>>>>>>>>>>> Python\Scripts. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> You installed the latest version of Leo from PyPI, which is >>>>>>>>>>>>> version 6.8.6.1. >>>>>>>>>>>>> >>>>>>>>>>>>> This version does NOT yet support Python 3.14.0 ! >>>>>>>>>>>>> >>>>>>>>>>>>> If you want to try it out before Edward releases version >>>>>>>>>>>>> 6.8.7, you have to use the 'devel' branch from GitHub. >>>>>>>>>>>>> >>>>>>>>>>>>> See >>>>>>>>>>>>> https://leo-editor.github.io/leo-editor/installing.html#installing-leo-from-github >>>>>>>>>>>>> >>>>>>>>>>>>> With kind regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Viktor >>>>>>>>>>>>> >>>>>>>>>>>>> -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/leo-editor/938ca7c4-31dd-4f12-8aeb-6c2246572f17n%40googlegroups.com.
