WoWInterface

WoWInterface (https://www.wowinterface.com/forums/index.php)
-   oUF (Otravi Unit Frames) (https://www.wowinterface.com/forums/forumdisplay.php?f=87)
-   -   API version 5: changes and discussion (https://www.wowinterface.com/forums/showthread.php?t=35152)

haste 09-25-10 02:09 PM

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)


zork 09-27-10 03:33 AM

Download 'oUF'

haste 09-27-10 03:41 AM

Quote:

Originally Posted by zork (Post 207466)
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.

Monolit 09-30-10 06:29 PM

Quote:

Originally Posted by haste (Post 207288)
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?

haste 09-30-10 11:37 PM

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.

zork 10-01-10 10:39 AM

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?

haste 10-01-10 02:07 PM

Quote:

Originally Posted by zork (Post 207801)
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.

Ailae 10-01-10 07:50 PM

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. :)

haste 10-02-10 04:52 AM

Quote:

Originally Posted by Ailae (Post 207830)
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.


Quote:

Originally Posted by Ailae (Post 207830)
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.

Ailae 10-02-10 05:32 AM

Ah, that clears things up. Thanks!

Dawn 10-02-10 08:51 AM

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. :)

haste 10-02-10 09:18 AM

Quote:

Originally Posted by Dawn (Post 207874)
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.

haste 10-02-10 09:19 AM

I forgot to comment on the Ready check part; I'll have a look at it.

haste 10-02-10 09:21 AM

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.

haste 10-02-10 06:02 PM

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".

zork 10-03-10 04:13 AM

Ok, gonna test the 1.5 version next week. I guess the newly commited master is 1.5.x?

haste 10-03-10 04:24 AM

Quote:

Originally Posted by zork (Post 207947)
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.

Dawn 10-03-10 09:55 AM

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. :)

haste 10-03-10 10:00 AM

Feel free to create an issue about how there should be an threatpct tag :P.

Dawn 10-03-10 10:15 AM

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 07:32 AM.

vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI