Creating overhaul UI

[seyan777]

SO! How's everyone going so far?

Hope you all having a great days

Okay, as the title says I am trying to create an overhaul UI for my personal use which re-designs Blizzard default UI like ElvUI, Tukui or SupervillianUI.

However, I have not yet decided whether I should put them all in one folder called (let's say) SeyanUI

OR

should put each modules in each folders like SeyanUI_Core (where the core holds all libs, media and functions that would be shared in each modules), SeyanUI_Unitframe, SeyanUI_Actionbar and so on.

The second approach would be more like Blizzard default UIs, and my favor is slightly biased to this method.

The reasons are because:

1. seems more organized (for me)

2. easier profiling (memory and CPU usage)

3. easy to disable each modules if I don't like them

4. easier to debug(?)

I would like to know how you guys think of this.

Cheers!

[Fizzlemizz]

One of the purposes of the Blizzard UI code is to teach/show how things work making this design understandable and if that is part of your goal then probably also a good idea. There may also some sort of resource hit as this approach will most likely lead to using more individual source files. The biggest down side would be the need to use globals if you need to share between components in seperate folders.

If not then it really does not matter which approach you take but remember, the Blizzard UI addons don't appear in the Addons list in-game so using the seperate folder approach makes it that much harder for people to distinguish between other addons and your UI (assuming you're planning on publishing it).

[Lombra]

As an end user I would much prefer the least amount of folders necessary. If they're not optional (unit frames and action bars shouldn't be) or load on demand, they should definitely be in the same folder. As a developer, points 2 and 4 (possibly 3) may be valid. So maybe separate into folders for development only?

[seyan777]

Many thanks to Fizzlemizz and Lombra for comments, and sorry for the late reply.

So, here are some of my stances.

1. At this stage, I am not really planning to release this UI to public as I am aware of myself that I am not a skilled addon developer, yet. I would be honored if someone decides to use it as teaching materials, but don't think people will learn a lot from my work

2. Like Lombra said, most of the end users (especially those with less knowledge on Lua) would prefer the least amount of folders as it would seem complex on their perspective. However, as I've stated on my point 3, I personally think that such structure would make it easier for those users to disable a module (e.g. Unitframe) that they don't like and instead switch it to whatever they prefer just like we do with default UIs.

[Joker119]

personally, having used an addon that had each module in seperate folders in the AddOns folder, rather than all self-contained in a single "xxUI" folder was rather cumbersome.

When I was given the project by the original author, I condensed everything into the main folder, with a more standardized layout;
core - Holds all core lua files, sich as databases, libraries, menus, slashcommands, etc
embeds - all of the "extra" addons, like chat frame, buff frame, minimap, quest tracker, etc
Libs - A 3rd party Libraries folder for stuff like Ace and LibSharedMedia
media - all font, audio and image files used by the addon
modules - Since the base of the UI is from oUF, all oUF based 'modules' are held here, like oUF_ArtifacePower
units - contains lua files for each individual unitframe that is changes (target, party, pet, player, etc)

The "embeds" folder is where all the once "loaded seperately" addons went into, since the core addon itself does not rely on them, you can easily make them use-configurable by having a config.lua file in the main addon folder with something like this:

  cfg.embeds = {
	rChat = true, -- Simple chat frame
	rActionBarStyler = true, -- Simple actionbar styler for Roth UI 
	rButtonTemplate = true, -- Simple button skinning mod
	rMinimap = true, -- Simplistic square minimap
	rNamePlates = true, -- Diablo style Nameplates
	rInfoStrings = true, -- Information text displayed under Minimap
	rRaidManager = true, -- Replacement for blizzard's pull-out raid manager
	rTooltip = true, -- Diablo styled tooltips
	tullaRange = true, -- Creates Red/Blue overlay over icons that are not useable due to range or lack of resources
	Roth_ShinyBuffs = true, -- ShinyBuffs buff frame, edited for use with Roth UI
	rObjectiveTracker = true, -- Simple drag and resizeable Objective Tracker frame
	RothFont = true, -- makes game client use a font (as defined in config file) for all game text
  }

If for example, you wanted to turn off RothFont; simply change 'true' to 'false' on it's line, and have a check in the "embeds/RothFont/core.lua" file at the beginning like this:

if not cfg.embeds.RothFont then return end

You can do this for every module that is able to be independently disabled, including specific unit frames like party, target, etc.

This gives users the best of both worlds - A simplistic "single folder" for your entire UI, but also the ability to easily enable/disable parts they do/don't want to use.
These enable/disable switches can also be incorporated into an in-game menu, you just have the menu write a true or false value to a database, then have the module check the corresponding value in the database when it loads (this does mean a /reload is required for enabling/disabling modules to take effect, but so would editing a config file directly)

[seyan777]

So, you mean those folders would go into one addon and put

if not cfg.embeds.ModuleName then return end

on top of each lua files, right?

Hm... Interesting!

I'll have a go with it

[Joker119]

Originally Posted by seyan777 So, you mean those folders would go into one addon and put if not cfg.embeds.ModuleName then return end on top of each lua files, right? Hm... Interesting! I'll have a go with it

Correct, then in the .toc file, where you list the order in which to load files for your addon, you put a config.lua file somewhere near the top. Then you have the options to enable/disable them in that config file.

You can use my addon as a working representation of this; https://github.com/galaxy119/Roth_UI?files=1
the options to enable/disable modules are at teh top of the "config.lua" file, and the modules being managed here are in the "embeds" folder.

[seyan777]

Originally Posted by Galaxy119 Correct, then in the .toc file, where you list the order in which to load files for your addon, you put a config.lua file somewhere near the top. Then you have the options to enable/disable them in that config file. You can use my addon as a working representation of this; https://github.com/galaxy119/Roth_UI?files=1 the options to enable/disable modules are at teh top of the "config.lua" file, and the modules being managed here are in the "embeds" folder.

Just had a look at your work and here is a quick question.

What would be the reason for you to separate oUF from Libs folder and put that inside embeds folder, instead?

[Joker119]

Originally Posted by seyan777 Just had a look at your work and here is a quick question. What would be the reason for you to separate oUF from Libs folder and put that inside embeds folder, instead?

The first version of the addon had oUF and the actual layout for oUF as seperate folders inside Interface/AddOns, I moved oUF into the embeds with all the other addons I migrated into the Roth UI folder, just for convenience, it's actual position doesn't matter.

[seyan777]

Alright, I got the point!

Thanks