Creating overhaul UI
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! |
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). |
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?
|
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. |
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: Code:
cfg.embeds = { Code:
if not cfg.embeds.RothFont then return end 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) |
So, you mean those folders would go into one addon and put
Code:
if not cfg.embeds.ModuleName then return end Hm... Interesting! I'll have a go with it :) |
Quote:
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. |
Quote:
What would be the reason for you to separate oUF from Libs folder and put that inside embeds folder, instead? |
Quote:
|
Alright, I got the point!
Thanks :) |
All times are GMT -6. The time now is 11:06 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI