Style registration separate from unit creation?

[Folji]

So this is mostly a question regarding good coding habits more than anything else, though I'm still trying to learn my way around addon development in general.

As far as I understand, Lua is a language in which you can't just straight-forward call a function before it has been defined. My development habits has be liking a top-to-bottom coding, having a constructor at the top that calls all the heavier chunks of code written further down. But that's not really an option out of the box in Lua, as far as I understand?

So for the sake of code simplicity when working with it, would it be a good habit to write the actual constructor code for each of the UI elements separate from the Lua file containing the style registration for oUF? I learned recently how functions and variables specific to an addon can be passed around within the addon through its namespace, so I could have a core file in which I create a frame and save it as a variable to the namespace, write all the constructor functions to that frame, then in the style file make that frame a local variable and call the constructor functions with the individual frames passed as a parameter?

Hopefully that wasn't too much a garble of a way to put it! But essentially, trying to figure good ways to not write too much repeated code and wind up with an oUF layout in which each frame has its own Lua file that essentially does everything on its own. Though I'm guessing the runtime difference wouldn't be too much difference, other than just lots of needlessly repeated code and one style registered for each type of frame.

[Seerah]

I always put my main code at the bottom of the file, referencing what is above it. Though you could certainly split things into different files.

[Tim]

Originally Posted by Folji As far as I understand, Lua is a language in which you can't just straight-forward call a function before it has been defined. My development habits has be liking a top-to-bottom coding, having a constructor at the top that calls all the heavier chunks of code written further down. But that's not really an option out of the box in Lua, as far as I understand?

Correct, you have to create the function before you call it unless you store it in the namespace in another file in which you still have to create it before calling it later in the other file as well.

Originally Posted by Folji So for the sake of code simplicity when working with it, would it be a good habit to write the actual constructor code for each of the UI elements separate from the Lua file containing the style registration for oUF? I learned recently how functions and variables specific to an addon can be passed around within the addon through its namespace, so I could have a core file in which I create a frame and save it as a variable to the namespace, write all the constructor functions to that frame, then in the style file make that frame a local variable and call the constructor functions with the individual frames passed as a parameter?

Assuming no gui/in game options. The way you code your ouf layout is entirely up to you. I'm not sure of the runtimes but, splitting stuff up does make editing easier instead of sifting through 1 file. Generally it's good to at least have a config file as well as a tags file if you plan to use them as well. Some people have a seperate file with most of their functions while others just include them within their layout file. If you have plans on releasing your styles you will want to consider coding to make things easier for the user to edit if they want which generally means splitting up your code. In the end it's once again entirely up to you how you want to lay your code out.

Haste has a few layouts that are good for learning from and so does zork.

[Folji]

So I managed to figure things out, and I've been making pretty nice progress with it!



But, now, what'd be the easy way to go about trimming that health bar? Would I have to create a suitable statusbar texture and SetStatusBarTexture() to do this, or is there an easy way to just use the backdrop frame I've already created beind the statusbars as a mask of sorts?

Also, is there any reference anywhere for the various colour tables oUF uses and overriding it globally? I found some code changing up metatables, but I couldn't get any of it to work, so instead I wrote a function out of the self.colors.power[power] stuff on the Github wiki

lib.SetColors = function(self)
    self.colors.power['MANA'] = {50/255, 140/255, 230/255}
    self.colors.power['RAGE'] = {255/255, 148/255, 148/255}
    self.colors.power['ENERGY'] = {255/255, 255/255, 30/255}
    self.colors.power['FOCUS'] = {255/255, 115/255, 60/255}
end

And then I just call that function in the frame constructor to apply the colour values. But are there any more efficient ways to go about this?

And any reference out there for additional colour values, such as for reaction colouring?

[Seerah]

Yes, just create a statusbar texture with the shape you want.

[Folji]

Properly horizontally mirroring statusbars, wound up resorting to just having an actual mirrored texture for the target frame until I can find a better solution.

But, having applied a texture with a particular shape like this, how can I now force the status bar to keep the texture static? Seems the standard behaviour is to anchor the texture to the "head" of the bar, so that it follows along with it as it shortens down.

[syncrow]

Originally Posted by Folji How can I now force the status bar to keep the texture static? Seems the standard behaviour is to anchor the texture to the "head" of the bar, so that it follows along with it as it shortens down.

This would be the easiest way but results in a stretched texture which you want to avoid (especially with your nice and shapy texture)

I'm assuming that the bar fill texture fits the size of the border?! If so, you should use the resize & crop method to handle the bar texture every time the health changes. Doing so doesn't stretch the texture only cut it.


Example:

local fileWidth, fileHeight = 256, 64
local originWidth = 180
local originHeight = 64
local left, top, bottom = 0, 0, 1
local barTex = <StatusBarFillTexture>
 
-- right anchor, cause the texture grows from right to left  <--
barTex:SetPoint("RIGHT",statusBar)  
 
-- cropping and resizing function (used health percentage value here)
local function UpdateBarTexture(perc)
    local width = originWidth / 100 * perc
    local right = width * 100 / fileWidth
    
    barTex:SetWidth(width)
    barTex:SetTexCoord(left, right, top, bottom)
end

Btw: nice diablo 3 console like of border texture <3