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: |
|
Quote:
It basically is what I tell people to treat the ARR license as. So there aren't exactly any changes. |
Quote:
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? |
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.
|
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? |
Quote:
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. |
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', 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. :) |
Quote:
Removing showRaid = true, should be all you have to do. Quote:
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. |
Ah, that clears things up. Thanks!
|
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. :) |
Quote:
The following template should work fine, but I haven't gotten to test it yet: Code:
<Ui xmlns="http://www.blizzard.com/wow/ui/"> |
I forgot to comment on the Ready check part; I'll have a look at it.
|
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.
|
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". |
Ok, gonna test the 1.5 version next week. I guess the newly commited master is 1.5.x?
|
Quote:
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. |
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
or
Not sure which one would make more sense. Probably threatpct. Code:
local _,_,threatpct,_,_ = UnitDetailedThreatSituation("player", "target") |
Feel free to create an issue about how there should be an threatpct tag :P.
|
Meh, forgot that the target is not optional for UnitDetailedThreatSituation like it is for UnitThreatSituation ... I'll think about it. :rolleyes:
|
All times are GMT -6. The time now is 06:22 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI