Is your feature request related to a problem? Please describe.

The connection lost screen after killing/relaunching the server appears as though it is trying to reconnect with the spinning icon:

But it actually does nothing (as far as I can tell). So I have to refresh the page.

Describe the solution you'd like

I'd like this to attempt to reconnect to my app and load when it's ready or not using this sort of misleading graphic

Simple demo to use the Vue-Router in Trame to create multi-page applications.

I suggest two ways to add a new route. layout.add_route and layout.with_route. See the example.

Any more/other suggestions?

(Depends on this PR in py-web-vue: https://github.com/Kitware/py-web-vue/pull/11)

Describe the bug Hi, I found a bug, but it doesn't have to happen on every machine any times, Sometimes it works, sometimes throw this: Can not forward events without a current renderer on the interactor. I has test many times many way by variable of control, but still can not find a pattern. As I know, one colleagues of mine run the program in terminal, never throw this bug. But another colleague of mine need run the program by java thread, this bug happend by this way, but sometimes it works. So we try to run the program in the same machine in terminal, as my first colleagues, he never got this bug, but it still throw in our machine!

I google this message, found this.

But I can not imagine why getCurrentRenderer() dont work well. So, I came here, hoping for some possible leads, maybe can help.

sorry for my english, I come from china. I hope I've described it correctly

Code

# just same as examples

Screenshots

Platform: Windows 10

Trame:

• [*] Version 2.x

Device:

• [*] Desktop
• [ ] Mobile

OS:

• [*] Windows

Browsers Affected:

• [*] Chrome

v-on and v-bind were not mapped from python keys to vue keys, which made it not possible to implement and example like this:

with vuetify.VMenu():
    with vuetify.Template(v_slot_activator="{ on, attrs }"):
        with vuetify.VBtn(icon=True, v_bind="attrs", v_on="on", v_on_click="test"):
            vuetify.VIcon("mdi-dots-vertical")
    with vuetify.VList(), vuetify.VListItem(
        v_for="(item, i) in menu_items",
        key="i",
        value=["item"],
    ):
        vuetify.VBtn(
            "{{ item }}",
            click=(print_item, "[item]"),
        )

Note: The list of v_on_names does not cover all possibilities yet. Since you can chain most of the keywords in different ways, we should probably build the list programmatically. (e.g. v-on:click.self.stop.prevent etc.)

Is your feature request related to a problem? Please describe.

The vtk widgets module should be named something else as only serious VTK power users import vtk-python the proper way like from vtkmodules.vtkRenderingCore import vtkRenderWindow.

Most (like 99% of) users simply use import vtk and that's not going anywhere. Having from trame.widgets import vtk in the examples where you want users to also use VTK-python is setting new users up for failure as the two namespaces will conflict.

Further, VTK is an overwhelming library for new users, so seeing from trame.widgets import vtk, they will likely think that vtk is the actual vtk where they can get classes like vtkPolyData (actually even I thought that when first trying trame).

Describe the solution you'd like

The vtk widgets module should be named something other than vtk, like vtk_widgets

from trame.widgets import vtk should be something else, perhaps from trame.widgets import vtk_widgets

Describe alternatives you've considered

An alternative is to have all the examples use an alias: from trame.widgets import vtk as vtk_widgets

Additional context

I'm having to carefully modify this import statement in every trame app I create from the examples (I use the examples as templates which I expect most others do as well)

The trame apps will be able to mount a special "deploy" directory into the container and start a service for multiple clients to connect to and individually run the trame app.

After excuting the click_test2() function, I can still see the actor in the browser. Refreshing the web page could erase the actor and browser Cache might be the reason. How to solve the problem?

Thanks

Both VtkRemoteView and VtkLocalView have a "ref" parameter, but VtkRemoteLocalView does not.

VtkRemoteLocalView is also missing the "interactive_quality" parameter from vtkRemoteView.

The commit messages are pasted below:

fix(docker): add additional build options

This allows the user to separate out building the venv, launcher, and www.

The default behavior is that all will build if they do not exist. If they do exist, then they will not be built.

However, the user can now select some options via a TRAME_BUILD environment variable. If this string contains (single or any combination of) "venv", "launcher", or "www", then those respective parts will be re-built, even if they already exist.

Additionally, a "no_www" can be specified in the TRAME_BUILD environment variable, which indicates to skip the www generation, even if it does not exist.

fix(docker): add ability to replace USE_HOST

If a TRAME_USE_HOST environment variable is defined, then this will replace USE_HOST in the final copy of the launcher json file.

If TRAME_USE_HOST contains ://, then this will replace ws://USE_HOST instead.

Continuation of #145!

I am currently trying to run trame/pv-visualizer on our JupyterLab instance using a JupyterServerProxy After starting the proxy, the webpage is loading properly for a few seconds. But after that, the UI can only be seen for a frame before the connection is lost.

[I 2022-11-24 23:40:44.960 SingleUserNotebookApp handlers:446] Trying to establish websocket connection to ws://localhost:54753/ws
[I 2022-11-24 23:40:44.963 SingleUserNotebookApp handlers:453] Websocket connection established to ws://localhost:54753/ws

Loguru caught a signal: SIGSEGV
Stack trace:
85            0x4006ce _start + 46
84      0x14dd31dbbcf3 __libc_start_main + 243
83      0x14dd3363fc29 Py_BytesMain + 41
82      0x14dd33660166 Py_RunMain + 326
81      0x14dd3364cb0c PyRun_SimpleStringFlags + 60
80      0x14dd335cd424 PyRun_StringFlags + 164
79      0x14dd3364fc57 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x1b9c57) [0x14dd3364fc57]
78      0x14dd33651974 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x1bb974) [0x14dd33651974]
77      0x14dd335b129b PyEval_EvalCode + 27
76      0x14dd335b12e3 PyEval_EvalCodeEx + 67
75      0x14dd335b1341 _PyEval_EvalCodeWithName + 81
74      0x14dd335b1534 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x11b534) [0x14dd335b1534]
73      0x14dd335b4302 _PyEval_EvalFrameDefault + 7394
72      0x14dd335c168d _PyFunction_Vectorcall + 221
71      0x14dd335b1534 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x11b534) [0x14dd335b1534]
70      0x14dd335b70fd _PyEval_EvalFrameDefault + 19165
69      0x14dd335cb2aa PyVectorcall_Call + 170
68      0x14dd335cac59 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x134c59) [0x14dd335cac59]
67      0x14dd335c168d _PyFunction_Vectorcall + 221
66      0x14dd335b1534 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x11b534) [0x14dd335b1534]
65      0x14dd335b70fd _PyEval_EvalFrameDefault + 19165
64      0x14dd335cb2aa PyVectorcall_Call + 170
63      0x14dd335c168d _PyFunction_Vectorcall + 221
62      0x14dd335b1534 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x11b534) [0x14dd335b1534]
61      0x14dd335b70fd _PyEval_EvalFrameDefault + 19165
60      0x14dd335cb2aa PyVectorcall_Call + 170
59      0x14dd335c168d _PyFunction_Vectorcall + 221
58      0x14dd335b1534 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x11b534) [0x14dd335b1534]
57      0x14dd335b2b7f _PyEval_EvalFrameDefault + 1375
56      0x14dd335c168d _PyFunction_Vectorcall + 221
55      0x14dd335b1534 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x11b534) [0x14dd335b1534]
54      0x14dd335b2d29 _PyEval_EvalFrameDefault + 1801
53      0x14dd335c1923 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x12b923) [0x14dd335c1923]
52      0x14dd335b2d29 _PyEval_EvalFrameDefault + 1801
51      0x14dd335c1923 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x12b923) [0x14dd335c1923]
50      0x14dd335b2d29 _PyEval_EvalFrameDefault + 1801
49      0x14dd335c1923 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x12b923) [0x14dd335c1923]
48      0x14dd335b2d29 _PyEval_EvalFrameDefault + 1801
47      0x14dd335c1923 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x12b923) [0x14dd335c1923]
46      0x14dd335b85b3 _PyEval_EvalFrameDefault + 24467
45      0x14dd335ba75a /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x12475a) [0x14dd335ba75a]
44      0x14dd336385c6 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x1a25c6) [0x14dd336385c6]
43      0x14dd335bb8c3 _PyObject_MakeTpCall + 131
42      0x14dd229ae378 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/python3.9/lib-dynload/_asyncio.cpython-39-x86_64-linux-gnu.so(+0x8378) [0x14dd229ae378]
41      0x14dd229ac8f4 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/python3.9/lib-dynload/_asyncio.cpython-39-x86_64-linux-gnu.so(+0x68f4) [0x14dd229ac8f4]
40      0x14dd335e6032 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x150032) [0x14dd335e6032]
39      0x14dd335b4d6c _PyEval_EvalFrameDefault + 10060
38      0x14dd335e6032 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x150032) [0x14dd335e6032]
37      0x14dd335b4d6c _PyEval_EvalFrameDefault + 10060
36      0x14dd335e6032 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x150032) [0x14dd335e6032]
35      0x14dd335b4d6c _PyEval_EvalFrameDefault + 10060
34      0x14dd335e6032 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x150032) [0x14dd335e6032]
33      0x14dd335b70fd _PyEval_EvalFrameDefault + 19165
32      0x14dd335c168d _PyFunction_Vectorcall + 221
31      0x14dd335b1534 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x11b534) [0x14dd335b1534]
30      0x14dd335b2d29 _PyEval_EvalFrameDefault + 1801
29      0x14dd335c168d _PyFunction_Vectorcall + 221
28      0x14dd335b1534 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x11b534) [0x14dd335b1534]
27      0x14dd335b2d29 _PyEval_EvalFrameDefault + 1801
26      0x14dd335c1923 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x12b923) [0x14dd335c1923]
25      0x14dd335b48a4 _PyEval_EvalFrameDefault + 8836
24      0x14dd335bb8c3 _PyObject_MakeTpCall + 131
23      0x14dd335cc4a0 /p/software/juwels/stages/2022/software/Python/3.9.6-GCCcore-11.2.0/lib/libpython3.9.so.1.0(+0x1364a0) [0x14dd335cc4a0]
22      0x14dcd16fa3cd /p/usersoftware/swmanage/goebbert1/stage2022/ParaView/easybuild/juwels/software/ParaView/5.11.0-gpsmkl-2021b/lib64/python3.9/site-packages/paraview/modules/vtkPVClientWeb.so(+0x43cd) [0x14dcd16fa3cd]
21      0x14dcd16ee191 vtkPVWebApplication::StillRenderToBuffer(vtkSMViewProxy*, unsigned long, int) + 17
20      0x14dcd16eddc2 vtkPVWebApplication::StillRender(vtkSMViewProxy*, int) + 370
19      0x14dd0050c011 vtkSMViewProxy::CaptureWindow(int, int) + 81
18      0x14dd0050ba76 /p/usersoftware/swmanage/goebbert1/stage2022/ParaView/easybuild/juwels/software/ParaView/5.11.0-gpsmkl-2021b/lib/libvtkRemotingViews-pv5.11.so.1(+0x2eca76) [0x14dd0050ba76]
17      0x14dd0050b675 /p/usersoftware/swmanage/goebbert1/stage2022/ParaView/easybuild/juwels/software/ParaView/5.11.0-gpsmkl-2021b/lib/libvtkRemotingViews-pv5.11.so.1(+0x2ec675) [0x14dd0050b675]
16      0x14dd0050ae24 vtkSMViewProxy::CaptureWindowSingle(int, int) + 52
15      0x14dd0050a7a2 vtkSMViewProxy::CaptureWindowInternal(int, int) + 770
14      0x14dd0050a21a vtkSMViewProxy::StillRender() + 362
13      0x14dd04e03764 vtkPVSessionBase::ExecuteStream(unsigned int, vtkClientServerStream const&, bool) + 52
12      0x14dd04e0585b vtkPVSessionCore::ExecuteStreamInternal(vtkClientServerStream const&, bool) + 251
11      0x14dd2237257d vtkClientServerInterpreter::ProcessStream(vtkClientServerStream const&) + 29
10      0x14dd223720ed vtkClientServerInterpreter::ProcessOneMessage(vtkClientServerStream const&, int) + 221
9       0x14dd22371fae vtkClientServerInterpreter::ProcessCommandInvoke(vtkClientServerStream const&, int) + 1214
8       0x14dcfd8a3950 vtkPVRenderViewCommand(vtkClientServerInterpreter*, vtkObjectBase*, char const*, vtkClientServerStream const&, vtkClientServerStream&, void*) + 6608
7       0x14dd0043c977 vtkPVRenderView::StillRender() + 103
6       0x14dd00449fc5 vtkPVRenderView::Render(bool, bool) + 2373
5       0x14dd0477b920 vtkXOpenGLRenderWindow::Render() + 32
4       0x14dd046ceb99 vtkOpenGLRenderWindow::Render() + 169
3       0x14dd0572ed68 vtkRenderWindow::Render() + 584
2       0x14dd0436e779 vtkXRenderWindowInteractor::Initialize() + 217
1       0x14dd07cf689b XSync + 11
0       0x14dd32ad9ce0 /usr/lib64/libpthread.so.0(+0x12ce0) [0x14dd32ad9ce0]
(  16.615s) [paraview        ]                       :0     FATL| Signal: SIGSEGV
/p/home/jusers/windgassen1/juwels/Nek/proxy-venv/lib/python3.9/site-packages/jupyter_trame_proxy/share/launch_trame.sh: line 20: 16088 Segmentation fault      python -c "from pv_visualizer.app.main import main; main(port=$1)"
2022-11-24 23:40:47,646 - SingleUserNotebookApp - ERROR - Uncaught exception GET /user/j.windgassen_at_fz-juelich.de/vf0a98375c2247efb8baa17a2ed3d3ce/trame/ws (79.232.197.221)
HTTPServerRequest(protocol='https', host='jupyter-jsc.fz-juelich.de', method='GET', uri='/user/j.windgassen_at_fz-juelich.de/vf0a98375c2247efb8baa17a2ed3d3ce/trame/ws', version='HTTP/1.1', remote_ip='79.232.197.221')
Traceback (most recent call last):
  File "/p/software/juwels/stages/2022/software/Jupyter/2022.3.4-gcccoremkl-11.2.0-2021.4.0/lib/python3.9/site-packages/tornado/websocket.py", line 1086, in write_message
    fut = self._write_frame(True, opcode, message, flags=flags)
  File "/p/software/juwels/stages/2022/software/Jupyter/2022.3.4-gcccoremkl-11.2.0-2021.4.0/lib/python3.9/site-packages/tornado/websocket.py", line 1061, in _write_frame
    return self.stream.write(frame)
  File "/p/software/juwels/stages/2022/software/Jupyter/2022.3.4-gcccoremkl-11.2.0-2021.4.0/lib/python3.9/site-packages/tornado/iostream.py", line 530, in write
    self._check_closed()
  File "/p/software/juwels/stages/2022/software/Jupyter/2022.3.4-gcccoremkl-11.2.0-2021.4.0/lib/python3.9/site-packages/tornado/iostream.py", line 1019, in _check_closed
    raise StreamClosedError(real_error=self.error)
