Intrinsic (template) reusability in addons
 

Gellow statement sounds like the intrinsic would be useful in more then one addon but I'm wondering how it might be packaged/versioned for this.

Has anyone seen any discussion, have thoughts, about if/how intrinsics and or templates might be able to be used/versioned across multiple addons? I have a generic widget created as an intrinsic that would be usable (maybe even useful) across multiple addons not just my own. It's created as an intrinsic because it needs the scripting additions that templates and lua don't have (although it's crippled as a base widget for XML because of the scripting limitations there, "Frame does not have an OnValueChanged script".

Templates you can work around by creating one or more widget factories but intrinsics are explicitly XML only. You can't embed the xml in more than one addon because the "Node Already Exists" error.
If you make it a standalone addon you run afoul of addons that package it overwriting a new version with an older one.

So, other than a "get it right the first time and pray a Blizzard change doesn't bugger it up" or create a new addon for each version, can anyone think of (know of) a mechanism that might cover this?

LibStub is seemingly not made for this.

For the multiple node errors I can see something like a "noexists" or "once" attribute to ignore multiple instantiations (along with my other some day suggestion, a "scripts" attribute scripts="OnValueChanged, ...") might be nice but versioning would still be a problem.

Being able to create intrinsics with CreateFrame would be an answer to both problems (but not adding/hooking "unknown" scripts for XML use) but until then...?

I've never used intrinsics, knowingly. I ususally just grab code from another addon for a frame I want to reuse and rename it for the addon. But I have been using template xmls recently so I can just copy and paste a template to get most of the visuals so I only need to code the functionality.

That's the bit I'm trying to avoid as the widget on it's own is just as generic as an editbox or statusbar etc.

Actually it is essentially a slider that just goes around in circles (the bits inside the circles in the image) that I've been tinkering with it pretty much since intrinsics became a thing but this problem using it keeps cropping up .

It seems to limit intrinsics to everyone but Blizzard as a one addon, one use thing because of the nature of addons being able to survive updates and xpacs where Blizz. code doesn't.



Maybe someone smarter than I will figure it out (or has already) and I can use theirs if I ever finish an addon that uses these things (yeah yeah, just use a slider and...no! ;)).

Just curious - how do intrinsics help with rotating textures?

FWIW other than an external addon dependency, sticking to strict semver, and having the major version in the name (like Circle-1), I don't have a better suggestion, something like LibStub just can't help because WoW is loading any XML/Lua files if they are listed in toc and you can't prevent it.

They don't. The intrinsic here is a circular mouse driven "slider". Drag the mouse around the rotator and bits move, values change depending on settings. The compas intrinsic on the right rotates the globe image showing degrees rotated, the others change the values shown.

The intrinsic puts it all together visually like a template but, unlike templates, allows pre/post scripts. When instantiated in lua via CreateFrame also allows you to add scripts not native to the widgets used (XML needs to know/complain about scripts before OnLoad happens hence the desire for a scripts="..." attribute).

The external depenency only works until you have need of a new version/update and the different name for each version gets untenable pretty quickly, hence the thread hoping someone with more of a clue than I has has a solution if it's possible.

I made another intrinsic element called "AutoScrollFrame" (that I'm retiring in favor of Blizzard's Dragonflight-improved ScrollBox/ScrollView/DataProvider model) that I use across multiple addons simply by naming them differently:

<Frame name="StashAutoScrollFrame" mixin="StashAutoScrollFrameMixin" flattenRenderLayers="true" intrinsic="true">

vs

<Frame name="RematchAutoScrollFrame" mixin="RematchAutoScrollFrameMixin" flattenRenderLayers="true" intrinsic="true">

As you've noted XML is not really suited for versioning.

I did make a non-intrinsic version of AutoScrollFrame in all Lua with primitive versioning (still used in AddonUsage) but it was really unappealing to me. Even moderately complicated all-Lua UIs remind me of old WinForms code when the hierarchical nature of XML (or XAML compared to WinForms) seems more natural and intuitive for parent/child relationships.

I was guessing it would remain nothing more than interesting idea but too complicated in reality. Maybe as a "just for my own addons" thing but even that seems a bit messy and accident prone once you go beyond one addon...

Having all the geometry and math skills of a modern day labradoodle it's been fun just getting it working although even a side glance at the code by anyone with the skills I'm sure would most likely lead to vigorous head scratching :eek:.

Given it can't be used in XML atm then maybe it is possible.

The intrinsic is essentially just a layout template that is unlikely to change so maybe it can be handled by creating that as a standalone "top level" addon with just a stub mixin which is updated/versioned when the "embeded" code is loaded.

Then it would be pretty much no different to using LibStub and only as messy as any library that manages multiple game clients in a single source.. I think.

Something to nut through next, thank you all.