282 - Feature request: Sorting for AceConfig select controls

What is the enhancement in mind? How should it look and feel?

Currently the data input to AceConfig "select" controls is:

  values (table|function) - [key]=value pair table to choose from, key is the value passed to "set", value is the string displayed

This provides no facility for sorting the options in an order that makes sense to the user + application, and in fact AceConfigDialog renders the table in a random order that can even change between window openings. In some applications, especially those using multiple radio button selects, this leads to very confusing option screens.

I would a feature that allows the client to specify a sorting order for the display, where supported.

One possible interface would be to add a new optional member like:

  sort (function(k1,k2)) - An optional sorting comparison function that requests the options be displayed in a sorted order when supported. The function takes two keys from the values array and returns true when k1 should appear before k2 in a sorted display. For example, if the keys are integral values one could sort the display by increasing key with sort = function(k1,k2) return k1 < k2 end

User When Change
oscarucb Jan 13, 2012 at 13:59 UTC Create

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

  • Avatar of oscarucb oscarucb Apr 06, 2012 at 19:25 UTC - 0 likes

    Thanks mikk- your new change allows me to sort the radio buttons in the order I want, although I did have to add an additional level of indirection in my key implementation to arrange for the desired display sort when the keys are sorted alphabetically.

    I still think allowing an optional client-provided sort function for the keys would provide greater display flexibility to addons using select controls in their config, without complicating their key implementation.

  • Avatar of mikk mikk Apr 02, 2012 at 13:23 UTC - 1 like

    r1049 does sorting by value also for style="radio", which is a step in the right direction.

  • Avatar of oscarucb oscarucb Mar 24, 2012 at 08:32 UTC - 0 likes

    To clarify, this bug/enhancement is primarily concerned with AceConfig widgets of type="select" with style="radio". The radio button UI makes the most visual sense for my addon's config needs, which is why I selected it. A dropdown control would be a poor visual choice for this config scenario.

    Type="select" with style="radio" currently generates a grouped set of radio buttons, which appear in a *completely random* order, and furthermore there is no way for the client to request sorting them in a logical way. I'm asking for an option to sort them in a specific way, or at least in a predictable way, so that the radio buttons aren't scrambled differently each time you open the window. I don't think anyone would argue that shuffling the radio buttons randomly each time you open the config is a "good" behavior.

    Non-radio selects, ie dropdowns, are a different control which are not my primary concern - however now that you bring it up the AceConfig client has limited control over the sorting for those controls. Currently AceGUI sorts them strictly by key, which is a reasonable default but is not necessarily what makes the most sense for a given client. Clients have to select their keys specifically to arrange for a desired sort order in the UI, which unfortunately conflates key choice (an internal addon design issue) with config UI sorting (a pure display issue). Again, an optional sort parameter would provide the AceConfig client with additional flexibility here.

  • Avatar of Nevcairiel Nevcairiel Mar 24, 2012 at 07:51 UTC - 0 likes

    If you talk about a select control, a dropdown comes to mind, which is sorted. :D

  • Avatar of oscarucb oscarucb Feb 12, 2012 at 18:41 UTC - 0 likes

    mikk said: They take an optional "order" table (key=value),

    Those are the dropdown controls in AceGUI, which have nothing to do with the select controls in AceConfig.

    Nevcairiel said:

    OK, AceGUI allows sorting, however AceConfig doesn't expose it. Nevertheless, it should never be random. Both select and multiselect are sorted by the keys of the values.

    I assure you the current AceConfig results in indeterminate order - at least in the case of "radio" select controls, which is the one I'm most interested in. Here is the actual code from AceConfigDialog-3.0.lua line 1178:

    elseif v.type == "select" then
            local values = GetOptionsMemberValue("values", v, options, path, appName)
            if == "radio" then
                    local optionValue = GetOptionsMemberValue("get",v, options, path, appName, value)
    >>>>>>          for value, text in pairs(values) do
                            local radio = gui:Create("CheckBox")
                            InjectInfo(radio, options, v, path, rootframe, appName)

    The line marked with a >>> iterates over the user-provided values array in a random order (the lua pairs function does NOT provided a sorted traversal) and inserts the radio button checkboxes into the parent container.

    Sorting the options by key would be a nice step and would solve my immediate concerns, but you'd need to ensure correct behavior when the keys are not strings.

  • Avatar of Nevcairiel Nevcairiel Feb 10, 2012 at 14:23 UTC - 0 likes

    OK, AceGUI allows sorting, however AceConfig doesn't expose it.

    Nevertheless, it should never be random. Both select and multiselect are sorted by the keys of the values.

  • Avatar of mikk mikk Feb 10, 2012 at 14:23 UTC - 0 likes

    They take an optional "order" table (key=value), which is not exactly what this ticket requests.. but it also solves the problem of perhaps not having enough info in the sort function to sort meaningfully.

  • Avatar of Nevcairiel Nevcairiel Feb 10, 2012 at 14:19 UTC - 0 likes

    I think there actually was a way to sort the options in a multiselect or select group, i'll have to check the code.

  • Avatar of oscarucb oscarucb Jan 13, 2012 at 14:02 UTC - 0 likes

    The same would also make sense for multi-select controls, for all the same reasons



Jan 13, 2012
New - Issue has not had initial review yet.
Enhancement - A change which is intended to better the project in some way
Medium - Normal priority.

Reported by

Possible assignees