Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

destroy is not working #5

Open
ttytm opened this issue Sep 10, 2023 · 6 comments
Open

destroy is not working #5

ttytm opened this issue Sep 10, 2023 · 6 comments
Assignees

Comments

@ttytm
Copy link

ttytm commented Sep 10, 2023

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 SteffenL transferred this issue from webview/webview Sep 10, 2023
@SteffenL
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Author

ttytm commented Sep 12, 2023

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
Copy link
Contributor

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
Copy link
Author

ttytm commented Sep 22, 2023

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
Copy link

I am also experiencing this...
#13

@SteffenL SteffenL self-assigned this Feb 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants