Conversation
|
@ansBAkula can you please add in the description info about the code changes in this PR as well? The current description indicates only the library bump, but there actually is more work there (for the WASM library fix). Can you please add in the PR description what these changes are and how they change the behavior of VISOR? |
Done. |
LKasianAnsys
left a comment
There was a problem hiding this comment.
Built in a clean repo (including the updated visor-setup), ran some basic manual tests, and didn't see any issues. Approving (though I know @margalva needs to approve as well)
This branch bumps
trame-vtklocalfrom0.16.4to1.6.2and updates the code that depends on its WASM asset layout to match the new version's behavior.trame-vtklocalpinned version updated from0.16.4to1.6.2inpyproject.toml.0.16.4): shipped a single flat WASM directory underwasm/<version>, and exposed its URL to the frontend as a plain string under the__trame_vtklocal_wasm_urlstate key.1.6.2): builds separate 32-bit and 64-bit WASM variants underwasm32/<version>andwasm64/<version>, and exposes them to the frontend as objects (with aurlproperty) under new state keys —__trame_vtklocal_wasm32/__trame_vtklocal_wasm64.autosetup.py: updated to copy thewasm32build instead of the old flatwasmdirectory. Thewasm32(non-threaded) variant was chosen because it doesn't requirecrossOriginIsolated.RemoteVtkScene.js: updated to probe several possible state keys and handle both the old plain-string format and the new object format when resolving the WASM asset URL, so the client keeps working regardless of whichtrame_vtklocalversion is installed.Addresses #126