Thread Tools Display Modes
09-25-10, 02:09 PM   #1
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
API version 5: changes and discussion

Current changes:
- The license has been changed to MIT, from ARR.
- oUF:UpdateElement(name) has been removed. This function has been replaced with element:ForceUpdate().
- element:Update() has been renamed element:Override() to correctly reflect what it actually does.
- Elements no longer require element:GetParent() to return the oUF object. Elements now have a element.__owner which points towards self at enable.
- Support for cataclysm has been added.
- HealPredition element added.
- HolyPower element added.
- PhasingIcon element added.
- SoulShards element added.
- QuestIcon element added.
- EclipseBar element added.
- ReadyCheck element added.
- oUF automatic frame name generator has been improved. It will no longer generate names such as: oUF_LilyPartyParty.
- Elements no longer use the .Override function directly with the event system.
- Support for blank parent frames on headers.
- Added a third argument to the style function indicating if the frame was spawned from a header or not (isSingle).
- Minor optimizations of common tag paths.
- [defict:name] has been renamed [deficit:name].
- Added ['pereclipse'] tag.
- tagfs.overrideUnit has been added. It basically tells the tag system that it should feed the "real" unit to the tag function as a second argument.
- self.disallowVehicleSwap has been removed. Vehicle switching is now always enabled.
- Sub-objects now correctly have self.id set.

Known issues:
- Headers: Due to how RegisterAttributeDrive works on 4.0.x, clicking _can_ go void on frames. The solution to this is to use self:RegisterForClicks('AnyDown') instead of AnyUp. Another solution is to NOT use the visibility field in :SpawnHeader().
- Portraits: On header frames this will constantly reset their animation due to the bug mentioned above

Needs testing:
- All of the new elements require as much testing and input as possible.

Updating version 4 layouts to version 5:
- Any use of oUF:UpdateElements(name) needs to be changed to element:ForceUpdate().
- Any use of element.Update needs to be renamed element.Override.
- If you are checking for an automatically generated name in your style, then you might have to update this check.
- All usage of restricted functions on secure frames (self:Set{Width,Height,Size,Attribute} and a ton other) need to be split into two parts, one of headers and one of single spawns.
Code:
-- single units can be done within the style function:
local style = function(self, unit. isSingle)
-- 8<8<8<8<8<8<8<8<8<8<8<
    if(isSingle) then
        self:SetSize(width, height)
    end
-- >8>8>8>8>8>8>8>8>8>8>8
end

-- header units are slightly more annoying:
local party = self:SpawnHeader(
    nil, nil, 'party', 'showParty', true,
    'oUF-initialConfigFunction', [[
        -- unit can be nil here, and usually it will be: {raid,party}{,pet,target}
        local unit = ...
        -- Do note that this is an string, and you can't actually use locals like this:
        self:SetWidth(width)
        self:SetHeight(height)
    ]]
)

-- If you need local variables within oUF-initialConfigFunction, you can do:
    'oUF-initialConfigFunction', ([[
        -- unit can be nil here, and usually it will be: {raid,party}{,pet,target}
        local unit = ...
        -- Do note that this is an string, and you can't actually use locals like this:
        self:SetWidth(%d)
        self:SetHeight(%d)
    ]]):format(width, height)
__________________
「貴方は1人じゃないよ」

Last edited by haste : 10-12-10 at 12:48 PM.
  Reply With Quote
09-27-10, 03:33 AM   #2
zork
A Pyroguard Emberseer
 
zork's Avatar
AddOn Author - Click to view addons
Join Date: Jul 2008
Posts: 1,740
Download 'oUF'
__________________
| Simple is beautiful.
| WoWI AddOns | GitHub | Zork (WoW)

"I wonder what the non-pathetic people are doing tonight?" - Rajesh Koothrappali (The Big Bang Theory)

Last edited by zork : 10-13-10 at 12:38 AM.
  Reply With Quote
09-27-10, 03:41 AM   #3
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Originally Posted by zork View Post
Could you post the changed license?
http://github.com/haste/oUF/commit/b...3e15fceb015647

It basically is what I tell people to treat the ARR license as. So there aren't exactly any changes.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
09-30-10, 06:29 PM   #4
Monolit
A Black Drake
AddOn Author - Click to view addons
Join Date: Jan 2006
Posts: 81
Originally Posted by haste View Post
Current changes:

Known issues:
Hm, what about that issue with party/raid frames I told you about a week ago, where you get "sluggish" response from clicking on raid and party units.

It looks like some sort of problem with input handling for secure headers, though since you didn't list it maybe there's a workaround for that kind of behavior?
  Reply With Quote
09-30-10, 11:37 PM   #5
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
I haven't been able to write a small test case on that yet, so I don't know if it's a general issue or something with oUF.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
10-01-10, 10:39 AM   #6
zork
A Pyroguard Emberseer
 
zork's Avatar
AddOn Author - Click to view addons
Join Date: Jul 2008
Posts: 1,740
haste give me a hint. I currently stopped working on my layout because I thought 1.4.xx would be a version to go live with Cataclysm.

So I assume this is not the case?
__________________
| Simple is beautiful.
| WoWI AddOns | GitHub | Zork (WoW)

"I wonder what the non-pathetic people are doing tonight?" - Rajesh Koothrappali (The Big Bang Theory)
  Reply With Quote
10-01-10, 02:07 PM   #7
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Originally Posted by zork View Post
haste give me a hint. I currently stopped working on my layout because I thought 1.4.xx would be a version to go live with Cataclysm.

So I assume this is not the case?
The initial plan was to keep 1.4.x going a good while. There was some minor annoyances with 1.4.x that were reported shortly after it was pushed however, and I decided that I might as well break the API with Cataclysm coming.

The changes between 1.4.x and 1.5.x aren't exactly extensive on the surface, and they'll probably not get any worse than they currently are.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
10-01-10, 07:50 PM   #8
Ailae
A Rage Talon Dragon Guard
 
Ailae's Avatar
AddOn Author - Click to view addons
Join Date: Dec 2007
Posts: 318
I'm not sure if this is a 1.5 error or just user error (more likely), but since I'm only developing on the beta I can't really compare to any earlier version.

However, I want my partyframes to be shown even when I'm in a raid. Thus I spawn them using this:

Code:
local party = self:SpawnHeader(nil, nil, 'party,raid',
          -- http://wowprogramming.com/docs/secure_template/Group_Headers
          -- Set header attributes
          "showRaid", true,
          "showParty", true,          
          "yOffset", -30
)
party:SetPoint("TOP", player, "BOTTOM", -20, -90)
This is pretty much based on the boilerplate for 1.4. However, when I have showRaid set to 'true', it creates the partyframe as a raidbutton and since I'm not doing any specific stylings to any raidframe it turns out all weird-looking. This was tested by adding solo to visibility and adding showPlayer = true and showSolo = true. But I first noticed it when I joined a party. I didn't want to file it as a bug because it's very possible I'm either doing it wrong or assuming it's going to work in another way then it really does.

Apologies if this should've gone in it's own thread or someplace else.

The elements for HolyPower and SoulShards works beautifully on the other hand, no problems at all so far. Only done limited testing on warlocks though. Incoming heals was working fine as well as far as I can tell.

Is there any reason why a ReadyCheck-element isn't included in oUF itself, instead of relying on a plugin? Seems like a default thing to have available on any unitframe in my humble opinion. Not bashing p3lims plugin, just curious. I spend five minutes trying to find something about it in the elements-folder before figuring it wasn't included.
__________________
Oh, the simulated horror!
  Reply With Quote
10-02-10, 04:52 AM   #9
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Originally Posted by Ailae View Post
I'm not sure if this is a 1.5 error or just user error (more likely), but since I'm only developing on the beta I can't really compare to any earlier version.

However, I want my partyframes to be shown even when I'm in a raid. Thus I spawn them using this:

Code:
local party = self:SpawnHeader(nil, nil, 'party,raid',
          -- http://wowprogramming.com/docs/secure_template/Group_Headers
          -- Set header attributes
          "showRaid", true,
          "showParty", true,          
          "yOffset", -30
)
party:SetPoint("TOP", player, "BOTTOM", -20, -90)
This is pretty much based on the boilerplate for 1.4. However, when I have showRaid set to 'true', it creates the partyframe as a raidbutton and since I'm not doing any specific stylings to any raidframe it turns out all weird-looking. This was tested by adding solo to visibility and adding showPlayer = true and showSolo = true. But I first noticed it when I joined a party. I didn't want to file it as a bug because it's very possible I'm either doing it wrong or assuming it's going to work in another way then it really does.

Apologies if this should've gone in it's own thread or someplace else.
showRaid = true toggles if the header should create raid frames or not. The visibility string controls if the header should be shown or hidden.

Removing showRaid = true, should be all you have to do.


