The 1.4 list
 

I currently have quite a few changes I want to push out in oUF, but I've been holding them back as it will break quite a few APIs however. Most of these changes are in the form of:
- Incorrectly named functions (ie. :PreAuraSetPosition).
- Every single element hook resides with a "generic" name in the object namespace. (ie. :SetAuraPosition).

The basic idea with 1.4 is to clean up all of this, while reviewing some other parts of oUF. The reason I'm publishing this right now is to give people the possibility to chip in regarding what they find frustrating/will find frustrating.

Core
:Spawn(unit, name, template, disableBlizz)
I don't like how the current spawn works. What should be done is moving disableBlizz into it's own function and removing template. The arguments should be changed into: unit, name, showParty, showRaid. Where showParty/showRaid act true to their name.

A quick example would be having showParty set til true and showRaid set to nil/false. This would make the frame only show when you aren't in a raid.

:DisableBlizzard(unit)
Supplement as disableBlizz will be removed from :Spawn. The question is really if it still should be automatically called from :Spawn.

What I mean with <element>PostCreateIcon is basically:
self.Buffs.PostCreateIcon = function() end

The following is pretty much just renaming/moving of functions.

Aura
:PostCreateAuraIcon -> <element>PostCreateIcon
:CreateAuraIcon -> <element>CreateIcon
:CustomAuraFilter -> <element>CustomFilter
:PostUpdateAuraIcon -> <element>PostUpdateIcon
:PreUpdateAura -> <element>PreUpdate
:PreAuraSetPosition -> <element>PreSetPosition
:SetAuraPosition -> <element>SetPosition
:PostUpdateAura -> <element>PostUpdate

This allows us to define custom functions to all of these on all of the aura elements we use. With the current solution we have to check if we're on self.Auras or self.Buffs or self.Debuffs. It also helps the entire API to be consistent (or at least more consistent).

Castbar
:PostCastStart -> <element>PostCastStart
:PostCastFailed -> <element>PostCastFailed
:PostCastInterrupted -> <element>PostCastInterrupted
:PostCastDelayed -> <element>PostCastDelayed
:PostCastStop -> <element>PostCastStop
:PostChannelStart -> <element>PostChannelStart
:PostChannelUpdate -> <element>PostChannelUpdate
:PostChannelStop -> <element>PostChannelStop
.OnCastbarUpdate -> <element>OnUpdate

Happiness
:PostUpdateHappiness -> <element>PostUpdate

Health
:PreUpdateHealth -> <element>PreUpdate
:OverrideUpdateHealth -> <element>Update
:PostUpdateHealth -> <element>PostUpdate

Portraits
:PreUpdatePortrait -> <element>PreUpdate
:PostUpdatePortrait -> <element>PostUpdate

Power
:PreUpdatePower -> <element>PreUpdate
:OverrideUpdatePower -> <element>Update
:PostUpdatePower -> <element>PostUpdate

Threat
:PreUpdateThreat -> <element>PreUpdate
:OverrideUpdateThreat -> <element>Update
:PostUpdateThreat -> <element>PostUpdate

Runes
The current version of the rune element uses the following unneeded variables:
- height (required)
- width (required)
- spacing
- anchor
- growth

All of these are just used for positioning the bars initially. It's a one-time set-up and can be done from the layouts without requiring any extra effort from the layout authors.

{Pre,Post}Update arguments
The old behavior was defined as:

I suggest changing this to:
Just so it's said: You won't loose access to the main frame object. You can still access this through element:GetParent(). So conditional manipulation of other elements is still possible.

I'm dropping the event argument as it's pretty redundant for these functions.
_________________________________

I'm also pondering about removing most of the overrides, but that's pretty foggy right now.

There's also a need for some real documentation, but I'm not going to tackle that task alone :).

Revision history
3
- Added example on what are changes being made to the pre/post update functions.
2
- Added potential changes to the Runes element.
1
- Renamed OverrideUpdate to Update. It now acts as a full replacement to the internal Update function.

Considering that I override almost everything oUF does on health/power updates, I'd argue in favor of not removing the overrides, if for no reason other than to save CPU cycles by not doing everything twice.

I've also used an override on the threat update function to color my frame's border instead of setting a texture color... with the small hack of creating a table with empty functions to mimic a texture object so oUF doesn't complain when it tries to :SetVertexColor on it.

As for the rest, I'm assuming you meant <element>:PostUpdate? If so, that sounds reasonable.

Does anyone generates a frame though oUF and not want to simultaneously hide the corresponding Blizzard frame? o_O

