MacOS soft-close notification

[Emiliano Heyns]

On MacOS, "closing" apps by clicking the red close button leaves apps running in a weird semi-closed state; can I get a notification that Zotero has been closed this way? I need to close DB connections and stuff so that I can re-open them when the user "starts" Zotero again.

[Emiliano Heyns]

On Saturday, January 6, 2018 at 12:25:21 AM UTC+1, Emiliano Heyns wrote:

On MacOS, "closing" apps by clicking the red close button leaves apps running in a weird semi-closed state; can I get a notification that Zotero has been closed this way? I need to close DB connections and stuff so that I can re-open them when the user "starts" Zotero again.

Can I emulate this soft-close behavior on Linux? I have access to a mac but it's a pretty slow machine. Developing on Linux would be much better for me. 

[Dan Stillman]

All that's closing is the main window. Zotero keeps running normally in
the background — all DB connections, etc., stay open, and the same
should apply to your code, since items can still be saved. When the main
window is reopened, Zotero initializes the Zotero pane again
(zoteroPane.js/overlay.js code), but it's not starting up again
(zotero.js code). This isn't much different from how multiple windows
used to work in Firefox. It sounds like you're just initing on window
code instead of application code.

There's not currently an equivalent on Windows or Linux (though there
might be in the future if we support minimizing to the system tray on
Windows).

[Emiliano Heyns]

I init in the "onload" called from my overlay of zoteropane. Should I be using a different init trigger?

[Dan Stillman]

On 1/8/18 6:16 PM, Emiliano Heyns wrote:
> I init in the "onload" called from my overlay of zoteropane. Should I be using a different init trigger?
>

The overlay is window code, so that's not the place to set up DB access.
(That would be the place to set up window modifications.) You should
just be waiting on schemaUpdatePromise.

[Emiliano Heyns]

I am waiting on schemaUpdatePromise, but by what route can I kick off that wait? I've always used the overlay load as the entry point -- if there's a better one I'd be happy to change over. 

[Emiliano Heyns]

I known about these entry points, but BBT uses (as many extensions do) XUL overlays; those can't be used in bootstrapped extensions, but bootstrapped extensions are to my knowledge the only ones that are actively kicked of from an function entry point. Moving BBT to bootstrapped is not a trivial change -- I really can't do another port. at this stage.

[Emiliano Heyns]

(and loadoverlay is not a good workaround). 

[Dan Stillman]

On 1/8/18 7:42 PM, Emiliano Heyns wrote:

I known about these entry points, but BBT uses (as many extensions do) XUL overlays

Ah, got it. OK, yes, you can start waiting on schemaUpdatePromise from the overlay, but you just don't need to init global stuff more than once. As long as you're not storing global state on the window object, the window's closing shouldn't affect anything, and if the window reopens it should be a no-op (other than any window modifications you're doing).

[Emiliano Heyns]

That's what I thought I did. Ah well, at least I'm not structurally off then. I'll just need to figure out why it's re-running the db init in that case.

[Dan Stillman]

On 1/9/18 2:14 AM, Emiliano Heyns wrote:
> That's what I thought I did. Ah well, at least I'm not structurally off then. I'll just need to figure out why it's re-running the db init in that case.

If you're just doing the equivalent of schemaUpdatePromise.then() in the
overlay onload, it will run your init code again every time the window
opens, because that promise is already resolved and will immediately run
the .then(). Easiest solution is just to store a variable in global
state and skip initialization when that's set.

[Emiliano Heyns]

I already mostly do the latter. But I have a lead now where perhaps I don't.