Packages

FlashScp -- a two-pane scp-over-SSH file-transfer GUI, from Stan Switaj (programmer/creator of LinuxDoors), created 2026-08-30. Free. Not upstream anywhere -- FlashScp.py (a ~4,840-line PySide6/Qt6 app) is a hand-authored asset, tarred as a pinned local source (flashscp-2026.08.30.tar.gz in download/, sha pinned) the same way packages/sudo and LinuxUltraOffice's branding assets are. This is the installable-package build: it uses the system Python + PySide6 + Qt6 (depends: pyside6 -> which itself pulls qt6-full and, transitively, qtwebengine -- ~290MB total, since there is no pyside6-base split) and the system ssh/scp/sshpass. The lightweight alternative is the self-contained FlashScp.AppImage on the LinuxDoors AppImage Store (linuxdoors.com/appimages), which carries its own Python + Qt + sshpass in one ~50MB file. build.sh installs FlashScp.py to /usr/lib/flashscp/, a /usr/bin/flashscp wrapper (python3 that script), a /usr/share/applications/flashscp.desktop in Categories=Network (Applications > Internet), and the 256px FlashScp.png as the hicolor + pixmaps icon. The app draws its own window icon programmatically (draw_bolt()) so it needs no icon file to run. FlashScp deliberately drives the real ssh/scp/sshpass as child processes -- no bundled SSH library -- so keys, ~/.ssh/config, the agent, known_hosts, ProxyJump and key+password hosts all behave as in a terminal. ship_in_iso=false. Verified on the .101 fast computer via Xvfb. || 2026.08.30 -> 2026.09.24 (2026-09-24): the folder-copy "already there, skip it" check now verifies by SHA-256 at both ends once file sizes match, instead of trusting size alone -- an edit that happens to leave a file's length unchanged (the ordinary case while someone is actively working on a file) used to be silently skipped as "already copied"; now only a genuine content match skips it, and a size match that turns out to differ is sent. Only same-size files are hashed (a normal transfer with no naming collisions costs nothing extra), and the far end is asked for its hashes once for the whole batch via whichever of sha256sum/shasum/openssl it has, not once per file. Text and description also picked up: a real text_description_flashscp.txt now ships (previously referenced by appimages.json but never actually present, so the site's "Read full description" toggle never rendered for this app). || 2026.09.24 -> 2026.09.30 (2026-09-30): two real bugs fixed, both around key-based auth. (1) A private key locked with a passphrase never worked -- with no password ticked, the connection used BatchMode, which suppresses every prompt ssh can make including the key's own passphrase prompt, so ssh refused the key unread ('Permission denied (publickey)', reading as a wrong key rather than a locked one); with a password ticked, sshpass answered the passphrase prompt with the machine's password instead, so the key still failed and the password was spent for nothing. Fixed with a new Key passphrase field (a genuinely separate secret from the machine's password -- a machine can want both) and a small helper program handed to ssh via SSH_ASKPASS that inspects the actual prompt text to decide which of the two secrets to answer with -- the one thing sshpass structurally cannot do, since it answers every prompt with the same single secret. Also fixed in the same area: a password typed into the field was previously ignored unless its own tick was on (backwards -- the tick now only means 'ask me for one if I have not given you one'), and a secret you decline to save no longer gets silently written back into its own on-screen field (where Show would reveal it and the next Save would persist it) -- it is now held aside for the session instead, surviving every form repaint without ever reappearing on screen unless typed again. (2) Browse-for-a-key showed an empty file picker on any machine running xdg-desktop-portal, since the OS portal chooser (a separate process) was the one coming up empty, not FlashScp's own listing -- fi

linuxdoors-vncviewer -- a small, real, interactive Qt6 VNC client (a hand-authored asset tarred as a source, same pattern as packages/sudo/packages/flashscp), built on top of packages/libvncserver's libvncclient. Written specifically for the GNOME 51 (VNC) x2goclient integration: x2goclient's own patched 'GNOME 51 (VNC)' session type tunnels a local port to the remote host's 127.0.0.1:5900 (gnome-remote-desktop's VNC server, started via linuxdoors-gnome51-vnc -- see packages/gnome-session's own notes) over its existing SSH connection, then spawns this against that local port instead of embedding nxagent's X11 window the way every other x2go session type does. Real, interactive, not just a screenshot tool: a background QThread pumps WaitForMessage/HandleRFBServerMessage and repaints via a queued signal, mouse motion/clicks/wheel are forwarded via SendPointerEvent, and keyboard input via SendKeyEvent using a pragmatic (not fully exhaustive, but covers real everyday desktop use -- arrows/backspace/enter/escape/tab/delete/home/end/pgup/pgdn/F1-F12/modifiers plus all printable text via the Qt-key-event's own Latin-1/Unicode codepoint, which is numerically identical to the corresponding X11 keysym in that range) Qt-key-to-X11-keysym map. Isolated to /opt/gnome51 is NOT needed here -- this is a plain client tool linked against the SHARED qt6-full and libvncserver, no soname/path collision risk with anything. Built + connect-verified for real against a live gnome-remote-desktop VNC server on .101 before being wired into x2goclient. || Real bug found and fixed here (2026-09-19), reported live by a user once mouse/keyboard input actually worked: the visible pointer had a 'shadow with a delay' -- their own real, instant local cursor, plus a second one GNOME Shell was baking directly into the video frames (since nothing had ever asked for real VNC cursor handling), lagging by a full network+frame round-trip. Fixed with the real, standard VNC cursor pseudo-encoding: appData.useRemoteCursor=TRUE plus GotCursorShape/HandleCursorPos callbacks -- libvncclient then requests it automatically during the handshake, a compliant server (gnome-remote-desktop is) stops drawing its own cursor into frame updates, and this client draws the server's cursor shape itself at the LOCALLY-tracked mouse position (repainting on every local mouseMoveEvent, not just on server frame updates), so the pointer is instant with no double image. || LIVE RESIZE FEATURE (2026-09-19), built after a user asked why the resolution couldn't be changed from inside the running GNOME 51 Settings app -- real answer: a headless Mutter virtual monitor (--virtual-monitor=WxH) has exactly one fixed mode for its whole lifetime, confirmed against Mutter's own meta-context-main.c, so there is genuinely nothing else for Settings to list, and no live in-place resize is possible either. The only real fix is to restart the remote gnome-shell/gnome-remote-desktop at a new size (x2goclient's own new 'GNOME 51 (VNC): Change Resolution...' Session-menu action does this, re-running linuxdoors-gnome51-vnc over the same already-open SSH connection) and have THIS viewer reconnect on its own once the new server is ready. Added: VncWidget now retries a dropped connection automatically (VncThread::finishedWithReason -> onThreadFinished -> scheduleReconnect/attemptReconnect, every 1.5s for up to 40 attempts/~60s before finally giving up and showing the old 'Disconnected' dialog), with a 'Reconnecting... (attempt N of 40)' status shown in the empty-framebuffer paintEvent() text; a deliberate window close (closeEvent, m_closing) suppresses reconnecting. || TWO REAL, PRE-EXISTING CONCURRENCY BUGS found and fixed getting this far, not something this feature introduced but something it made vastly more likely to trigger (a resize -> reconnect cycle now happens routinely instead of rarely): (1) resizeCB() reallocated client->frameBuffer to the new size with NO lock at all, while paintEvent() reads client->fram