Rewriting Aurora, looking for feedback

[Haleth]

Hello!

Over the years I've been updating and adding features to my addon, Aurora. It's gotten reasonably popular and many UI authors now include it in their UI, which I'm really happy about.

However, I started writing Aurora when I wasn't that experienced in programming, and a couple of glaring flaws in the addon's structure have become apparent over time as it got bigger and bigger and I learned more about programming. Namely:

- A lack of separation between core addon code, API, persistence, actual implementation, and appearance
- A lack of customizability, which is hard to implement because of the above issue
- The inability for UI authors to easily provide their own custom theme for Aurora to use, because of the two issues above

To address all of these problems, I've decided to rewrite Aurora from the ground up, focusing on good design principles and extensibility. I want the actual visual style to be completely independent from the implementation, so that I can add in-game options to allow people to customize colours, opacity, background and border style, etc. I also want UI authors to be able to provide their own custom style, without having to mess with Aurora's code each time I update the addon.

I've thought of several ways to do this, but I'm not entirely sure how to go about it. That's where I need help. I could:

- Provide a way for other authors to supply custom settings, such as colours and borders, in a certain format, and register them with Aurora (and request a theme reload to apply instantly). Aurora would then copy these settings to its own saved variables (if the theme wasn't saved already), letting users select the theme from an in-game option. They'd be able to modify the theme as well, or reset it to its defaults at any time (keep 2 cvar tables for each theme, the defaults and the current). All API functions (used both to restyle the Blizzard UI and in plugins for other addons) would then use these settings. The downside of this method is that it would be quite a bit of work to implement. It also means that even when disabling the addon that provided the theme, it would still be saved - so if the author of the other addon decides to modify their theme (or the theme changes dynamically), it would have to notify Aurora of this so that it can copy the new settings. Another problem is that some textures provided by the addon and saved in the cvars as a string might no longer be available if the addon is removed. I'd have to check for that, somehow.
- Instead of using settings like the above, I could code all necessary information about colours, borders, etc into the API functions itself. By default, they would provide the default "Aurora" style. I could then allow authors to register their custom API functions, and if those functions are found, Aurora would use them rather than the default ones. This seems a lot easier than the first method, but I'm not sure if it's actually possible. I'd have to ask each author to send me the name of their addon so that I can add it to Aurora's OptionalDeps, which seems less than ideal. Alternatively, I could provide a function for the addons to call to notify Aurora that a custom API is available. Aurora could then show a dialog prompting the user to reload the UI. Then, it would delay loading the API until the other addon has been loaded (using OnUpdate), but what if the user disabled the other addon in the meantime? Another consequence of this method is that custom styles could not be changed in Aurora itself, but only in the addon providing them. That could be seen as both a benefit and a drawback.
- I could do a mix of the above, letting other authors somehow override the default API, but still letting the default API use settings that are customizable in Aurora itself. Those settings could still only be used for the default theme, though - custom themes would have to be changed in the addon providing them.

There are probably more, and perhaps better methods to do this that I can't think of right now.

Apologies for the long post/text walls. Any ideas and suggestions would be much appreciated.