Originally Posted by Ailae View Post
Is there any reason why a ReadyCheck-element isn't included in oUF itself, instead of relying on a plugin? Seems like a default thing to have available on any unitframe in my humble opinion. Not bashing p3lims plugin, just curious. I spend five minutes trying to find something about it in the elements-folder before figuring it wasn't included.
Initially the ready check system was completely useless compared to the add-on alternatives. You had to wait 30 (or was it 60?) seconds until you got any information about what people clicked. Compared to the add-ons that gave you the information instantly.

Then there's the fact that no-one asked for it to be implemented and the fact that oUF_ReadyCheck was public when the ready check system didn't suck.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
10-02-10, 05:32 AM   #10
Ailae
A Rage Talon Dragon Guard
 
Ailae's Avatar
AddOn Author - Click to view addons
Join Date: Dec 2007
Posts: 318
Ah, that clears things up. Thanks!
__________________
Oh, the simulated horror!
  Reply With Quote
10-02-10, 08:51 AM   #11
Dawn
A Molten Giant
 
Dawn's Avatar
AddOn Author - Click to view addons
Join Date: May 2006
Posts: 918
I would like to see Ready Check being part of oUF's core, though. I don't know if it's just me, but It never seemed to update properly. At least hiding itself after a certain period of time - after someone performed a ready check - did not seem to work sometimes. And after all this is definitely an unit frame element.

Have you thought about giving party pets and all things alike an own .. err, term(?!) which can be used to address them, like you did with party and raid instead of the "GetPArent() .... whatever" thing it was in the past?

I still think it's quite annoying that frames like party pets inherit all and everything from party and one has to "ClearAllPoints()" etc. everything to clean them up. But maybe I'm just doing it wrong - spawning them through xml, atm.
__________________
Rock: "We're sub-standard DPS. Nerf Paper, Scissors are fine."
Paper: "OMG, WTF, Scissors!"
Scissors: "Rock is OP and Paper are QQers. We need PvP buffs."

"neeh the game wont be remembered as the game who made blizz the most money, it will be remembered as the game who had the most QQ'ers that just couldnt quit the game for some reason..."

  Reply With Quote
10-02-10, 09:18 AM   #12
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Originally Posted by Dawn View Post
I would like to see Ready Check being part of oUF's core, though. I don't know if it's just me, but It never seemed to update properly. At least hiding itself after a certain period of time - after someone performed a ready check - did not seem to work sometimes. And after all this is definitely an unit frame element.

Have you thought about giving party pets and all things alike an own .. err, term(?!) which can be used to address them, like you did with party and raid instead of the "GetPArent() .... whatever" thing it was in the past?

I still think it's quite annoying that frames like party pets inherit all and everything from party and one has to "ClearAllPoints()" etc. everything to clean them up. But maybe I'm just doing it wrong - spawning them through xml, atm.
Take a look at the experimental branch. It's there to solve exactly what you're asking for. I explained some of it in the commit.

The following template should work fine, but I haven't gotten to test it yet:
Code:
<Ui xmlns="http://www.blizzard.com/wow/ui/">
	<Button name="oUF_MySeparateHeaderTemplate" inherits="SecureUnitButtonTemplate" hidden="true" virtual="true">
		<Attributes>
			<Attribute name="oUF-onlyProcessChildren" type="boolean" value="true"/>
		</Attributes>

		<Frames>
			<!-- You get UnitButtonUnit with this btw :p -->
			<Button name="$parentUnit" inherits="SecureUnitButtonTemplate">
				<Attributes>
					<Attribute name="useparent-unit" type="boolean" value="true"/>
					<Attribute name="type1" type="string" value="target"/>
					<Attribute name="initial-unitWatch" type="boolean" value="true"/>
				</Attributes>
			</Button>
			<Button name="$parentPet" inherits="SecureUnitButtonTemplate">
				<Attributes>
					<Attribute name="unitsuffix" type="string" value="pet"/>
					<Attribute name="useparent-unit" type="boolean" value="true"/>
					<Attribute name="type1" type="string" value="target"/>
					<Attribute name="initial-unitWatch" type="boolean" value="true"/>
				</Attributes>
			</Button>
			<Button name="$parentTarget" inherits="SecureUnitButtonTemplate">
				<Attributes>
					<Attribute name="unitsuffix" type="string" value="target"/>
					<Attribute name="useparent-unit" type="boolean" value="true"/>
					<Attribute name="type1" type="string" value="target"/>
					<Attribute name="initial-unitWatch" type="boolean" value="true"/>
				</Attributes>
			</Button>
		</Frames>
	</Button>
