back Back to Blog

An overview of the libraries used in MayronUI with real use-cases



4 min read

MayronUI (MUI) has been built in a modular style to enable other developers to create their own MUI modules as separate plugins which connect to the underlining engine. However, this design choice has also been applied to the packages that have built the engine. In this blog post, I explain the three core packages that are available for download by other addon authors and do not depend on MUI.

LibMayronGui builds the responsive MayronUI config menu but unfortunately it is tightly coupled to MUI and so there is no way of using it in other addons and is not discussed here. Maybe someday I will refactor this as that responsiveness code was difficult to write and writing about it would be a huge blog post in of itself (EDIT: The GUI code has now been bundled into a new package called Pkg-GridPanels).

Each of the three packages has had their documentation updated and is available to view on this website. Simply head over to mayronui.com/downloads to view them. Below is a short overview of why they exist and how they have helped me during my WoW addon development "career":


A framework to make object-oriented programming (OOP) easier for Lua developers and World of Warcraft addOn development.

I used this a lot to build a modular system for my UI. For example, I have a Minimap module, ActionBars module, and many more and I needed a good object-oriented solution where modules would have a shared interface and would inherit from 1 parent/base module to orchestrate modules and their life-cycles.

Yes, I could have used basic Lua functions without messing with meta-tables, but this framework also adds strict-typing support for ensuring that parameters and return types are the expected types, as well as allowing for information hiding where instances have their own private data tables. This really helped with the debugging process because errors are thrown at the right location. A major benefit of this is that users who have tried making modules/plugins for my UI followed a spec and the code helped enforce this. This reduced the number of issues reported to me saying "It's not working! :(".


A lightweight, feature-rich World of Warcraft addon database.

This package (originally a LibStub library called LibMayronDB) takes memory usage very seriously while trying to deliver a lot of features. I worked a long time and wrote many unit tests to try to get this as low as possible (you can actually see some of the tests in the leftover Test.lua file on the Github repo!).

One of my favourite features is its support for database table inheritance so that you can have a "template" table of settings for other tables to inherit from. This reduces the number of duplicate settings to save on space and also allows the user to create multiple "child" settings tables. This is different to how a traditional "defaults" table works in other addons. Pkg-MayronDB also supports this but there are some scenarios where a template table is needed instead of a defaults table.

If you didn't know how many tables you needed to represent a feature of your addon but they all needed to share a defaults table then you would have to merge the default settings in with your custom settings and write lots of lines like this:

local height = db.profile.castbars.player.height or db.defaults.castbar.height;

Pkg-MayronDB can ensure that db.profile.castbars.player.height always refers to the correct value by using the customised value if there is one, or by defaulting to the defaults table. So the line above becomes:

local height = db.profile.castbars.player.height;

All you need to do is setup inheritance so that the player table inherits from some template table:

db:AddToDefaults("profile.castbars", { __templateCastBar = { height = 123; }; player = {} }); db.profile.castbars.player:SetParent(db.profile.castbars.__templateCastBar);

A good example of this is how I used a template for the timerbar fields in MUI in the list of defaults and then applied that template to multiple concrete timerbar field settings; by concrete I mean real timerbar fields that the user has setup, such as the player and target timerbar fields (A single timerbar field holds many timerbars for tracking the auras for a given unit).


A simple event management package for World of Warcraft.

This package (originally a LibStub library called LibMayronEvents) controls all events in one central place and lets you define your own custom (non-Blizzard) addon events. You can dynamically control the behavior of your event callback functions, such as allowing you to change the callback arguments passed to the function, assign more than 1 event to trigger it, disabling/enabling and destroying handlers, and more... It uses MayronObjects for strong-typing to build a reliable API.

I personally like using this to auto-destroy the event listener after its first execution, using SetExecuteOnce(true). This lets me setup a few extra things when the player first enters the world using the PLAYER_ENTERING_WORLD event and then destroy it after:

local obj = MayronObjects:GetFramework(); local em = obj:Import("Pkg-MayronEvents.EventManager"); local listener = em:CreateEventListener(function() if (not MayronUI:IsInstalled()) then MayronUI:TriggerCommand("install"); end end); listener:RegisterEvent("PLAYER_ENTERING_WORLD"); listener:SetExecuteOnce(true);

This package has had a major update. Please read the latest documentation for more information.


Written By


back Back to Blog

© 2020 MayronUI.com, All rights reserved.