Demo locks up after first time

[stacksmith]

@joachifm, it seems that destroying the web-view object screws something up, requiring a complete reload. Not destroying the webview (removing it from the window container and abandoning it - or reusing it for next time) makes things work again.

I know it's an old project, but could you clarify how to manage the lifespan of a web-view properly?

[joachifm]

Sorry, I can't really recall many details. This is a thin wrapper around the C library so I don't know how much is really due to the binding itself.

[Ambrevar]

I can reproduce, I'll try to fix it. If anyone else has a good idea how things work with CFFI / GTK / WebKit, please share your insights!

[Ambrevar]

@stacksmith Can you provide an example that works for you?

[Inc0n]

I think I am encountering some similar issues, I am using SBCL. Just running the example code, if I quit the app window, I will need to call a slime-reload-inferior-lisp to restart the environment, in order to get another app instance to appear. otherwise the main function will hang, and nothing will appear.

[Inc0n]

As of now, a workaround that I am using is to instead of leave-gtk-main, I call gtk-destroy-widget on the window. After the window closes, the repl is stuck because of join-gtk-main, which is needed, so now I can C-c C-c to abort the thread.

[Ambrevar]

Can you restart the webview after that, without restarting the REPL?

[Inc0n]

If you mean by getting the app running and webview window etc appearing, then yes. But I can't say I fully understand the consequences of not calling gtk-main-quit or the lisp version leave-gtk-main properly, hence, the hacky workaround.

It seems that this works because, it only destroy the window but not the web-view, which matches what the OP said.

[Ambrevar]

I'm using SLY and C-c C-c (sly-interrupt) does not abort the thread.

In sly-list-threads, I'm not able to kill any thread. Here is my thread list:

2  main thread                    Running 
3  Slynk Sentinel                 Running 
4  reader-thread                  Running 
9  control-thread                 Running 
1  sly-channel-1-mrepl-remote-1   Running 
6  cl-cffi-gtk main thread        Running 
7  finalizer                      Running 
8  Anonymous thread               Running 
5  slynk-indentation-cache-thread Running

Which one are you killing?

[Inc0n]

You are right actually, the gtk thread is still running on my side too. Hmmm I automatically assume, when C-c C-c shows one of the option to abort thread aborts gtk thread, it seems we would have to call leave-gtk-main to do so.