Finally, I'd be happy to help write documentation once things are further along.

On both health and power, not setting any of the color* flags will be the same as overriding. The current solution would most likely save CPU compared to not having a override also, so that's not really the concern.

There's always tricks such as:
if self.Threat is a frame: self.Threat.SetVertexColor = self.Threat.SetBackdropBorderColor

The override on .Threat is one of those I wanted to remove. It basically removes all the functionality of the element, making a simple event registration more sensible to do. I do see how it's convenient to just do self.Threat and override the function tho'.

No, I intentionally left out the call notation on all of those. I'll have to review the arguments on each and everyone of them, and doing :PostUpdate would translate over to: .PostUpdate(element, ...). The problem with this is that you in most cases want to manipulate something else on the frame in these functions.

I have a vague memory of some odd-case scenario, but I do agree with you. Especially true with :Spawn knowing about the party/raid state.

The goal with it is mostly to document what behavior the elements in oUF expect and what hooks are available to the author. Pretty much just an extended version of what exists within the files atm. :)

Does this include setting the statusbar value? Most of my statusbars fill in the opposite direction as normal, so I'm overriding that too.

True, but what I'm doing is slightly more complicated. I am coloring my frame's border... but my frame's border is actually 8 separate textures, and I also color the border for debuffs, and I increase the size of the border for dispellable debuffs and full aggro (as opposed to just high threat), so I think my current solution is about as simple as it can get. I'd previously been using my own custom module for threat, but it's less work for me to just hijack oUF.

Yeah, but who wants to read through the code to figure out that Spawn passes the initial config function a nil unit for party frames? :p

Power and health actually run :SetValue and friends before they run the override :). In other words your override is basically just a :PostUpdate.

It's actually Blizzard doing that. It is possible to convert the nil value into a unit, but I've never found a good reason to add the extra cruft needed for it.

See, nobody reads the code! :p

The override solution is really just a leftover from earlier versions. A solution I guess would be to allow custom enabling of elements.

Writing this on my phone so I'll be short:
:EnableElement(unit, customUpdateFunction)

The idea is that the custom function will be used instead of the normal one. It would require some refractoring in most modules, but that's what 1.4 is for: 3

So I had some time to think about that part. Doing <element>Update would make a lot more sense, and it would be easier to handle. Does it sound sensible enough?

I'm also willing to help with documentation stuff. :)

<element>Update is meant to replace <element>OnUpdate or <element>OverrideUpdate ? It is confusing...

I've updated the first post.

<element>Update is meant to replace self.OverrideUpdateX.

I need some kind of PostUpdateHealth and PostUpdatePower functionality for my orbs aswell. Thats the only way I can draw the orb texture after every health/power update.

If this is still granted in the new version...fine with me.

They're there still, but renamed to just PostUpdate as mentioned in the first post.

I've updated the initial post with some changes that will be made to the runes element. Having to look up all the variables and setting them up probably takes more time than just letting the layout handle it. It also prevents some flexibility.

Updated first post with information about what changes are being made to the argument list on {Pre, Post}Update functions.

This is fine, though unless other things are changing, a bit redundant for elements like Health where the element is already passed:

Or would bar be going the way of event?

Also, if Spawn will no longer accept a template, how will layouts indicate that a header should show pets? Currently that's done by passing the SecureGroupPetHeaderTemplate template...

Using the old OverrideUpdateHealth as an example:
For the health element the bar variable _is_ the element.

The goal of this thread is really to catch corner cases such as that. That being said, I'm not entirely sure how I would want to solve it. There's two potential solutions to it that I can see instantly:
A: Add template as the argument after name, or at the end of the list. It should then also be used for the single-units.
B: Split the header part out of :Spawn and into :SpawnHeader. This would also require the arguments to be changed into: name, template, showParty, showRaid. It's also possible that name is removed all together, but that depends on how successful automatic naming will be.

Yes, hence the "unless other things are also changing" bit. :p

As the main goal of oUF is to simplify the creation of unit frames, I'd vote against requiring the layout author to specify a template, especially since there is only one instance where a "non-standard" template is used (pet headers).

You could tack an isPetGroup flag on the end, and drop template.

There are other header templates than pet, so just replacing template with isPet isn't really the best solution. I'm still leaning towards the B solution, but not entirely sure yet.

Yes; the idea is that if isPet is nil/false, the default SecureGroupHeaderTemplate is used. I haven't seen any layouts that use anything other than that or SecureGroupPetHeaderTemplate.