search

Hammerspoon / hammerspoon

Staggeringly powerful macOS desktop automation with Lua
http://www.hammerspoon.org
MIT License
12.07k stars 583 forks source link

Close callback for hs.webview #1259

Closed latenitefilms closed 7 years ago

latenitefilms commented 7 years ago

Would it be possible to add a "on close" callback function to hs.webview?

I'm currently using watchers to achieve the same thing, but it's... buggy, currently.

Thoughts @cmsj & @asmagill ?

cmsj commented 7 years ago

Seems like a good idea to me

latenitefilms commented 7 years ago

Maybe something we can add to the 0.9.53 wish list?

asmagill commented 7 years ago

Do you want to be able to abort the close or just be notified when it happens?

latenitefilms commented 7 years ago

Notify when it happens without needing a window watcher would be great.

latenitefilms commented 7 years ago

Thanks so much for adding this! Very much appreciated!

Would it be overkill to also add a "hasMoved" and "gotFocus" callback too? I realise you can do this with hs.window object, but might be easier/better to have this functionality "built-in"? Thoughts?

asmagill commented 7 years ago

Anything that NSWindowDelegate has a method for could be tied to a callback... of course we can only do this for windows that Hammerspoon creates, so at present that means only webviews (in theory drawings and the console as well, but for drawings we hide the window decorations and the console is created independent of the Hammerspoon/Lua environment).

The question becomes -- is doing so more useful/reliable/programable than using the existing window/application watcher that relies on the accessibility functions... they can apply to any application's windows, though admittedly the interface isn't as intuitive as it could be in some places.

Closing the webview makes sense (to me at least) because webview's don't delete themselves on garbage collection automatically... you have to delete them through code... this choice was made because allowing the system to collect the webview when it closes means you have to completely recreate it if all you want to do is temporarily hide it... it was a question of persistence and the time it takes to create, retrieve, and render the view. So if you truly do want the webview to release its resources when the user closes it, the only way to know this is if we have the callback just added.

This is a long way of asking what is the use case for the additional messages and why/how do the current features of the application and window watchers fail to meet this? Since this would be unique to the webviews, what's the justification for a different set of commands?

I will say that in the long term (so long I don't even have a roadmap yet) I envision adding some modules that allow other view types -- editable text/RTF windows, media playback, maybe a python/tkinter like module for creating input dialogs, etc. and at that point merging webview, canvas/drawing, and possibly even the console itself under this umbrella. At that point, having "methods for what we create" and "methods for what we don't" makes more sense, so I'm not saying I disagree with the idea, just that, to me, it's maybe premature since only webview would benefit at the moment. But I'm willing to be convinced otherwise...

latenitefilms commented 7 years ago

I issue I have with hs.webview:hswindow() is that it's not created instantly after you create a hs.webview so you need to use a hs.timer. I've also found on really complex scripts with lots of watchers and timers, there can be a bit of a delay in this callback triggering. Having callbacks built into hs.webview would just make the hs.webview more reliable for me. We're currently using hs.webview for all our user interfaces, which works great, but having these callbacks built in would make things even better.

latenitefilms commented 7 years ago

Case in point:

https://github.com/Hammerspoon/hammerspoon/blob/master/extensions/doc/hsdocs/init.lua#L142