Valis-GUI

A PyQt desktop front end for VALIS from the same lab — and on the branch you get by cloning it, the Register button runs nothing: the only call into the registration backend is commented out, and the interface marks the run complete regardless.

Purpose

Verdict: do not clone this expecting a working tool. If it is tried at all, check out valis-test, not the default branch. The finding worth carrying forward is not that an unfinished GUI is unfinished — it is where the working code turned out to be, and that the interface reports success without doing anything.

The appeal is obvious and worth stating, because it is why this was looked at: VALIS is configuration-heavy and terminal-driven, this group runs Windows workstations, and a form with combo boxes is a plausible route to getting a pathologist to run a registration at all. That is a real need. This is not yet the thing that meets it.

Data used

None. samples.csv on main is a leftover worklist pointing at a developer’s own /Users/4474613/Downloads/... copy of the VALIS example datasets.

Methods

Read at source level on 2026-08-01 from a full clone, on both branches. Every claim below was independently re-checked by a reviewer instructed only to refute it; that pass overturned two things this page originally said and made the conclusion stronger rather than weaker. Both corrections are recorded in place, because the pattern in them is the useful part.

On main — the default branch — the Register button is wired to nothing

src/gui/views/windows/functions_main_window.py assembles the user’s settings into a dictionary, writes them to a hardcoded /Users/4474613/Documents/user_settings.json, and then:

#self.valis_worker = ValisWorker()
#self.valis_worker.begin_process(docker_path, data_dict)
#self.valis_worker.finished.connect(...)

REGISTRATION_STATE = COMPLETE

The three lines that would start a registration are commented out. The line that tells the rest of the interface the registration finished is not. This is the whole finding, and it is worse than “incomplete”: a user gets a completed-looking run and no output, with nothing in the interface saying so.

Behind those commented lines, valis_command.py’s begin_process() is documented """Not configured yet."""; it unpacks every setting the user chose into local variables, uses none of them, and issues docker run --rm docker-test with no volume mount and no arguments. A third module, launch_with_selections.py, does construct a real registration.Valis(**selections) call and is the only genuinely functional piece on the branch — but nothing in the GUI reaches it; it is invocable only through its own __main__.

Correction, from the refutation pass: this page first asserted that main has no launchscript.sh. It does — the shell script that runs the Docker container is present and looks correct. The claim was wrong and the conclusion survives it, because the failure is upstream of that script: nothing calls it. Recording the slip because the lesson generalises — “the plumbing is missing” was the tidier story, and the real one was “the plumbing is fine and the tap is disconnected”.

There is no requirements.txt, setup.py or pyproject.toml on main, so its PyQt dependencies are undeclared. __pycache__ (249 files), .idea/ and .DS_Store are committed.

valis-test is where the work went, and it is not reachable by default

origin/valis-test’s most recent commit is 2026-01-23, seventeen months later than main’s. It rewrites the launch path into src/gui/models/qt_threads/valis_thread.py, which validates the session’s user_settings.json and sample.json, checks that Docker is running, and then either docker execs into a pre-built session container or docker runs one with bind mounts for the source slides and the output directory, piping stdout and stderr back to the interface. It adds a pinned requirements.txt, a docker/Dockerfile built on cdgatenbee/valis-wsi:1.2.0, a real 135-line README, and deletes all 249 committed cache files. That is a coherent design.

Second correction: the two branches are diverged, not sequentialmain carries six commits valis-test does not, and valis-test thirty that main does not. “Thirty commits ahead” was the first reading and it was wrong; nobody has merged them, and choosing one means giving up whatever is in the other.

Neither branch is clean of developer-specific state. The hardcoded C:\Users\80029349\Documents\GUI-Repo\...\on_register_press.py used as the Windows working directory survives into valis_thread.py on valis-test — where it now points at a file that branch deleted — under a # TODO: Configure windows portion. For a Windows-first department that is the relevant sentence on this page: the Windows path is the one the authors marked as untested, on both branches.

Current state / open questions

  • Is valis-test actually runnable end to end? Not tested here — it needs Docker, a built image and slides, and that is an afternoon rather than a read. It is the only version worth spending that afternoon on.
  • Would the group be better off with fifteen lines of Python than with this? VALIS’s API is a directory in, a directory out. The GUI’s value is entirely in not making a pathologist touch a terminal, which is real — but the same benefit is available from a QuPath menu entry calling a script, which is the pattern QuPath Hepatocyte Extension already establishes here and which nobody would have to maintain against someone else’s dormant branch.
  • The LICENSE file exists and is empty on both branches, so the code is unlicensed in effect. Recorded, not investigated, per AGENTS.md §8.

How it connects

VALIS — the backend this wraps; read that page first, because the capability being wrapped is the reason to care and it is unaffected by any of this.

QuPath Hepatocyte Extension — the alternative pattern already working in this group: a QuPath menu entry that shells out to a Python process, so the model runs outside the GUI and the extension stays thin. If a front end for registration is ever wanted, that is the shape to copy.

Slide Metadata Extraction — the same failure class, in someone else’s code this time: an operation that does not happen while the surrounding software reports that it did.

OncoLens — the same author’s other application, and the reason this page’s findings read as a house style rather than one bad afternoon: the same PyQt scaffold down to the settings file and window chrome, and a README from the same template rooted at the same phantom digital-twin-pipeline/ directory, both written on 2026-01-23. Read them together before judging either — a pattern repeated across two repositories says something different about what to expect from a third than a single instance does.

Derived from: repository cloned at full depth 2026-08-01; main (2971593) and valis-test (ed3d03d) both read via git show; files read include main.py, settings.json, samples.csv, src/core/scripts/valis/* on both branches, src/gui/views/windows/functions_main_window.py, src/gui/models/qt_threads/valis_thread.py, requirements.txt, docker/Dockerfile, launchscript.sh and both LICENSE blobs. Currency figures computed from the clone’s own git history; the GitHub API was unreachable from this session, so star, fork and open-issue counts were not obtained.

Reuse

None — the LICENSE file is present and zero bytes, on every branch