tornado.iostream.StreamClosedError: Stream is closed

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/p/software/juwels/stages/2022/software/Jupyter/2022.3.4-gcccoremkl-11.2.0-2021.4.0/lib/python3.9/site-packages/tornado/websocket.py", line 635, in _run_callback
    result = callback(*args, **kwargs)
  File "/p/software/juwels/stages/2022/software/Jupyter/2022.3.4-gcccoremkl-11.2.0-2021.4.0/lib/python3.9/site-packages/jupyter_server_proxy/handlers.py", line 160, in on_message
    self.ws.write_message(message, binary=isinstance(message, bytes))
  File "/p/software/juwels/stages/2022/software/Jupyter/2022.3.4-gcccoremkl-11.2.0-2021.4.0/lib/python3.9/site-packages/tornado/websocket.py", line 1500, in write_message
    return self.protocol.write_message(message, binary=binary)
  File "/p/software/juwels/stages/2022/software/Jupyter/2022.3.4-gcccoremkl-11.2.0-2021.4.0/lib/python3.9/site-packages/tornado/websocket.py", line 1088, in write_message
    raise WebSocketClosedError()
tornado.websocket.WebSocketClosedError

I tried digging around in the code for an afternoon and finding out, where it goes south, but couldn't find anything. I was previously using ParaView 5.9 and Python 3.8 (i modified the code a bit to run there) and blamed it on those versions, but we just installed ParaView 5.11 and this error still occurs there with Python 3.9

