search

webview / webview_go

Go language bindings for the webview library.
MIT License
176 stars 27 forks source link

`destroy` is not working #5

Open ttytm opened 10 months ago

ttytm commented 10 months ago

Doc: // Destroys a webview and closes the native window.

package main

import "github.com/webview/webview_go"

const html = `<html style="background: #1B2845; color: #eee;">
<button onclick="window.exit();">Exit</button>
</html>`

func main() {
    w := webview.New(true)
    w.SetTitle("Bind Example")
    w.SetSize(480, 320, webview.HintNone)

    w.Bind("exit", func() {
        w.Dispatch(func() {
            w.Destroy()
            // w.Terminate() // Works. But I'd like to keep the main loop.
            println("Should be destroyed.")
        })
    })

    w.SetHtml(html)
    w.Run()
}
gcc (GCC) 13.2.1 20230801
clang version 16.0.6
go version go1.21.0 linux/amd64
SteffenL commented 9 months ago

I can't see that any of the destructors in the core library make an attempt at closing the window so this may affect more platforms and possibly all of them.

I've confirmed that the documentation in the core library also states that the window will be closed, so if that doesn't happen then this is a bug in the core library.

The issue was moved here because the Go binding moved.

SteffenL commented 9 months ago

I would like to clarify something now that I am looking a bit more into this.

In the example code you provided, the library manages the main loop, but by calling Destroy() then you're signaling that you want to tear down the webview instance and everything it owns while the main loop managed by the same webview instance is still running.

Please explain in more detail what you're trying to do, how it isn't working according to your expectations and the solution you're seeking.

ttytm commented 9 months ago

Yes it's an issue with the core lib. I thought to include the reproduction in Go as it felt the simplest.

The Idea was to close the window but to be able to keep the background process running and to re-create a window on demand. To save time of initializing the application, loading configurations, caches, setting up a localhost / websocket server etc.

SteffenL commented 9 months ago

Would being able to control the visibility of the window be a satisfactory solution? That way you could hide/show the window instead of closing and recreating it.

ttytm commented 9 months ago

Yes Hide/Show would help. A useful functionality to have in general 👍.

Additionally, a function to set the window as utility window would then help to fully achieve what is desired in my use-case. As the program doesn't need an app icon in the launcher. E.g. set_type_hint(Gdk.WindowTypeHint.UTILITY) for gtk windows and NSApp.setActivationPolicy(.accessory) for NSWindows.

precisionpete commented 9 months ago

I am also experiencing this... https://github.com/webview/webview_go/issues/13