WowAce

It might be convenient to have a Code section (perhaps only visible when LuaTexts or similar module is enabled) that allows us to define our LuaTexts once, so they can be reused with just a click in the desired layouts.

For example, Player unitframe uses LayoutPlayer and Target unitframe uses LayoutTarget. I have a Code called "Level" that I want to use in both unitframes. So I edit both Layouts and simple select the "Level" text from a drop-down menu, instead of having to copy-paste and propogate corrections etc.

I wish to reuse snippets of Code throughout PitBull4, in the same way that the Layouts section allows me to reuse unitframe settings.

EDIT: It just occurred to me that this Code section doesn't have to be LuaTexts specific, and that there might be some value in using this for DogTags too.

This would be especially useful for the Event memory. I find myself looking at new tags with a confused expression until I realize I forgot to attach the Event.

Designing / brainstorming: (comments please)
 * Useful for DogTags and LuaTexts
  * Keep database of pre-defined and user-defined codes
  * Should not be implemented as part of either one alone
  
 * PitBull only related? (or "Would make a lib sence?")
  - LuaTexts also used by eg. CowTip
  - DogTag used by many unit frame mods, eg. UnderHood
  + Different addons have different text styles
  - Often same information is needed, eg. "Health: Smart"
  
  * "Text database library" would be to generic for itself?
   * Distribution and addition of codes via SharedMedia? (new type="DogTag", type="LuaTexts")
     Quote: "Shared handling of media data (fonts, sounds, textures, [predefined DogTags, predefined LuaTexts ]...) between addons."
    + Would make distribution of third party codes really easy and straight forward
    + Easy and solution which many addons might use
    - SM original designed to share "media", eg. images not text
    
 * What functionality would be needed?
  * Add predefined default codes (on addon load)
   * (OPTINAL) Not editable
   * (OPTINAL) Not deleteable
  * Add new codes (with events) on run time
   * Ability to edit/readd those codes
   * Ability to delete those codes
  * Callbacks when new codes are added
 
 * How to integrate into PitBull4?
  [For now, let GetLuaTextCodes(), GetDogTagTextCodes() and NEW_MEDIA_EVENT be methods that return those predefined codes (indepentend of how or where those are implemented)]
  * Changes needed to PitBull4_LuaTexts
   * LayoutOptionsFunction(function) needs to be able to cope with GetLuaTextCodes()
    * 'default_codes' -> get and set functions need to be changed
    * 'default_codes' -> values need to be replaced
   * Watch NEW_MEDIA_EVENT and refresh LayoutOptionsFunction(function)
  * Changed needed to PitBull4_DogTagTexts
   * Not taken a deep look yet, but should be roughly the same

LuaTexts between CowTips and PitBull4 isn't really compatible. The CowTip version is a modified version of the PitBull4 version but there is no library. LuaTexts is too tied into the operation model of PitBull4 to stand on its own as a library. Moving it into a library would give up some of the efficiency that being tied to PitBull4 gives. So I didn't turn it into a library.

This should go into ModuleHandling/TextProviderModule.lua and into a new file under Options. Really all this would end up doing would be to abstract the code from the text providers, similar to how layouts were abstracted from the unit frame configuration.

Overloading SharedMedia doesn't really seem appropriate. Code isn't particularly hard to share now. And I have other thoughts on how to make the code easier to share for LuaTexts. In particular, moving the events into the code section rather than being a drop down. I just haven't gotten to it.

Implementation wise, you shouldn't add functions that are named like GetLuaTextCodes...

Rather I see the implementation like so:

Codes would be indexed by a name ModuleName:Name or Custom:Name. Would require that Custom not be a valid module name and that : be disallowed in module names but that would be fine. Name would have no restrictions.

Codes themselves would be stored as opaque values, PitBull4 would make no assumptions as to what sort of type was the stored value, it could be a table or a string or really anything.

Text provider modules would have a function added to their template to register the configuration table for displaying and editing their codes.

Any module could register pre-defined codes. They'd do so like so: Module:RegisterDefaultCodes(text_provider,table_of_key_value_pairs); text_provider is the module (by string or by table) that can render the codes. These codes would not be deletable but can be edited. If a user edits a Default code it would be transformed into a Custom code. The user would be prompted if they wanted to convert all references to Module:Code to Custom:Code. If a Custom:Code already exists we could do something like Custom:Code 2 or simply error out of the edit.

Codes internally would be stored with a table for each text provider module. Within that table would be tables for each module providing pre-built codes, plus a Custom table. Unlike currently default codes would not be copied to the profile, and would only be provided by their module. This prevents the problem we have now where when default codes are changed users must reselect the default or they will keep the existing code. This meant that codes with bugs couldn't be fixed without user action and the issue would linger.

Iterator functions would be provided to walk over the codes. Getter/Setter functions. Callbacks for changes.

The code edit box under Layout would be removed and replaced with only a drop down. A new Code section would be added to edit these codes. The dropdown for selecting a code would be laid out like so:

Custom:
  Mine
  Foo
  Bar
HealthBar:
  Smart
  Absolute
  Short
...

Migrating existing configuration would be done by looking to see if a code is the same as a default under the new system. If so it would not be duplicated. If not the code would be converted to a Custom. Some detection should be added to deal with old buggy versions of the default codes to detect them as matching the default codes.

That should cover pretty much all the issues.

Quote:

LuaTexts between CowTips and PitBull4 isn't really compatible. The CowTip version is a modified version of the PitBull4 version but there is no library. LuaTexts is too tied into the operation model of PitBull4 to stand on its own as a library. Moving it into a library would give up some of the efficiency that being tied to PitBull4 gives. So I didn't turn it into a library.
Overloading SharedMedia doesn't really seem appropriate. Code isn't particularly hard to share now. And I have other thoughts on how to make the code easier to share for LuaTexts. In particular, moving the events into the code section rather than being a drop down. I just haven't gotten to it.

The point I tried to make was more that maybe other addons (eg. IceHud) might benefit from such a "code database" too, but my fear was that implementation might just get too general.
That said I think, using a separate library seems unintuitive and (ab-)using SharedMedia would only mean another dependency.

Quote:

This should go into ModuleHandling/TextProviderModule.lua and into a new file under Options. Really all this would end up doing would be to abstract the code from the text providers, similar to how layouts were abstracted from the unit frame configuration.
Codes themselves would be stored as opaque values, PitBull4 would make no assumptions as to what sort of type was the stored value, it could be a table or a string or really anything.
Text provider modules would have a function added to their template to register the configuration table for displaying and editing their codes.
Any module could register pre-defined codes. They'd do so like so: Module:RegisterDefaultCodes(text_provider,table_of_key_value_pairs); text_provider is the module (by string or by table) that can render the codes. These codes would not be deletable but can be edited. If a user edits a Default code it would be transformed into a Custom code.The user would be prompted if they wanted to convert all references to Module:Code to Custom:Code. If a Custom:Code already exists we could do something like Custom:Code 2 or simply error out of the edit.
Codes internally would be stored with a table for each text provider module. Within that table would be tables for each module providing pre-built codes, plus a Custom table. Unlike currently default codes would not be copied to the profile, and would only be provided by their module. This prevents the problem we have now where when default codes are changed users must reselect the default or they will keep the existing code. This meant that codes with bugs couldn't be fixed without user action and the issue would linger.
Iterator functions would be provided to walk over the codes. Getter/Setter functions. Callbacks for changes.

Sounds good.

Quote:

Codes would be indexed by a name ModuleName:Name or Custom:Name. Would require that Custom not be a valid module name and that : be disallowed in module names but that would be fine. Name would have no restrictions.

Wouldn't this mean that custom text would be shared by (for example) DogTags and LuaTexts?
(Offtopic: What about serializing ModuleName and Name?)

Quote:

Migrating existing configuration would be done by looking to see if a code is the same as a default under the new system. If so it would not be duplicated. If not the code would be converted to a Custom. Some detection should be added to deal with old buggy versions of the default codes to detect them as matching the default codes.

My idea would be to add some additional variables to each code (predefined or custom), that is

• For predefined and predefined -> custom (predefines that where changed) a version number. (Might be nil for real custom codes)
  
• And for predefined -> custom a reference name of the original predefined code. (Might be nil for real custom codes)

Quote:

The code edit box under Layout would be removed and replaced with only a drop down. A new Code section would be added to edit these codes. The dropdown for selecting a code would be laid out like so:
Custom: Mine Foo Bar HealthBar: Smart Absolute Short ...

Should this represent one line of the dropdown or actually two? I'm confused.

Quote:

Wouldn't this mean that custom text would be shared by (for example) DogTags and LuaTexts? (Offtopic: What about serializing ModuleName and Name?)

No, the ModuleName is the module that is providing the code, not the text provider module that will render it. Like I said further on down there would be a separate table of codes for each text provider. As a result you could have a LuaText code and a DogTags code with the same names (e.g. a module providing both types of codes). So the unique key to get the code would require the text provider module that would render it and the name.

Quote:

My idea would be to add some additional variables to each code (predefined or custom), that is

For predefined and predefined -> custom (predefines that where changed) a version number. (Might be nil for real custom codes) And for predefined -> custom a reference name of the original predefined code. (Might be nil for real custom codes)

Don't really see the value in this. What would it be good for? Once the code has diverged from the default there's really no value in knowing which code it diverged from. We're not going to build something into PitBull4 to merge changes in.

Quote:

Should this represent one line of the dropdown or actually two? I'm confused.

Formatting got eaten, I'll update the original post.

I am not sure if I should comment here or make new tickets but here are few additional ideas: 1) ability to "copy" an existing code to create a new one, as an alternative to a blank item. I know ctrl-a exists but it would be nice to start with predefined categories and such. 2) few additional "templates" like a snippet of code showing icon of a debuff, or texts based on priority of multiple conditions, or text that changes if the unit is target or is on mouseover. This would help a lot to newer users who might not be familiar with WoW API but still need grid indicator like features or more finely tuned UIs (and even for more experienced people who are in a hurry and needs to set something up mid-raid).

Thanks for this awesome add-on.

Lanalei, you can copy existing code by selecting the code and then making a new code while your source code is selected. This is pretty much the standard way to copy "objects" in PitBull4. But it probably isn't 100% obvious.

Regarding the templates. I'd be open to accepting some templates to add to the documentation for LuaTexts, but I don't really want to include codes that aren't really usable out of the box in the defaults. While these template codes might be useful for more technically oriented users, I think they would be more confusing to the less technically oriented users. In fact there's probably a lot of room for the LuaTexts docs to be improved.