Describe the bug

On the latest version of trame (1.19.1), the VTK view does not work as on version 1.18.0. The viewer doesn't show up in the UI and I am getting an error from vtkmodules saying:

ERROR:root:Exception raised
ERROR:root:Exception('no view provided: -1')
ERROR:root:Traceback (most recent call last):
  File ".../lib/python3.8/site-packages/wslink/backends/aiohttp/__init__.py", line 371, in onMessage
    results = await asyncio.coroutine(func)(*args, **kwargs)
  File "/usr/lib/python3.8/asyncio/coroutines.py", line 124, in coro
    res = func(*args, **kw)
  File ".../lib/python3.8/site-packages/vtkmodules/web/protocols.py", line 425, in imagePush
    sView = self.getView(options["view"])
  File ".../lib/python3.8/site-packages/vtkmodules/web/protocols.py", line 80, in getView
    raise Exception("no view provided: %s" % vid)
Exception: no view provided: -1

I think it may be because of this commit? https://github.com/Kitware/trame/commit/ad23c4d88884319c05391b7e195cd8bcc85f9738

To Reproduce

Minimal code to reproduce:

import vtk
from trame import change, state
from trame.layouts import SinglePageWithDrawer
from trame.html import vuetify
from trame.html.vtk import VtkRemoteLocalView

