Quantcast
The 1.4 list - WoWInterface
Thread Tools Display Modes
01-11-10, 03:02 AM   #1
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
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:
Lua Code:
  1. local PostUpdate = function(self, event, unit, arg1, arg2, arg3)
  2. end

I suggest changing this to:
Lua Code:
  1. local PostUpdate = function(element, unit, arg1, arg2, arg3)
  2. end
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.
__________________
「貴方は1人じゃないよ」

Last edited by haste : 01-13-10 at 09:33 AM.
  Reply With Quote
01-11-10, 03:10 AM   #2
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
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.
  Reply With Quote
01-11-10, 03:31 AM   #3
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Originally Posted by Phanx View Post
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.
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.

Originally Posted by Phanx View Post
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.
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'.

Originally Posted by Phanx View Post
As for the rest, I'm assuming you meant <element>:PostUpdate?
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.

Originally Posted by Phanx View Post
Oh, and I'm not sure if anyone generates a frame though oUF and doesn't want to simultaneously hide the corresponding Blizzard frame. o_O
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.

Originally Posted by Phanx View Post
Finally, I'd be happy to help write documentation once things are further along.
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.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
01-11-10, 03:50 AM   #4
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
Originally Posted by haste View Post
On both health and power, not setting any of the color* flags will be the same as overriding.
Does this include setting the statusbar value? Most of my statusbars fill in the opposite direction as normal, so I'm overriding that too.

Originally Posted by haste View Post
There's always tricks such as:
if self.Threat is a frame: self.Threat.SetVertexColor = self.Threat.SetBackdropBorderColor
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.

Originally Posted by haste View Post
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.
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?
  Reply With Quote
01-11-10, 03:56 AM   #5
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Originally Posted by Phanx View Post
Does this include setting the statusbar value? Most of my statusbars fill in the opposite direction as normal, so I'm overriding that too.
Power and health actually run :SetValue and friends before they run the override . In other words your override is basically just a :PostUpdate.

Originally Posted by Phanx View Post
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?
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.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
01-11-10, 03:59 AM   #6
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
Originally Posted by haste View Post
In other words your override is basically just a :PostUpdate.
See, nobody reads the code!
  Reply With Quote
01-11-10, 04:49 AM   #7
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Originally Posted by Phanx View Post
See, nobody reads the code!
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
__________________
「貴方は1人じゃないよ」
  Reply With Quote
01-11-10, 07:12 AM   #8
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
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?
__________________
「貴方は1人じゃないよ」
  Reply With Quote
01-11-10, 01:41 PM   #9
wurmfood
A Flamescale Wyrmkin
AddOn Author - Click to view addons
Join Date: Apr 2009
Posts: 122
I'm also willing to help with documentation stuff.
  Reply With Quote
01-12-10, 02:48 AM   #10
Nodd
A Murloc Raider
 
Nodd's Avatar
Join Date: Dec 2009
Posts: 7
<element>Update is meant to replace <element>OnUpdate or <element>OverrideUpdate ? It is confusing...
  Reply With Quote
01-12-10, 03:46 AM   #11
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Originally Posted by Nodd View Post
<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.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
01-12-10, 05:53 PM   #12
zork
A Pyroguard Emberseer
 
zork's Avatar
AddOn Author - Click to view addons
Join Date: Jul 2008
Posts: 1,739
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.
__________________
| Simple is beautiful.
| WoWI AddOns | GitHub | Zork (WoW) | TDMOG

"I wonder what the non-pathetic people are doing tonight?" - Rajesh Koothrappali (The Big Bang Theory)
  Reply With Quote
01-13-10, 04:31 AM   #13
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Originally Posted by zork View Post
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.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
01-13-10, 07:14 AM   #14
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
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.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
01-13-10, 09:34 AM   #15
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Updated first post with information about what changes are being made to the argument list on {Pre, Post}Update functions.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
01-14-10, 07:41 AM   #16
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
Originally Posted by haste View Post
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.
This is fine, though unless other things are changing, a bit redundant for elements like Health where the element is already passed:

Code:
OverrideUpdateHealth(self, event, unit, bar, min, max)
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...

Last edited by Phanx : 01-14-10 at 07:44 AM.
  Reply With Quote
01-14-10, 08:18 AM   #17
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Originally Posted by Phanx View Post
This is fine, though unless other things are changing, a bit redundant for elements like Health where the element is already passed:

Code:
OverrideUpdateHealth(self, event, unit, bar, min, max)
Or would bar be going the way of event?
Using the old OverrideUpdateHealth as an example:
Lua Code:
  1. local PostUpdate = function(bar, unit, min, max)
  2. end
For the health element the bar variable _is_ the element.

Originally Posted by Phanx View Post
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...
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.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
01-15-10, 01:29 AM   #18
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
Originally Posted by haste View Post
For the health element the bar variable _is_ the element.
Yes, hence the "unless other things are also changing" bit.

Originally Posted by haste View Post
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.
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).

Originally Posted by haste View Post
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.
You could tack an isPetGroup flag on the end, and drop template.
  Reply With Quote
01-15-10, 07:37 AM   #19
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
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.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
01-17-10, 02:10 AM   #20
Phanx
Cat.
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 5,617
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.
  Reply With Quote

WoWInterface » Featured Projects » oUF (Otravi Unit Frames) » The 1.4 list

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off