desktop mode renders a blank window

[gsal]

So, I have a small trame-paraview app running just fine, at least when rendered using the browser; but, when I switch from main() to main(exec_mode="desktop"), all I get is a blank standalone window.

The debug messages in the terminal are as follows:

DEBUG:asyncio:Using selector: EpollSelector
INFO:root:awaiting runner setup
INFO:root:awaiting site startup
0
INFO:root:Print WSLINK_READY_MSG
INFO:root:Schedule auto shutdown with timout 300
INFO:root:awaiting running future
INFO:aiohttp.access:127.0.0.1 [08/Sep/2023:23:46:41 +0000] "GET /index.html HTTP/1.1" 200 236 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/5.15.2 Chrome/83.0.4103.122 Safari/537.36"

Any ideas what may be happening?

I am using the following:
Rocky 9
conda environment
Python 3.11.5
trame 2.5.2
paraview 5.11.1
pywebview 4.3.3

[jourdain]

What is the command line you are running? Also the "desktop" mode can be triggered when adding the --app argument without any code change.

[gsal]

As suggested in the docs, I looked into the cookiecutter bundle desktop example and all it does is import multiprocessing and then simply call my main with the desktop argument; so, I skipped the wrapper and added that to my main:

import multiprocessing

from frontend.ui import create_engine

def main(server=None, **kwargs):
    engine = create_engine(server)
    engine.server.start(**kwargs)

if __name__ == "__main__":
    multiprocessing.freeze_support()
    # main()
    main(exec_mode="desktop")

So, I have tried all 4 combinations, with and without exec_mode=desktop argument; and, with and without --app command line argument.

[jourdain]

Still no command line... ParaView setup can be tricky. Understanding how you built your venv and how you are running your code is key.

Just to be sure, did you try a trivial (no dependency) trame example and did the --app worked for it?

[gsal]

Sorry and thanks for your insistence.

I am using a conda environment, built with:

conda create -n <ename> python=3.11.* trame==2.5.2 paraview 
conda activate <ename>
pip install pywebview[qt]

I have run my program with the following commnands:

export PYWEBVIEW_GUI=qt
python   main.py 
python   main.py --app
pvpython main.py 
pvpython main.py --app
pvbatch  main.py 

The browser based runs do fine; the desktop based one, do not.

I just downloaded an example and will be doing some testing with that one, side-by-side my program. Additionally, I have access to Centos7 machines; I am going to test there too and see if it is a different experience than in Rocky9.

[jourdain]

Ah, I guess I'll have to see why conda is failing here... (I usually use venv and downloaded ParaView)

Thanks for providing those steps so I can reproduce that issue locally.

[jourdain]

I think you are getting a conflict between the Qt of ParaView (from conda) and the Qt you get from pip with pywebview.

[gsal]

Hhhhmmm, that's a pickle...there is no pywebview in conda and there is no paraview in pip......so, if this is something that is supported and supposedly functional, maybe it is just a matter of having some specific version of each?

[gsal]

Testing, testing, 1, 2, 3

So, my program is based on Trame tutorials and samples, it takes advantage of ParaView as a friendlier (less complicated) interface to VTK.

My program uses ParaView; desktop mode:

• it does NOT run in Centos7
• it does NOT run in Rocky9

Found a Trame example online, downloaded it:

• it does run in Centos7
• it does NOT run in Rocky9
• but, I noticed the example does not use ParaView; instead,
• it seems they deal directly with VTK.

I am not sure what THAT answers:

• based on centos7 runs, it ooks like ParaView is getting in the way of something
• based on the VTK example runs, it looks like there is something missing in Rocky9:
  • we have had Centos7 for over 6 years and it is our current production platform
  • IT is currently working towards deploying Rocky9

[jourdain]

Well, you can use the plain ParaView (pvpython) and use a virtual-env (venv) to expend it. So the Qt be only in the venv if you grab a headless paraview (osmesa/egl).

[jourdain]

Is the "not running" in Rocky9 related to a rendering issue/limitation? If so, that could be related to the GPU driver setup.
Or is it related to network limitation (firewall / net interface)?

[gsal]

Well, the non-ParaView, VTK-based sample that runs on centos7...
...in Rocky9, the messages in the terminal stop at the first aiohttp output line:

python app.py  --app --debug
DEBUG:asyncio:Using selector: EpollSelector
INFO:root:awaiting runner setup
INFO:root:awaiting site startup
INFO:root:Print WSLINK_READY_MSG
INFO:root:Schedule auto shutdown with timout 300
INFO:root:awaiting running future
INFO:aiohttp.access:127.0.0.1 [12/Sep/2023:19:50:43 +0000] "GET /index.html HTTP/1.1" 200 236 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/5.15.2 Chrome/83.0.4103.122 Safari/537.36"

[jourdain]

Does the following works on any of your system

python3.9 -m venv venv
source ./venv/bin/activate
pip install -U pip
pip install trame trame-vuetify trame-vtk pywebview

python -m trame.app.demo --app

[gsal]

Exactly like that, it does not
I get a GTK error
After I do export PYWEBVIEW_GUI=qt
I get a Qt error
After I do pip install -U pywebview[qt]
I get:

• In Centos7, the running application
• In Rocky9, just the blank window with the following debug statements:

DEBUG:asyncio:Using selector: EpollSelector
INFO:root:awaiting runner setup
INFO:root:awaiting site startup
INFO:root:Print WSLINK_READY_MSG
INFO:root:Schedule auto shutdown with timout 300
INFO:root:awaiting running future
INFO:aiohttp.access:127.0.0.1 [12/Sep/2023:22:15:32 +0000] "GET /index.html HTTP/1.1" 200 235 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/5.15.2 Chrome/83.0.4103.122 Safari/537.36"

[jourdain]

Does any of the pywebview example works on your system (meaning no trame)?

[gsal]

Well, well, well...

• I placed centos7 and rocky9 side-by-side
• Tried 3 pywebview examples
• On both systems, the sample apps come up and seem to do what it was intended: pop a dialog, hide the window, etc.
• But
  • in centos7, the main window of the app shows content (advertising pywebview, user-agent, support)
  • in rocky9, the main window of the app remains blank

[gsal]

Since this is now proving to be a pywebview-linux problem, I went to the pywebview github discussions and there are quiet a few bugs/reports of this blank screen.....not that it is of any consolation, but I guess I am not alone.

[jourdain]

If the app bundling is important, another approach that is slightly more involving would be to use tauri for which we have a couple of examples. We may have to do some code cleanup/update to properly leverage the latest version of tauri, but the general gist should remain the same. Although, I've never bundles ParaView into such infrastructure, so there will still be some exploration. ;-)