Add SlicerConnect Extension

[pka420]

New extension

Tier 1

Any extension that is listed in the Extensions Catalog must fulfill these requirements.

• Extension has a reasonable name (not too general, not too narrow, suggests what the extension is for). The extension name should not start with Slicer (unless it explicitly provides a bridge between Slicer and a tool or library), because it would make it more difficult to find extensions if the name of many started with the same word.
• Repository name is Slicer+ExtensionName (except if the repository that hosts the extension can be also used without Slicer)
• Repository is associated with 3d-slicer-extension GitHub topic so that it is listed here. To edit topics, click the settings icon in the right side of "About" section header and enter 3d-slicer-extension in "Topics" and click "Save changes". To learn more about topics, read https://help.github.com/en/articles/about-topics
• Extension description summarizes in 1-2 sentences what the extension is usable (should be understandable for non-experts)
• Any known related patents must be mentioned in the extension description.
• LICENSE.txt is present in the repository root and the name of the license is mentioned in extension homepage. We suggest you use a permissive license that includes patent and contribution clauses. This will help protect developers and ensure the code remains freely available. MIT (https://choosealicense.com/licenses/mit/) or Apache (https://choosealicense.com/licenses/apache-2.0/) license is recommended. Read here to learn more about licenses. If source code license is more restrictive for users than MIT, BSD, Apache, or 3D Slicer license then describe the reason for the license choice and include the name of the used license in the extension description.
• Extension URL and revision (scmurl, scmrevision) is correct, consider using a branch name (main, release, ...) instead of a specific git hash to avoid re-submitting pull request whenever the extension is updated
• Extension icon URL is correct (do not use the icon's webpage but the raw data download URL that you get from the download button - it should look something like this: https://raw.githubusercontent.com/user/repo/main/SomeIcon.png)
• Screenshot URLs (screenshoturls) are correct, contains at least one
• Content of submitted json file is consistent with the top-level CMakeLists.txt file in the repository (dependencies, etc. are the same)
• Homepage URL points to valid webpage containing the following:
  • Extension name
  • Short description: 1-2 sentences, which summarizes what the extension is usable for
  • At least one nice, informative image, that illustrates what the extension can do. It may be a screenshot.
  • Description of contained modules: at one sentence for each module
  • Publication: link to publication and/or to PubMed reference (if available)
• Hide unused github features (such as Wiki, Projects, and Discussions, Releases, Packages) in the repository to reduce noise/irrelevant information:
  • Click Settings and in repository settings uncheck Wiki, Projects, and Discussions (if they are currently not used).
  • Click the settings icon next to About in the top-right corner of the repository main page and uncheck Releases and Packages (if they are currently not used)
• The extension is safe:
  • Does not include or download binaries from unreliable sources
  • Does not send any information anywhere without user consent (explicit opt-in is required)

[pieper]

This sounds pretty cool to me 👍

[pka420]

This sounds pretty cool to me 👍

Thanks! It is buggy though and in experimental mode,
Do I need to do anything for this to be merged?

[pka420]

@pieper Please let me know if I need anything else to do here.

[pieper]

This sounds like a cool project. There are a couple checks not passing (see below).

Also it looks like there are some other things to address (the text below is Claude Code talking, not me).

Quick take: the scope and structure are reasonable for a Slicer extension (three ScriptedLoadableModules, proper CMakeLists, UI files, logic/widget separation), and the delta-sync idea is sound. But the code has several shipping blockers and a handful of Slicer-idiom problems you'd want fixed before calling this usable — and more before submitting to the ExtensionsIndex.

Shipping blockers (will crash or not build):

SlicerConnect.py:67 — stray bareword m inside _try_refresh_token; every 401 refresh path raises NameError.
SlicerConnect.py:488 — local_path=Null (should be None); download flow can't execute.
SlicerConnect.py:148 — uses json.dumps but json is never imported.
SlicerConnectLogin.py:150 — selectModule("CollaborativeSegmentation") — no such module; should be "SlicerConnect".
Top-level CMakeLists.txt — EXTENSION_LICENSE_FILE points to LICENSE but repo has LICENSE.txt; ICONURL/SCREENSHOT_URLS are absolute root paths, need full URLs for the index.
Security/privacy — contradicts the README:

SlicerConnectEditor.py:342 uses ws:// (cleartext) while README promises WSS. For PHI claims, that's a real problem.
Auth token appended as a URL query param on the WS handshake — ends up in proxy/server logs. Use a subprotocol or Authorization header.
Token is persisted to slicer.app.settings() (plaintext QSettings).
Slicer-idiom issues:

Main-thread pip_install + synchronous requests calls block the UI.
QTimer-polled non-blocking websocket-client at 200 ms works but QWebSocket would integrate with Qt's event loop without polling.
_applyArrayToSegmentation rebuilds every segment on each delta, largely defeating the delta optimization, and the per-label flatten drops Slicer's native overlapping-segment support.
SlicerConnectEditor category "None" (literal string) — it'll appear under a category named "None".
slicer.util.currentTime() SlicerConnect.py:573 isn't a real API.
File handles opened in files={"file": (..., open(path, "rb"), ...)} are never closed.
Design smell: the _resampleToShape + "shape mismatch" branch is papering over a bug — a bound session shouldn't see shape changes. Worth fixing the root cause instead.

Overall: the architecture is credible, but it reads like an early-stage prototype that hasn't been end-to-end exercised — several of the blockers would surface the first time you clicked a button. Worth a cleanup pass before it's demo-worthy, and real encryption/credential handling before anyone touches patient data with it.

[pieper]

BTW, for pure python modules you really don't need to make extensions at all. You can just put install instructions on your github page and post about the modules on the slicer forum. As long as you follow the extension format, all people need to do is checkout your code (or download the zip) and drop the folder on Slicer. Don't even need a restart. We should probably make this more clear in the dev instructions.

[pka420]

an early-stage prototype that hasn't been end-to-end exercised — several of the blockers would surface the first time you clicked a button. Worth a cleanup pass before it's demo-worthy, and real encryption/credential handling before anyone touches patient data with it.

Thanks! I will work on the fix.
I do want it to publish the extension (even if its pure python) to showcase the project.

[lassoan]

Nice work! Real-time multi-user collaboration so far has been mostly available in Slicer-based commercial applications and a few open-source research prototypes, so it is useful to have an up-to-date, maintained open-source solution for this. I would recommend to advertise the open-source server as well (https://github.com/pka420/SlicerConnectBackend) as many people may not want to rely on a proprietary server.

Make sure that all the automatic tests in "Extension Validation" and "Lint" actions are fixed, we cannot merge if those tests are failing.

Consider uploading a more informative screenshot (the current one shows a single empty Slicer application window).