WoWInterface

WoWInterface (https://www.wowinterface.com/forums/index.php)
-   oUF (Otravi Unit Frames) (https://www.wowinterface.com/forums/forumdisplay.php?f=87)
-   -   Would using oUF to just replace a player's nameplate be overkill? (https://www.wowinterface.com/forums/showthread.php?t=56197)

Eungavi 04-30-18 09:35 PM

Would using oUF to just replace a player's nameplate be overkill?
 
I honestly don't like how the player's default nameplate works and thus decided to replace it.

1. Would it be an overkill to use an oUF just to replace player's nameplate?

2. Afaik, spawning a unitframe with oUF would disable/hide default ones. The question is how could I prevent it from being disabled/hidden since I'm only willing to replace the player's nameplate, not unitframe.

neverg 05-01-18 12:39 AM

It will only hide the frames you spawn.
So if you only implement the nameplates it will only skin that.
Don't think it is overkill at all. oUF is quite light to be honest but as with everything depends on what you do with it. :)

Eungavi 05-01-18 07:52 AM

Quote:

Originally Posted by neverg (Post 327843)
It will only hide the frames you spawn.
So if you only implement the nameplates it will only skin that.
Don't think it is overkill at all. oUF is quite light to be honest but as with everything depends on what you do with it. :)

The problem is I'm planning to create an unitframe-like one instead of spawning a nameplate :p

At least it's good to hear that it's not an overkill :banana:

runamonk 05-01-18 08:35 AM

Careful..it's addictive. I started out with oUF just to replace my player and target units and ended up implementing all units and then actual nameplates as well lol.

Eungavi 05-01-18 01:59 PM

Quote:

Originally Posted by runamonk (Post 327846)
Careful..it's addictive. I started out with oUF just to replace my player and target units and ended up implementing all units and then actual nameplates as well lol.

Too bad...

I'm already addicted to it D:

My core UI has all unitframes implemented by oUF.

This will be a separate addon that can be used standalone just to replace player's default resource bar ;)

runamonk 05-01-18 02:22 PM

I did two addons with oUF as well. One for nameplates (and personal bar) and one for all the units. :D

Eungavi 05-14-18 04:17 AM

Okay... so back to the origin!

Would it be possible to create an unitframe without hiding the default ones?

Afaik, :Spawn function would disable blizzard's default unitframe for a selected unit.

Any helps please?!

runamonk 05-15-18 01:16 AM

In looking at the spawn function in oUF it does not appear there is a way to override the functionality.


You could modify the spawn function yourself and add an override to it? Maybe this is something they can add to the new version for BfA as well. :)


Lua Code:
  1. function oUF:Spawn(unit, overrideName)
  2.     argcheck(unit, 2, 'string')
  3.     if(not style) then return error('Unable to create frame. No styles have been registered.') end
  4.  
  5.     unit = unit:lower()
  6.  
  7.     local name = overrideName or generateName(unit)
  8.     local object = CreateFrame('Button', name, oUF_PetBattleFrameHider, 'SecureUnitButtonTemplate')
  9.     Private.UpdateUnits(object, unit)
  10.  
  11.     self:DisableBlizzard(unit)
  12.     walkObject(object, unit)
  13.  
  14.     object:SetAttribute('unit', unit)
  15.     RegisterUnitWatch(object)
  16.  
  17.     return object
  18. end

Eungavi 05-15-18 08:06 AM

Yeah, I thought of adding one extra parameter to Spawn function, but I quit doing it as I don't want to modify lua file whenver there's an update :/

Lua Code:
  1. function oUF:Spawn(unit, overrideName, showBlizzard)
  2.     argcheck(unit, 2, 'string')
  3.     if(not style) then return error('Unable to create frame. No styles have been registered.') end
  4.  
  5.     unit = unit:lower()
  6.  
  7.     local name = overrideName or generateName(unit)
  8.     local object = CreateFrame('Button', name, oUF_PetBattleFrameHider, 'SecureUnitButtonTemplate')
  9.     Private.UpdateUnits(object, unit)
  10.  
  11.     -- maybe something like this
  12.     if not showBlizzard then
  13.         self:DisableBlizzard(unit)
  14.     end
  15.    
  16.     walkObject(object, unit)
  17.  
  18.     object:SetAttribute('unit', unit)
  19.     RegisterUnitWatch(object)
  20.  
  21.     return object
  22. end

Eungavi 05-27-18 09:09 PM

May I ask project manager and authors to officially add an extra parameter to Spawn function (as above) so that the developers with oUF could choose to disable Blizzard default unitframe or not?

runamonk 05-28-18 03:29 AM

Enhancement Request added to GitHub oUF repo.

Cogwerkz 05-28-18 03:43 AM

As a workaround, you could always prehook oUF.DisableBlizzard, and only call it for the units you wish disabled. Then you don't have to directly change anything in the oUF code. Been doing this in some of mine for a while.

Just add something like the following before your spawn code is run:

Lua Code:
  1. local parent, ns = ...
  2. local oUF = ns.oUF
  3. local disableBlizzard = oUF.DisableBlizzard
  4.  
  5. -- table of units you wish to disable,
  6. -- all others blizzard frames will remain
  7. local framesToDisable = {
  8.    player = true,
  9.    target = true
  10. }
  11.  
  12. function oUF:DisableBlizzard(unit)
  13.    if unit and framesToDisable[unit] then
  14.       return disableBlizzard(self, unit)
  15.    end
  16. end

runamonk 05-28-18 03:47 AM

That's a great idea.

Eungavi 05-28-18 07:43 AM

Quote:

Originally Posted by runamonk (Post 328168)

Oh, Thanks mate!

I've recently lost my Github password and am being lazy to find it :p

Quote:

Originally Posted by Cogwerkz (Post 328169)
As a workaround, you could always prehook oUF.DisableBlizzard, and only call it for the units you wish disabled. Then you don't have to directly change anything in the oUF code. Been doing this in some of mine for a while.

Just add something like the following before your spawn code is run:

Lua Code:
  1. local parent, ns = ...
  2. local oUF = ns.oUF
  3. local disableBlizzard = oUF.DisableBlizzard
  4.  
  5. -- table of units you wish to disable,
  6. -- all others blizzard frames will remain
  7. local framesToDisable = {
  8.    player = true,
  9.    target = true
  10. }
  11.  
  12. function oUF:DisableBlizzard(unit)
  13.    if unit and framesToDisable[unit] then
  14.       return disableBlizzard(self, unit)
  15.    end
  16. end

That's actually a great idea.

The question is...

Let's say you have two addons which embeds their own copy of oUF.

One will replace all the unitframes (A) while the other will just draw an extra player unitframe on the center of the screen (B).

Do you reckon overriding a DisableBlizzard function in B would also affect one in A?

oUF doesn't use a LibStub, so I'm guessing that it won't affect each other tho...
(I can't test it myself atm :()

p3lim 05-28-18 08:54 AM

Quote:

Originally Posted by Eungavi (Post 328173)
Let's say you have two addons which embeds their own copy of oUF.

One will replace all the unitframes (A) while the other will just draw an extra player unitframe on the center of the screen (B).

Do you reckon overriding a DisableBlizzard function in B would also affect one in A?

oUF doesn't use a LibStub, so I'm guessing that it won't affect each other tho...
(I can't test it myself atm :()

Embedded oUF instances are their own addons, with their own space. Overwriting oUF internal functions will only affect each one, not both/all.
The only way it'd affect everything is if multiple layouts use the same unembedded oUF instance (which is why you should never override colors globally).

Another way to get what you want without modifying oUF source:
Lua Code:
  1. -- store and disable the method
  2. local orig = oUF.DisableBlizzard
  3. oUF.DisableBlizzard = nop
  4.  
  5. -- spawn your frames
  6. oUF:Spawn('player')
  7.  
  8. -- re-enable the method
  9. oUF.DisableBlizzard = orig

Eungavi 05-28-18 09:10 AM

Quote:

Originally Posted by p3lim (Post 328174)
Embedded oUF instances are their own addons, with their own space. Overwriting oUF internal functions will only affect each one, not both/all.
The only way it'd affect everything is if multiple layouts use the same unembedded oUF instance (which is why you should never override colors globally).

That makes sense :)

Quote:

Originally Posted by p3lim (Post 328174)
Another way to get what you want without modifying oUF source:
Lua Code:
  1. -- store and disable the method
  2. local orig = oUF.DisableBlizzard
  3. oUF.DisableBlizzard = nop
  4.  
  5. -- spawn your frames
  6. oUF:Spawn('player')
  7.  
  8. -- re-enable the method
  9. oUF.DisableBlizzard = orig

Damn... why did I not come up with this :eek:

Thanks for the tip!

Rainrider 05-28-18 12:29 PM

Why do you want to leave stock ui frames shown? Does the player frame come into question? If so, do you care about stuff handled by oUF elements like totems, additional power or the stagger bar? If the answer to the last two question is yes, you will have to poke into oUF elements that disable stock ui elements.

Eungavi 05-28-18 07:22 PM

Quote:

Originally Posted by Rainrider (Post 328179)
Why do you want to leave stock ui frames shown? Does the player frame come into question? If so, do you care about stuff handled by oUF elements like totems, additional power or the stagger bar? If the answer to the last two question is yes, you will have to poke into oUF elements that disable stock ui elements.

I'm sorry, but what's Stock UI?

The only reason that I'd like to keep the default player frame is because I'm willing to create an extra player frame with oUF in the center of the screen (on top of the default one).

It's like the personal resource display thing that Blizzard added since the Legion. The only difference is this will be an unitframe, not nameplate.

Kanegasi 05-28-18 09:00 PM

Quote:

Originally Posted by Eungavi (Post 328182)
I'm sorry, but what's Stock UI?

Another term for default. Stock UI is what you see with no addons installed. It comes from the economic market, specifically car parts, where a stock item is what the manufacturer intended to be installed.

Eungavi 05-28-18 09:48 PM

Quote:

Originally Posted by Kanegasi (Post 328183)
Another term for default. Stock UI is what you see with no addons installed. It comes from the economic market, specifically car parts, where a stock item is what the manufacturer intended to be installed.

A Ha!

Sorry, I'm still weak at those high level(?) terminologies :o


All times are GMT -6. The time now is 01:14 AM.

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