# -----------------------------------------------------------------------------
# VTK pipeline
# -----------------------------------------------------------------------------

renderer = vtk.vtkRenderer()
renderWindow = vtk.vtkRenderWindow()
renderWindow.AddRenderer(renderer)

renderWindowInteractor = vtk.vtkRenderWindowInteractor()
renderWindowInteractor.SetRenderWindow(renderWindow)
renderWindowInteractor.GetInteractorStyle().SetCurrentStyleToTrackballCamera()

# -----------------------------------------------------------------------------
# Callbacks
# -----------------------------------------------------------------------------
@change("viewMode")
def update_view(viewMode, flush=True, **kwargs):
    html_view.update_image()
    if viewMode == "local":
        html_view.update_geometry()
        if flush:
            # can only flush once protocol is initialized (publish)
            state.flush("viewScene")

# -----------------------------------------------------------------------------
# GUI
# -----------------------------------------------------------------------------

html_view = VtkRemoteLocalView(renderWindow, namespace="view")

def on_ready(**kwargs):
    update_view("local", flush=False)
    html_view.update()
    renderer.ResetCamera()

layout = SinglePageWithDrawer("Trame App", on_ready=on_ready)

with layout.content:
    vuetify.VContainer(
        fluid=True,
        classes="pa-0 fill-height",
        children=[html_view],
    )

