Brandon LiandClaude Opus 5
c5c946d3cc
The clicker had no Linux support at all: pygetwindow has no X11 backend, so _other_activate returned "window management is unsupported" and every step failed before it could click. focus.py now has a third backend that raises the browser with xdotool and reads the focused window's WM_CLASS to verify it came forward - the same activate-then-confirm shape as the macOS and Windows paths. setup-linux.sh mirrors setup-windows.bat with apt instead of winget. Three things are specific to this platform rather than incidental: - Node comes from NodeSource. Pi OS ships one too old for Next 16, and the LTS line is also what better-sqlite3 publishes prebuilt arm64 binaries for. - Python dependencies go in a virtualenv. Pi OS Bookworm enforces PEP 668, so pip into the system interpreter fails with externally-managed-environment. - Autostart uses an XDG ~/.config/autostart entry, the direct analogue of the Windows Startup folder: no sudo, and it runs inside the graphical session, which the clicker needs for DISPLAY. Wayland is called out in four places - the session guard, diagnose.py, the installer and both READMEs - because Pi OS on a Pi 5 defaults to it and the clicker simply cannot work there. Wayland does not let one client synthesise input into another, so this is a switch-to-X11 situation, not a bug to fix. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
11 lines
524 B
Plaintext
11 lines
524 B
Plaintext
pyautogui>=0.9.54
|
|
# macOS backends: Quartz drives the mouse, Cocoa (AppKit) raises the browser
|
|
# window without needing AppleScript automation permission.
|
|
pyobjc-core>=10.0; sys_platform == "darwin"
|
|
pyobjc-framework-Quartz>=10.0; sys_platform == "darwin"
|
|
pyobjc-framework-Cocoa>=10.0; sys_platform == "darwin"
|
|
# Linux: pyautogui drives X11 through Xlib. Raising the browser window is done
|
|
# with xdotool, which is an apt package rather than a wheel - setup-linux.sh
|
|
# installs it.
|
|
python-xlib>=0.33; sys_platform == "linux"
|