The new ClassIcons element

[Rainrider]

Haste merged combo points, shadow orbs, holy power, chi orbs and soul shards (covers only affliction warlocks for now) on the master oUF branch on GitHub.

I have some questions about it:

Can we display combo points on the target frame and class power on the player frame and not mix them? An "issue" I have with this is switching from cat to moonkin as I then have both the eclipse bar and the combo points shown on the same frame and have to account for the extra space.

How do I proceed if I need to change the width of the class power "icons" in response to changes of max power? If I get it right, I can do this either on Pre or PostUpdate. PreUpdate is not a good go for this I believe as I would resize widgets before oUF updates their visibility. In PostUpdate I either do it every time or add another field to the ClassIcons array just as ClassIcons.__max and use it to find out if a resize is needed. Wouldn't it be better is oUF tells PostUpdate whether maxPower changed?

What is the idea behind element[i]:SetDesaturated(desaturated)?

I also find the name somewhat misleading. Why not call it ClassPower or something more descriptive that it is about class resources?

[zork]

You have to seperate them.

ComboPoints are for target.
ClassBars are for player.

Vehicles can have comboPoints aswell.

I do it this way: http://imgur.com/a/1znsW

*edit*

Holy cow what has he done? He changed it all into one widget? ALL???

Man I nearly finished creating the new elements on my layout.
...
But actually it is not that bad as I thought. Since I had to override the elements for my textue display anyway I just made the old classIcon elements local modules of my layout.

@Raidrider
Now I understand your problem. You are correct on the seperating.

[Rainrider]

I believe the change was because all the elements behaved the same: all of them were just textures being shown or hidden depending on the same events (with the sole exception of combo points, which does not toggle on UNIT_POWER*). Some layouts used a "class bar factory" because of that, having the same code create this type of class resources.

Some other things I noticed about the new element:
CPointsDisable and ClassPowerDisable do not hide the element. This holds true for every oUF element actually. There is a commit for this on Adirelle's oUF fork, don't know why he didn't make a pull request for it.

The soul shards part of the element does not unregister SPELLS_CHANGED if Soulburn in known (that's at lvl 19 currently - GetSpellLevelLearned(WARLOCK_SOULBURN)), so the element would update visibility for nothing every time the player changes glyphs or learns new spells. But I suppose this will change as burning embers and demonic fury have to be status bars and would require a new element to handle them.

The holy power part registers UNIT_POWER and not UNIT_POWER_FREQUENT as the other elements and the standard ui do. Don't know if that is much of a difference in that case, but it helps to get the Ascension talent for monks without registering PLAYER_TALENT_UPDATE and we have a similar situation with paladins when they level to 85 and learn Boundless Conviction . Also HOLY_POWER_FULL always equals 3, even if Boundless Conviction is known (that's actually irrelevant )

On a side note: does anybody know a vehicle quest with combo points where I can test the behavior of the new element (apart from Aces High! because it requires rep I don't have)

[Rainrider]

And another question (sorry about that):

Can SetSize and SetPoint be called in combat? What happens if my 3 chi monk enters a vehicle in combat and I try to re-size and re-anchor the "class icons" from 3 chi to 5 combo points in PostUpdate?

[p3lim]

Originally Posted by Rainrider And another question (sorry about that): Can SetSize and SetPoint be called in combat? What happens if my 3 chi monk enters a vehicle in combat and I try to re-size and re-anchor the "class icons" from 3 chi to 5 combo points in PostUpdate?

Yes, the combat lock is only for secure frames, which these arent.

[haste]

I combined combo points with the rest of the player elements because I've always viewed it as one. It also replaces the player element when you enter a vehicle. Anyway, I'll split it out again later today. I understand the annoyances people find with not being able to put it exactly where they want.

The intention with the element was to merge everything that's pretty much the same, but with slightly different input variables and colors. I'm all ears for improvements, things aren't really set in stone at all atm.

Originally Posted by zork But actually it is not that bad as I thought. Since I had to override the elements for my textue display anyway I just made the old classIcon elements local modules of my layout.

Why do you need to override the element just to change texture? Anything sane I can do to make it easier for you?

Originally Posted by Rainrider How do I proceed if I need to change the width of the class power "icons" in response to changes of max power? If I get it right, I can do this either on Pre or PostUpdate. PreUpdate is not a good go for this I believe as I would resize widgets before oUF updates their visibility. In PostUpdate I either do it every time or add another field to the ClassIcons array just as ClassIcons.__max and use it to find out if a resize is needed. Wouldn't it be better is oUF tells PostUpdate whether maxPower changed?

I'll add a flag to PostUpdate that max changed.

Originally Posted by Rainrider What is the idea behind element[i]:SetDesaturated(desaturated)?

I can't add custom textures to oUF and most of the default textures look crap when you remove parts of the background/overlay/and such. So I decided that it was better to provide a way to replace the UpdateTexture function and just use SetDesaturated() to grayscale the shadowpriest image and color it with a class related color.

Originally Posted by Rainrider I also find the name somewhat misleading. Why not call it ClassPower or something more descriptive that it is about class resources?

The plan was to create both ClassIcons and ClassBars. I wanted to lessen the burden that classes now provide in WoW. We've pretty much ended up with a bunch of equal elements handling the same issue, with a slight amount of difference.

We could still change the name to something else, or use ClassPower and ClassBars or something. I'm planning on having ClassBars handle Runes, Destruction and Affliction warlocks, druid/monk mana. One could probably throw EclipseBar into the mix as well, but it has fairly strict anchoring requirements. Do note that these elements are still very different, they would just be renamed.

Originally Posted by Rainrider The soul shards part of the element does not unregister SPELLS_CHANGED if Soulburn in known (that's at lvl 19 currently - GetSpellLevelLearned(WARLOCK_SOULBURN)), so the element would update visibility for nothing every time the player changes glyphs or learns new spells.

This doesn't really happen _that_ often. I'm horribly far behind on a lot of stuff currently, but as of this weekend I actually have a life again, so just crushing through as much as possible. For now, optimizations can wait.

Originally Posted by Rainrider The holy power part registers UNIT_POWER and not UNIT_POWER_FREQUENT as the other elements and the standard ui do.

I used the same events as blizzard. I'm sure people will complain if UNIT_POWER lags too much behind for them.

Originally Posted by Rainrider Don't know if that is much of a difference in that case, but it helps to get the Ascension talent for monks without registering PLAYER_TALENT_UPDATE

What?

Originally Posted by Rainrider Also HOLY_POWER_FULL always equals 3, even if Boundless Conviction is known (that's actually irrelevant )

I'm aware of this, but the element handles the switch. It just needs to have a base value to start from and that might as well be HOLY_POWER_FULL :P.