PitBull Unit Frames 4.0

431 - Code section to reuse LuaTexts or DogTags

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.

User When Change
Stanzilla Nov 04, 2013 at 22:19 UTC Changed assigned to from ckknight to Shefki
Shefki Jun 22, 2009 at 21:15 UTC Changed priority from Medium to Low
Shefki Jun 22, 2009 at 21:15 UTC Changed status from New to Accepted
jokeyrhyme Jun 08, 2009 at 05:52 UTC Changed name from Code section for easy LuaTexts reuse to Code section to reuse LuaTexts or DogTags

Changed description:
  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.
+
jokeyrhyme Jun 08, 2009 at 05:23 UTC Create

You must login to post a comment. Don't have an account? Register to get one!

  • 7 comments
  • Avatar of Shefki Shefki Nov 04, 2010 at 15:25 UTC - 0 likes

    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.

  • Avatar of Lanalei Lanalei Nov 04, 2010 at 14:54 UTC - 0 likes

    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.

  • Avatar of Shefki Shefki Sep 24, 2010 at 04:33 UTC - 0 likes
    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.

  • Avatar of CommanderSirow CommanderSirow Sep 23, 2010 at 13:49 UTC - 0 likes
    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.

    Last edited Sep 23, 2010 by CommanderSirow
  • Avatar of Shefki Shefki Sep 22, 2010 at 05:37 UTC - 0 likes

    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.

    Last edited Sep 24, 2010 by Shefki
  • Avatar of CommanderSirow CommanderSirow Sep 21, 2010 at 18:10 UTC - 0 likes

    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

    Last edited Sep 21, 2010 by CommanderSirow
  • Avatar of sfan27 sfan27 Jun 21, 2009 at 22:10 UTC - 0 likes

    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.

  • 7 comments

Facts

Last updated
Nov 04, 2013
Reported
Jun 08, 2009
Status
Accepted - Problem reproduced / Need acknowledged.
Type
Enhancement - A change which is intended to better the project in some way
Priority
Low - Might slip to a later milestone.
Votes
24

Reported by

Possible assignees