examples/gui/ is a full Qt + open3d application (30 modules, 4,815 lines) rather
than an example, and its proper home is the orisys-studio application. The move
is planned but not started, so this records the plan rather than performing any
of it.
What the plan establishes, so the work does not have to be re-derived:
- src/orisys/ imports no gui/viz/examples module, verified by AST rather than
grep. The dependency is one-way, so the GUI can leave without a library
change. The single apparent hit is `from .pipeline import ...` in
src/orisys/__init__.py, which is the SDK's own module.
- examples/viz/ is shared and cannot follow the GUI wholesale: it mixes open3d
renderers with toolkit-independent helpers that examples/pipeline/service.py
and tests/test_contact_arrow_scale.py depend on. It has to be split.
- The real coupling is inverted and lives in the tests: tests/test_qt_viewer_backend.py
imports examples/gui, and tests/conftest.py deliberately puts examples/ ahead
of build/ because both define a package named `gui`. Removing the GUI means
re-deriving that guard, not deleting it blindly.
- UVMeshViewer and friends are in src/orisys/finger/__init__.__all__, so removing
them is a breaking change to a released API and needs a deprecation release
first. It must not be folded into a code move.
- The `examples/` directory must keep existing in the packaged layout even after
gui/ leaves it: src/orisys/configs.py anchors its run-root detection on a
sibling examples/ folder.
Also updates examples/README.md to say "lives here for now" instead of "is moving
out", so nothing reads as work in progress. The GUI itself is untouched, and the
only guidance offered is that new SDK work should not build on it.
ykcheungab