Scratchpads not working with keybind

[hyprland-community]

Scratchpads not working with keybind

[fdev31]

I guess you tested this keybind with another command to check it worked at all, if not, you can exec hyprctl notify -1 10000 "rgba(ffffffff)" "This is working".

If that works, in your keybind line, also log the output using --debug /tmp/pypr_command.log for instance and share it here please.

[fdev31]

It's very likely a duplicate of #7, to debug those issues, in case the --debug file doesn't work because pypr can't initialize at all, then you might need to use a wrapper script such as:

#!/bin/sh
pypr toggle term --debug /tmp/pypr_toggle.log > /tmp/launch.log 2>&1

Feel free to re-open in case it's not a problem related to your python packages installation.

Try using your OS package manager for every package and get rid of pip installed ones, unless they run in a virtualenv.

[JPDucky]

Swapped out my bind for launching the script you wrote above, and was getting command not found so I ran which on it and it was in my local bin. So I symlinked pypr to /usr/bin and tried again, and here is the output I'm getting:

cat launch.log
                      ipc - Logger initialized for ipc // common.py:70
                  startup - Logger initialized for startup // common.py:70
                     pypr - Logger initialized for pypr // common.py:70
                  startup - Unhandled exception: // command.py:241
Traceback (most recent call last):
  File "/home/palmerd/.local/lib/python3.11/site-packages/pyprland/command.py", line 233, in main
    asyncio.run(run_daemon() if len(sys.argv) <= 1 else run_client())
  File "/usr/lib64/python3.11/asyncio/runners.py", line 190, in run
    return runner.run(main)
           ^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/asyncio/base_events.py", line 653, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "/home/palmerd/.local/lib/python3.11/site-packages/pyprland/command.py", line 211, in run_client
    _, writer = await asyncio.open_unix_connection(CONTROL)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/asyncio/streams.py", line 98, in open_unix_connection
    transport, _ = await loop.create_unix_connection(
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/asyncio/unix_events.py", line 259, in create_unix_connection
    await self.sock_connect(sock, path)
  File "/usr/lib64/python3.11/asyncio/selector_events.py", line 634, in sock_connect
    return await fut
           ^^^^^^^^^
  File "/usr/lib64/python3.11/asyncio/selector_events.py", line 642, in _sock_connect
    sock.connect(address)
ConnectionRefusedError: [Errno 111] Connection refused

[JPDucky]

So I've reinstalled a couple times, and what has gotten me some progress is installing with sudo pip install pyprland then running pypr in a shell- which then lets me use my keybind to launch the script above. Problem is, when I run pypr with no command, it launches the the scratchpad, and the keybind will not launch unless I have already run pypr. I'm gonna do some more tweaking and I'll report back here.

[JPDucky]

Okay so switching my hyprland.conf back to the original config (see above), so long as I have pypr running somewhere else the keybind will work. Problem is, running pypr spawns that terminal at first launch.

Update: So I've got it working (I think)- I've put the following config into my hyprland.conf:

exec-once = ~/scripts/hypr/pyprl.sh
# scratchpad
bind = ALT, code:51, exec, pypr toggle term
$dropterm = ^(kitty-dropterm)$
windowrule = float, $dropterm
windowrule = workspace special silent, $dropterm
windowrule = size 80% 70%, $dropterm

and the contents of ~scripts/hypr/pyprl.sh are as follows:

#!/bin/bash

pypr &

I'm not sure why this works instead of just exec-once = pypr, but it does. You can go ahead and close this @fdev31

[fdev31]

I'm pretty sure those are environmental issues, conflicting paths etc... manually installing things is a guarantee to get some problems at some point.

If you don't want pypr to start commands when it starts, but on the first "show" instead, you can use the "lazy=true" option in some scratchpads.
I may make this option the default in a near future.