The 1.4 list

[haste]

The current 1.4 definition of :Spawn is:
- :Spawn(unit, overrideName)
- :SpawnHeader(overrideName, template, showSolo, showParty, showRaid)

show{Solo,Party,Raid} is used to toggle visibility of the header. Setting showParty to true and showRaid to nil/false will actually hide the header, unlike the default behavior of the attributes.

[yaroot]

Originally Posted by haste The current 1.4 definition of :Spawn is: - :Spawn(unit, overrideName) - :SpawnHeader(overrideName, template, showSolo, showParty, showRaid) show{Solo,Party,Raid} is used to toggle visibility of the header. Setting showParty to true and showRaid to nil/false will actually hide the header, unlike the default behavior of the attributes.

The idea of custom visibility is good, but what's the profit of just doing this? People still need to set attributes like showSolo.
And I think that it should be more flexible, with custom condition supporting like toggle the raid frame according to different type of instance: 10 man/25 man instance, or 40 man battleground.
Just an idea

[haste]

Originally Posted by yaroot The idea of custom visibility is good, but what's the profit of just doing this? People still need to set attributes like showSolo.

The reason people still have to set their own is simply because visibility doesn't always overlap the show attributes.

Originally Posted by yaroot And I think that it should be more flexible, with custom condition supporting like toggle the raid frame according to different type of instance: 10 man/25 man instance, or 40 man battleground. Just an idea

Adding support for 10/25/40 separation isn't too much work.

[haste]

The tag syntax has been slightly changed in 1.4.
Some examples
1.3: [(>)tagname(>)]
1.4: [>>tagname<>]
1.3: [( | )tagname( | )]
1.4: [ | >tagname< | ]

The main reason for the syntax change is simply readability.

The tag names are also a lot less restrictive when it comes to characters they can include. And the API was also changed slightly as it now supports both functions and strings as tag functions.

The last thing is that all the functions will have a custom environment set which contains the following custom globals:
- Hex(): The same old Hex() function which was used internally, but not exposed.
- ColorGradient(): Same old.
- _TAGS: Reference to the internal table of tags. It's there so you can easily call other tags from within your tags.
- _CLASS_COLORS: Reference to the currently updating frames self.colors.class.

[p3lim]

Could you possibly add the whole colortable to the enviroment (_COLORS or something) in 1.4?

Edit: just tested the new tag system, the error prints seems incomplete

[haste]

Originally Posted by p3lim Could you possibly add the whole colortable to the enviroment (_COLORS or something) in 1.4?

yes

Originally Posted by p3lim Edit: just tested the new tag system, the error prints seems incomplete

They aren't.

[p3lim]

Originally Posted by haste yes They aren't.

Line 272 and line 290 in tags.lua, debug prints I guess.

Anyways, thanks for the color table expose

[haste]

Originally Posted by p3lim Line 272 and line 290 in tags.lua, debug functions I guess.

They're there because it isn't really tested. I currently only have unit tests for the tag parsing/event handling, not for the actual tag compiling and such.

[p3lim]

Also, just curious, is it possible to add custom functions and alike to the tags environment?

[haste]

Originally Posted by p3lim Also, just curious, is it possible to add custom functions and alike to the tags environment?

Not to string based tags. Function based can have their own environment set and oUF won't change it over to it's own.

[haste]

I've leisurely started to do wiki pages[1] on oUF over at GitHub, so those who want can give a helping hand. You generally shouldn't have to worry too much about quality for now .

There's still some changes missing in the 1.4 branch when it comes to the element system, so I'd advice people not to tackle a "General element usage" page just yet. Also the "API Documentation and Reference" list on the Home page can be discarded. I tried to map it all out yesterday, but I'm quite far from satisfied with the list. Feel free to take a stab at improving it tho'. :3

[1] http://wiki.github.com/haste/oUF/

[MoonWitch]

Originally Posted by haste The tag syntax has been slightly changed in 1.4. Some examples 1.4: [>>tagname<>] 1.4: [ | >tagname< | ]

Could you tell me what which does?
I'm slightly confused.

Eg
[>>curhp<>] outputs : <1234>
and
[ | >curhp< | } gives | 1234 |

Am I correct?

[haste]

Originally Posted by MoonWitch Could you tell me what which does? I'm slightly confused. Eg [>>curhp<>] outputs : <1234> and [ | >curhp< | } gives | 1234 | Am I correct?

[>>curhp<>] gives >1234>.
[ | >curhp< | ] gives | 1234 | .
Absolutely horrible writing that on my phone

[MoonWitch]

Originally Posted by haste [>>curhp<>] gives >1234>. [ | >curhp< | ] gives | 1234 | . Absolutely horrible writing that on my phone

So the >< around a tag allow you to "attach" a symbol (or perhaps other tag) to it based on which arrowpoint (whatever we call them lol) is located where.

Imba. Thanks haste!! And writing that on a phone must be hell :P