• 0

    posted a message on ScrollFrame problems (nested frames)
    The problem with the scrollframe resizing to fit the scrolled editbox can be worked around, I don't use the blizzard scrollframe templates for the AceGUI scrolling, only for the scroll bars themselves. Managing the size of the scrollchild and the range of scrolling can be done yourself to have better control.

    For the problem of the editbox getting mouse events outside the scroll frame, does an EditBox obey :SetHitRectInsets() ? It might be a way to manage which part of the editbox is clickable ourselves if scrollframes aren't fixed. I can't test from here but will when I get home if noone else has.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Trying out Ace3 config
    Once AceConfigDropdown is being worked on, the Dropdown controls will be replaced to use the same base code for building the dropdown lists. The current controls are direct copys from waterfall that I've always planned on replacing.
    Posted in: Ace3
  • 0

    posted a message on Trying out Ace3 config
    Well the original design goal was to create a base for me to build the successor to Waterfall on top of, It just ended up being generic enough that I got asked to commit it as AceGUI. There isnt any documentation outside of the comments right now, I want to get AceConfigDialog feature complete before working on other things.

    Widgets don't support inheritance explicitly, but theres nothing to stop a derived widget being created.

    From AceGUI's perspective all a widget 'class' is, is a function that will return a new instance. To get a derived widget, have your function grab an instance of the base widget, layer your stuff on top, change its type and return that. This is sort of already done with the DropdownGroup widget. It uses a dropdown widget that becomes part of the DropdownGroup widget and is never released on its own.

    control and dialogControl have been implemented in AceConfigDialog now, the AceConfig3 wiki page has the function and callbacks that a widget needs to implement to be usable. I've attached a screenshot of my test Config table, which has a custom control (DragTarget, works similarly to an action button, can drag on/off, accepts Items, Spells and Macros)
    Posted in: Ace3
  • 0

    posted a message on Trying out Ace3 config
    Its a simple code change, its a reasonable amount extra to go into the spec for what a widget has to be to be usable. The widgets weren't designed with a clean API in mind as I diddn't expect them to be replacable. I've got the code ready to go in, just making sure the API is sorted before people start developing against it.
    Posted in: Ace3
  • 0

    posted a message on Trying out Ace3 config
    If you are trying to delay building options untill they are requested then registering a function instead of the options table will let you do that.
    Posted in: Ace3
  • 0

    posted a message on Trying out Ace3 config
    Modules adding options to the base addons table would be the perfect example.

    The original idea was for things like the profiles options above where instead of having options injected into args directly, they have a place that they can be put that allows them to be updated / removed if necessary.

    Note that the keys used still have to be unique across args and all plugins for all the options to show, if there is a conflict only one of the options will show, plugins taking preference over args, clashes between plugins being undefined (plugins that come first when iterating them with pairs will take priority generally)

    local opts = {
     type='group'
     args = {
      Option1 = {...},
      Option2 = {...},
     },
     plugins = {
      ["Module1"] = {
        Option2 = {...},
        Option3 = {...},
      },
      ["Module2"] = {
        Option3 = {...},
      },
     }
    }

    In this example the result is 3 Options in the group. Option2 would come from Module1, the one in args wouldn't be accessable. Option3 will come from either Module1 or Module2, depending which comes first when you do for x in pairs(plugins)
    Posted in: Ace3
  • 0

    posted a message on Trying out Ace3 config
    Quote from Yssaril »

    alright next thing :P

    how do i use the plugin thing in the option tree

      * plugins subtable, containing named tables with more args in them, e.g. 
    
        plugins["myPlugin"]={ 
         option1={...}, option2={...}, group1={...} } 
        plugins["otherPlugin"]={...} 
    
      This allows modules and libraries to easily add more content to an addon's options table. 


    doesn't really explain much except that i can inject other option tables somehow


    Plugins is very simply just set of extra named args. Used to inject extra options into a group without having to manually copy them into the args table, and allowing them to be removed easily.
    e.g
    local opts = {
     type='group'
     args = {
      Option1 = {...},
      Option2 = {...},
     }
     plugins = {
      ["Module1"] = {
        Option3 = {...},
      }
     }

    is exactly the same set of options as if Option3 was in the args table with the other 2
    Posted in: Ace3
  • 0

    posted a message on Trying out Ace3 config
    A heading will act as a line break, I'm guessing you're after something that isnt visible itself tho ?
    Posted in: Ace3
  • 0

    posted a message on Trying out Ace3 config
    dialogControl (the proper name for dlgType) would be used as an attribute of an existing type, to change the widget that is used to represent it from e.g EditBox to MyCustomWidget. This would still be used by AceConfigDialog in exactly the same way as an EditBox would, so the custom widget would have to have the same API as an EditBox.

    Posted in: Ace3
  • 0

    posted a message on Trying out Ace3 config
    You can make and register custom widgets, but they are not usable from an options table right now.

    There will never be a way to register it as a completely new type, whats being discussed is being able to use it instead of the normal widget for an existing type.
    Posted in: Ace3
  • 0

    posted a message on Trying out Ace3 config
    Quote from Yssaril »

    is there anyway to pass something to the error msg part of the config window?

    If a validate function returns a string that will be used as the error message.
    If usage is set on an input option then it will be the message when that option fails validation or the pattern check.
    Posted in: Ace3
  • 0

    posted a message on Trying out Ace3 config
    Even with being able to specify a new Layout function there would still be no way to get the size information to it from the options table. Replacing this function isn't the way I'd go about implementing a width parameter anyway, the Layout is made to handle controls of any size.

    What are the situations where you want to be able to control the width of the options ? Having something like width = 250 in the spec is something that I don't think should happen. But i'd be open to discussion on something like wide = true on the input type so options that take long strings can be marked as such.

    Basicly trying to keep the options table away from requirements like 'this option should have a width of 256' more towards 'this option often takes big strings as input' leaving the implementation able to do what makes sense for its view of the options.

    Edit: Another note is that it is trivial to integrate an AceConfigDialog generated set of options into a custom AceGUI dialog, a very simple example is ConfigWrangler (which has been integrated into the Ace3 standalone addon). So if you have one section of your config that needs a specialized GUI it doesnt mean you have to completely abandon the Options table format.


    Posted in: Ace3
  • 0

    posted a message on Trying out Ace3 config
    The table will be re-parsed every time a set / func callback is completed so most of the time you can just change the table and it will be fine.

    The method that you call to trigger a refresh when its needed is
    LibStub("AceConfigRegistry-3.0"):NotifyChange("AddonName")

    This will trigger an event that any lib using the config table can listen for and act appropriately (Only AceConfigDialog does right now, but it may not stay the only gui implementation of the spec)

    A general guideline for when to use this is when the options table changes outside of a set/func function when the Config could be open.

    Currently theres a bug with AceConfigDialog where triggering a refresh from a callback will cause errors, once that is fixed it won't matter if you trigger one every time the table changes, but its unnecessary when its from a callback since a refresh happens then anyway.
    Posted in: Ace3
  • 0

    posted a message on Baggins - Official Thread
    I've fixed the Compress Ammo option, was a typo stopping it working in addition to not being localized

    Krothbot: Looks like you have a Category rule pointing at an Invalid Category. I've hopefully made the rule not error in this case, it will just not match anything. Let me know if the problem continues.
    Posted in: General AddOns
  • 0

    posted a message on Baggins - Official Thread
    Is everyone that is not getting ammo compressed non enUS ?
    I've just checked and I missed localizing the check in the compression function when I switched from PT set to item type checking for ammo.
    Will be simple to fix once I get home and can commit it.

    I'll add a check for empty profile names as well to prevent the error thats stopping the menu from appearing.
    Posted in: General AddOns
  • To post a comment, please or register a new account.