</Ui>
Do notice that the above template lacks anchoring, as that's pretty much up to you. It's also possible to implement this with the current 1.4.x/1.5.x code, but it's a bit more PITA.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
10-02-10, 09:19 AM   #13
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
I forgot to comment on the Ready check part; I'll have a look at it.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
10-02-10, 09:21 AM   #14
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Oh hai! With this commit unitsuffix information was added to the unit fed to the style function. I think I addressed all your questions with this :P.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
10-02-10, 06:02 PM   #15
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
So, I read through most of the secure group headers code today, and did a comparison against the LK version. The result was that I had to change quite a lot of stuff to make headers work correctly in combat in CC. I also removed the LK support code from 1.5. And I merged experimental into master.

The changes made aren't set in stone yet, so feel free to decipher the commits and give your feedback. I'll update the initial post when I feel it's more "stable".
__________________
「貴方は1人じゃないよ」
  Reply With Quote
10-03-10, 04:13 AM   #16
zork
A Pyroguard Emberseer
 
zork's Avatar
AddOn Author - Click to view addons
Join Date: Jul 2008
Posts: 1,740
Ok, gonna test the 1.5 version next week. I guess the newly commited master is 1.5.x?
__________________
| Simple is beautiful.
| WoWI AddOns | GitHub | Zork (WoW)

"I wonder what the non-pathetic people are doing tonight?" - Rajesh Koothrappali (The Big Bang Theory)
  Reply With Quote
10-03-10, 04:24 AM   #17
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Originally Posted by zork View Post
Ok, gonna test the 1.5 version next week. I guess the newly commited master is 1.5.x?
Yes, master has been 1.5.x since early September.

You should note that master is currently a moving target, and I'm not entirely sure what changes I will (and have) to do yet. The changes should mainly be around how you call :SetAttribute() and other secure/protected functions.

One of the current solutions is the 'oUF-initialConfigFunction' attribute, which allows you access to the secure function oUF uses to call the style function insecurely. The gain of this is that you have full secure access, as if you were called from the header directly. It's only used for header units however, not direct spawns.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
10-03-10, 09:55 AM   #18
Dawn
A Molten Giant
 
Dawn's Avatar
AddOn Author - Click to view addons
Join Date: May 2006
Posts: 918
No biggy, but would you consider adding a threat tag that shows the percent value of threat of the current target. Or maybe changing the default tag to show UnitDetailedThreatSituation instead of just UnitThreatSituation?

Either
  • threatpct: Number - returns the unit's threat on the mob as a percentage of the amount required to pull aggro, scaled according to the unit's range from the mob. At 100 the unit will pull aggro. Returns 100 if the unit is tanking and nil if the unit is not on the mob's threat list.

or
  • rawthreatpct: Number - returns the unit's threat as a percentage of the tank's current threat. Returns nil if the unit is not on the mob's threat list.

Not sure which one would make more sense. Probably threatpct.

Code:
local _,_,threatpct,_,_ = UnitDetailedThreatSituation("player", "target")
I know this could be done by authors them self, but I think the current threat tag is not that, err ... versatile/informative.
__________________
Rock: "We're sub-standard DPS. Nerf Paper, Scissors are fine."
Paper: "OMG, WTF, Scissors!"
Scissors: "Rock is OP and Paper are QQers. We need PvP buffs."

"neeh the game wont be remembered as the game who made blizz the most money, it will be remembered as the game who had the most QQ'ers that just couldnt quit the game for some reason..."

  Reply With Quote
10-03-10, 10:00 AM   #19
haste
Featured Artist
 
haste's Avatar
Premium Member
Featured
Join Date: Dec 2005
Posts: 1,027
Feel free to create an issue about how there should be an threatpct tag :P.
__________________
「貴方は1人じゃないよ」
  Reply With Quote
10-03-10, 10:15 AM   #20
Dawn
A Molten Giant
 
Dawn's Avatar
AddOn Author - Click to view addons
Join Date: May 2006
Posts: 918
Meh, forgot that the target is not optional for UnitDetailedThreatSituation like it is for UnitThreatSituation ... I'll think about it.
__________________
Rock: "We're sub-standard DPS. Nerf Paper, Scissors are fine."
Paper: "OMG, WTF, Scissors!"
Scissors: "Rock is OP and Paper are QQers. We need PvP buffs."

"neeh the game wont be remembered as the game who made blizz the most money, it will be remembered as the game who had the most QQ'ers that just couldnt quit the game for some reason..."

  Reply With Quote

WoWInterface » Featured Projects » oUF (Otravi Unit Frames) » API version 5: changes and discussion

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