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.

[Phanx]

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

Maybe a quick check to make sure the object has a SetDesaturated method would be nice, to allow using frames, font strings, or other non-texture objects. For example, each of my 5 objects is a frame with 2 textures, one of which gets class colored, the other of which is used as a highlight when the power is at max. I already use an Override to update and color exactly how I want, but unless I add a fake SetDesaturated method, I get errors when oUF tries to do the vehicle switch thing.

[haste]

I'll add it to my list :P

[haste]

I pushed some changes just now. They're pretty much all from Monday. I was planning on reviewing them before I pushed, but ended up having to travel through half of Norway due to work on Tuesday...

If you have any gripe with it still, let me know.

[haste]

No, Combo Points are back in CPoints. classbars.lua was just a stray file in my branch .

[zork]

Yeah I just found out about about that...

[haste]

I probably wouldn't have noticed if you hadn't said anything. :P

[lightspark]

Decided that making a new topic for my request is quite silly, so posting it here, ‘cause it’s related to class powers.

While making custom rune bar for my interface, I found out that it would be quite useful to have the same PostUpdate hook for runes as we’ve got for health/power bars, even two of them, because there’re UpdateType and UpdateRune.

For example, if we had those two hooks we could recolor runes, when they are on CD. I think other addon authors will like this idea, but.. who knows

That’s not too much to modify in runebar.lua code, just 3 extra lines of code for each function.

if (self.Runes.PostUpdateType) then
    return self.Runes:PostUpdateType(self, rune, rid)
end

if (self.Runes.PostUpdateRune) then
    return self.Runes:PostUpdateRune(self, rune, rid)
end

[Rainrider]

Just out of curiosity, why do you want to change the colors? They are statusbars, so if a rune is on cd then you have the filling bar as an indicator for this. Changing colors probably makes it more difficult for the user to distinguish which rune is recharging. Apart from that you probably need the returns of GetRuneCooldown(rid) or you'll have to call it yourself again in PostUpdate.

[Phanx]

Originally Posted by Rainrider ... why do you want to change the colors? They are statusbars ... Changing colors probably makes it more difficult for the user to distinguish which rune is recharging.

Some layouts might use text, cooldown spirals, or other things that aren't statusbars.

As for difficulty, it depends on how you change the color. If you're using a darker blue for recharging frost runes, and a brighter blue for ready frost runes, that probably makes it easier for users to see which ones are ready, especially if you're using a small statusbar where it's hard to distinguish between 90% full and 100% full.

[zork]

But to be fair. You can always make your own module if the default one doesn't fit your needs.

[Phanx]

That's true; I'd probably just use an Override if I wanted to change the default update process instead of adding to it.

[lightspark]

Well, we've got PostUpdate/Override callbacks for almost everything there are 6 of them (5 PostUpdate + 1 Override) for eclipse bar!!

Originally Posted by Phanx Some layouts might use text, cooldown spirals, or other things that aren't statusbars. As for difficulty, it depends on how you change the color. If you're using a darker blue for recharging frost runes, and a brighter blue for ready frost runes, that probably makes it easier for users to see which ones are ready, especially if you're using a small statusbar where it's hard to distinguish between 90% full and 100% full.

Exactly my case I use light grey for recharging runes and when they are ready, I just change the color back.

Originally Posted by Phanx That's true; I'd probably just use an Override if I wanted to change the default update process instead of adding to it.

I prefer using PostUpdates more. Mostly, I really like how the default update process works, but quite often I need to tweak it a little bit or add some features after the update runs.
And as for overriding runebar update process, to be honest, I’d try to avoid it because of enabling/disabling OnUpdate scripts inside the default update function. That's why I asked for adding 2 PostUpdate callbacks.

[Phanx]

Originally Posted by lightspark Exactly my case I use light grey for recharging runes and when they are ready, I just change the color back.

That's not the same thing at all, and I'd tend to agree with Rainrider -- if all recharging runes are gray, it's hard for the user to tell what kind of rune they are. You can guess based on the position, but you shouldn't have to think about it that much. It should be easy to glance at the display and see that you have a frost rune coming up in 2 seconds, etc. Color lets you do that instantly (even if you're colorblind). Gray bars tell you nothing.

[lightspark]

Originally Posted by Phanx That's not the same thing at all, and I'd tend to agree with Rainrider -- if all recharging runes are gray, it's hard for the user to tell what kind of rune they are. You can guess based on the position, but you shouldn't have to think about it that much. It should be easy to glance at the display and see that you have a frost rune coming up in 2 seconds, etc. Color lets you do that instantly (even if you're colorblind). Gray bars tell you nothing.

Okay I should think about it more I decided to do it in that way because of DKs who are testing my UI right now, they asked me about that feature
P.S. btw i'm colorblind (don't see any green)