if __name__ == "__main__":
    layout.start()

serializeInstance in Web/Python/vtkmodules/web/render_window_serializer.py of VTK uses print statements to issue warnings. We should patch this in trame to use warnings so as to have better outputs than:

Further, I'm wondering if we want to add a flag to suppress these warnings?

Trame should have a CLI for more easily running scripts and for documenting the available options when running. I highly recommend gaining inspiration from streamlit's CLI so that trame scripts do not have to have __main__ catch and can have better support and auto refresh when running.

This would likely help with #119

I don't think this would be a big ask as there is already args parsing happening.

As of now pip install trame installs the following packages:

trame-client
trame-components
trame-deckgl
trame-markdown
trame-matplotlib
trame-plotly
trame-router
trame-server
trame-simput
trame-vega
trame-vtk
trame-vuetify
trame-rca

Installing trame-client, trame-server makes totally sense as they are a fundamental requirement of trame, but maybe we can have the others in and extras_require. Especially trame-vtk is pretty hefty since it installs vtk with >300MB.

I understand that for showing the tutorials and demos it is pretty nice to have "just do pip install trame and it works", but maybe having a "just do pip install trame[vtk] and it works" isn't that bad.

The trame backend is now developed in python, while the front-end vue code is defined together in a python project.

For modern web development, flexibility and extensibility are necessary. In the case that vtk.js does not support all C++ functions and also does not support unstructured grid, separating trame front-end and back-end is the most convenient and perfect solution.

So I'm looking forward to the version that trame separates code of client and server.