Linux desktop port (Mint / Cinnamon / X11)

[heliorosadoneto]

Summary

• Shared Tauri crate moved to desktop/; linux/ and windows/ are front doors.
• Linux: notch, tray, Cursor session from ~/.config/Cursor, hover, axis-locked drag.
• Windows behaviour is unchanged; platform code lives in desktop/codenotch/src/platform/.

Test plan

• cd desktop && cargo test --locked on Linux
• Notch appears on Mint/Cinnamon/X11, unfolds on hover, tray works
• Cursor cell reads the editor session (not the CLI dir)
• Dragging the pill slides along the current edge
• Windows CI (build + package) still green

[vinzdg]

Thanks @heliorosadoneto — a lot of careful work here, and Windows behaviour looks preserved. Before this can be considered, the maintainer needs to decide whether Codenotch supports Linux at all (#200); until then I'm leaving it open. Whatever the decision, it would need restructuring:

1. Split it: (a) the pure windows/ → desktop/ move plus platform/, with no behaviour change; (b) Linux on top. The move alone affects every open Windows PR and the release scripts.
2. Fixes: the hook still looks for codenotch.exe (codenotch-hook/src/main.rs:80), so it never launches the app on Linux; platform/mod.rs now compile_error!s on macOS, breaking cargo check there (please keep a stub); Wayland is neither detected nor warned about while placement relies on Xlib; and linux/README.md lines 78–106 contain your own gh pr create notes.
3. CI: linux.yml and linux-package.yml haven't run yet, and a green Windows Package run showing the NSIS installer still comes out is needed.

[vinzdg]

Thanks @heliorosadoneto — I want to be straight with you about where this stands rather than leave it sitting silently.

First, the work is better than I expected. desktop/ is a genuine git mv of windows/ — 53 files at 100% similarity — with every provider shared and only ~215 lines of Linux-specific Rust in desktop/codenotch/src/platform/linux.rs behind a 10-function facade, plus one Linux-gated dependency. That's the right architecture: there's no second copy of anything to maintain, which is the thing I'd have refused outright.

But I'm not merging it yet, and the reason isn't code quality. The windows/ → desktop/ rename is all-or-nothing and permanent, and there are currently open Windows PRs written against the old paths — #282 and #279 among them, plus six that landed today. Merging this invalidates every one of them at once. That's not a reason to say no, but it does mean this needs its own quiet window with nothing else in flight, and I'd want to give the Windows contributors notice first rather than break their branches without warning.

The honest version of the tradeoff, which is mine to decide and not yours to keep arguing: supporting Linux means a third packaging path, two more CI workflows, and me answering Linux bug reports for a desktop environment I don't run. The code here doesn't add much maintenance; the commitment does. I haven't made that call yet.

Two things that need fixing regardless, and one is a real bug:

• desktop/codenotch/tauri.conf.json:34-50 leaks into the Windows release. It sets targets to ["nsis","deb"] and puts the PNGs ahead of icon.ico, and windows-package.yml:64 runs tauri build with no --bundles flag — so the Windows installer job starts reading that list. This has to move into a Linux-only bundle config.
• desktop/codenotch/src/main.rs:451-470 reorders drag_begin and adds an early return on zero window size, un-gated, on a path Windows runs. Either gate it or split it out as its own cross-platform fix.

Smaller: linux/README.md:74-105 ships your own gh pr create command and this PR's checklist into the repo, the dependency lists are duplicated across install-deps.sh and both workflows, and desktop/README.md is still Windows-flavoured (%APPDATA%, Codenotch-Setup.exe).

Mac is untouched by all of this — no Sources/, no xcodeproj, no appcast — which I verified and appreciated.

If you fix the tauri.conf leak and the un-gated main.rs change, I'll keep this open and come back to the platform question deliberately rather than let it rot. I'd rather tell you "not yet, and here's what it depends on" than string you along.

[vinzdg]

@heliorosadoneto — an update, and a heads-up that a second Linux port is now open: #294 by @arlindovs. Tagging you both so neither is working blind.

Your Linux engineering is the better of the two. A real 10-function platform facade with ~215 lines of Linux-specific Rust, no duplicated providers, and desktop/ as a genuine git mv rather than a copy — that is where this should end up. I said so before and it is still true. I also checked something I had wrong earlier: nothing outside the two Windows workflows references windows/, so the rename does not endanger the Mac release path. The cost is open PRs, not the build.

But the branch has not moved since the 19th, and that is now a real problem. It is based on 1.14.0. Since then 1.16.0 shipped, and it added a Tauri updater to the Windows port — src/updater.rs, a plugins.updater block, and signing steps in windows-package.yml. Your branch has none of those, and your edits to windows-package.yml drop the signing steps, so merging as it stands would silently revert the updater. That is the conflict you are seeing.

The three things I asked for on the 19th are also still unaddressed at 88b6450:

1. desktop/codenotch/tauri.conf.json:34 is still ["nsis","deb"] with the PNGs ahead of icon.ico — still leaking a Linux bundle target into the Windows installer job.
2. desktop/codenotch/src/main.rs:451-470 still reorders drag_begin and adds a zero-size early return, un-gated, on a path Windows runs.
3. linux/README.md:70-105 still ships your own gh pr create command and this PR's checklist into the repo.

Two more I found this time: desktop/codenotch-hook/src/main.rs:80 hardcodes codenotch.exe, and platform/mod.rs:18 compile_error!s on macOS — which breaks cargo check from my machine, so I cannot even type-check the tree locally.

Where this leaves things. I have not decided on Linux, and I want to be straight that the holdup is not your code — it is that supporting Linux means a third packaging path and triaging bugs from desktops I don't run, permanently. That is my call to make and I am taking too long over it.

What I would suggest, if you are willing: let #294 go first as a small reversible step that keeps windows/ in place, then rebase this onto it as a behaviour-neutral PR that is purely the git mv plus the facade extraction, absorbing #294's cfg(not(windows)) branches into platform/linux.rs — which is exactly where they belong. That splits the platform decision from the restructuring, and the restructuring is the part I am confident about.

If you would rather not, say so and I will take the whole thing or decline it on its own terms. Either way I owe you an answer rather than silence.

[AfshinJalili]

An accidental stuck socket does eventually self-heal. Node sets no response-write timeout (server.timeout is 0 by default), but the kernel gives up on an unacknowledged write after its TCP retransmission budget — roughly 15 minutes on Linux defaults. The socket dies, close fires, the slot comes back. So "pins indefinitely" only holds for a client that stays alive and reads at zero rate — which takes intent, not bad signal.

Why it isn't nothing. Capacity is 8 per process, and the counter is shared across private downloads, private uploads and public uploads. That number is small enough that ordinary use reaches it.

Real scenarios, most to least likely:

1. Your own admin, reviewing a KYC case. The React admin fetches each document separately — a case with 6 attachments is 6 parallel GETs, 6 slots, from one person. Two customers uploading photos at the same moment and you're at capacity. The result is a 503 during KYC review, from normal operation, with an idle CPU and nothing in the logs but "server busy". This is the one I'd actually expect to see.
2. Android in a tunnel / elevator / rural cell. Coil is mid-download of a 20 MB PDF, signal drops without a FIN. That slot is gone for ~15 minutes.
3. Doze or app-swipe-killed mid-fetch. Same half-open socket, same 15 minutes.
4. Retry on a flaky link. The client times out and retries; the abandoned socket may still hold its slot, so each retry costs two.
5. Rolling deploy on one replica. Slots are per-process, so traffic concentrating on a single pod halves effective capacity exactly when it's most loaded.
6. Deliberate. Your APK is decompilable and the endpoint is on the public internet. One real account + a zero-window reader holds all 8 forever, and that one never self-heals. At 1k users with a known customer base this is low, but it isn't zero.

At 1000 users the throughput argument is weak — real concurrent private-asset transfers are probably 2–5. The argument that survives is scenario 1, and that it fails silently.

Cheapest fix is the timeout, not more slots: raising the count multiplies the memory budget (the author sized 8 slots at ~640 MiB worst case), whereas a write deadline costs one line and makes the download side symmetric with the upload side that already has one.

[heliorosadoneto]

Thanks for the clear write-up — agreed on both the hold-up and the split.

The work lives on my fork: https://github.com/heliorosadoneto/codenotch/tree/feat/linux-desktop

I'm fine with #294 going first as the reversible Linux step, then rebasing this as a behaviour-neutral PR: git mv windows/ → desktop/ plus absorbing the cfg(not(windows)) bits into platform/linux.rs.

Independently I'll fix the items you listed (tauri.conf leak, un-gated drag_begin, hook looking for codenotch.exe, macOS compile_error!, README PR notes) and rebase onto current main so we don't drop the 1.16.0 updater.

[heliorosadoneto]

The review items and the rebase onto current main (1.16.0) are up on this branch.

tauri.conf.json is NSIS + updater only. Deb, PNGs and Linux depends live in tauri.linux.bundle.conf.json.
Windows drag_begin is the 1.16 axis-locked slide. The zero-size guard and edge-only slide stay behind drag_slides_along_edge() (Linux).
The hook launches codenotch on Linux and reads ~/.config/codenotch/config.json.
platform/other.rs stubs the facade so cargo check works on macOS.
linux/README.md no longer carries PR notes. Apt packages are in one linux/apt-packages.txt.
Windows Package signing / latest.json steps from main are restored under desktop/.
cd desktop && cargo test --locked is green here (134 tests). Still happy for #294 to land first; this can then be the behaviour-neutral windows/ → desktop/ move plus folding its cfg(not(windows)) bits into platform/linux.rs.