WeakAuras

WeakAuras

206M Downloads

Code Custom Option Type

emptyrivers opened this issue ยท 4 comments

commented

This has been suggested to me a couple of times, but I need more information before deciding.

What are the use cases in which writing code would help?

  • Localization of spell names
    • Valid, but this seems like a poor method of handling localization. In any case, this use case is handled by creating spell links with #1077
    • Localization is a hard problem in general, and since there are a lot of 3rd party strings to be translated, perhaps WeakAuras could use a localization module?

What format should be expected? A function, or just a json lua table which is sent to AceConfig?

commented

Potential issues:

  • Validating values given by the Author - Ace will complain loudly if given bad data, which could break the addon if we are not careful.
  • Author expectations - this code would necessarily need to run at the same time as Condition Variables. So no state, no region, config would be poorly defined, init has not yet run.
commented

it helps with localization
for example https://i.gyazo.com/38fb7394f5c1987ccc7d8d3f6a7833c0.png

would be neat if I could just return GetSpellInfo() instead of having to type the ability's name

commented

Something I was thinking about the other day touched on a potential use-case for this, and that was adding a custom text frame to Auras and wanting to provide a custom function, akin to the WA %c one.

commented

I've thought about this for a while more, and I've decided to not implement this. There are significant issues with preserving user data if we allow the options to mutate uncontrollably, and I'd rather not go down that rabbit warren if I can avoid it. The primary use cases which could have been solved by letting the author write code to generate options on the fly are, in no particular order:

  • Localization. We can handle this via a more structured approach, as outlined in #1077.
  • Interactivity. Having some amount of interactivity for custom options, such as hiding a group when a toggle is unchecked, or providing more dynamic options like a selector for sounds, is certainly something which would be nice. But we don't need to use code to do it. I do plan to add hidden and disable functionality to custom options in the medium term, and adding new option types to satisfy things like media is relatively simple.

Neither of these are impossible to solve without writing code, so I think that it is not worth the headache to implement.