Plater needs a new script/mod event: Uninitialization
Arcitec opened this issue · 7 comments
-
Initialization: Triggers when the mod first starts up, and every time the user disables/re-enables the mod.
-
Constructor: Triggers when nameplates first appear on the screen.
-
Destructor: When the user disables the mod, this triggers for all visible plates. If no plates are visible, this event doesn't trigger at all.
There is, from what I can see, no real way to do a guaranteed "this code will run when the user disables my addon" in Plater.
The destructor is not reliable, since it doesn't run at all if no plates are visible.
Therefore, it prevents programmers from creating Plater mods that do complex setup and teardowns. In my case, I'm hooking into another addon, leeching its data, presenting it in Plater instead. If the user disables my Plater mod, I need to restore the original 3rd party addon's behavior. But I can't do that, because there is no reliable event for it.
I even tried going through all of Plater's source code, looking for a way to loop through the list of compiled and loaded mods and checking which ones are enabled. That is kind of doable, but extremely hacky.
What would really improve things here is if Plater has a new event:
- Uninitialization: Triggers whenever the mod is disabled (whether via auto-unload from load conditions, or via the user manually disabling the mod).
@cont1nuity Still testing, and everything still seems perfect!
I forgot to say that this message seems a bit unclear:
["Deinitialization"] = "Executed once for the mod when it is unloaded. Used to de-initialize the global mod environment 'modTable' and the mod for the last time.",
It makes it sound like deinitialization only runs once, ever. And that it only runs when the mod is being unloaded for the last time.
From what I can see, it always runs every time the mod is unloaded (whether automatically via load-conditions or manually unloaded).
I notice, however, that the "execute once" language is used in initializer too: ["Initialization"] = "Executed once for the mod when it is compiled. Used to initialize the global mod environment 'modTable'.",
Similarly confusing language is used for the Constructor: ["Constructor"] = "Executed once when the nameplate run the hook for the first time.\n\nUse to initialize configs in the environment.\n\nAlways receive unitFrame in 'self' parameter.",
Perhaps something like this is clearer then?
["Initialization"] = "Executed once for the mod every time it is compiled (loaded). Used to initialize the global mod environment 'modTable'.",
["Deinitialization"] = "Executed once for the mod every time it is unloaded. Used to de-initialize the global mod environment 'modTable' and the mod.",
["Constructor"] = "Executed once when the nameplate runs the hook for the first time after every initialization.\n\nUse to initialize configs in the environment.\n\nAlways receives unitFrame in 'self' parameter.",
As a programmer reading the docs, those descriptions would be a lot clearer. I've had to do a lot of manual testing prior to this too, until I figured out when the different hooks run. I even made my own mod-code-comments docs for every event just because it was so confusing (which you can see an example of over here). 😄 So if the descriptions can become a bit clearer, that would be a win. Right now I feel like they're a bit misleading depending on how people reads things like "executed once" and "for the last time".
This is related to the "Mod Destructor's modTable is nil" bug:
Proposed Plater algorithm when a mod becomes disabled:
- Trigger destructors for all visible frames, with modTable provided. (This improvement is described in #104.)
- Trigger uninitialization script for the mod, with modTable provided.
- Finally, Plater erases/forgets the modTable and disables the mod.
@cont1nuity Thank you so much. I am testing the Deinitialization script now and it's working perfectly. It receives the modTable and I'm able to unhook from the 3rd party addon in there, I love it so much! ;-)