New UI for LibAddonMenu r17 (update 1.6)?

circonian · 02/05/15, 02:42 AM

Originally Posted by Sasky

How would they fit to the left of the text? If on the far right, there'd be a lot of space between label and control. The checkbox (or on/off) portion is fixed width though, and would be right next to the label.

As far as skins, there's a couple different levels. One would be the overall layout and the other would be the individual controls.

As for the empty space, that is what "half" width is for, well one of its uses. If your text isn't that long use "half" width.

As for the Fixed width...Just change it and make it a different "fixed" width

Make it just big enough for the words on the button, a little padding, & anchor it differently to allow for more room for text.

Although Your idea of putting the buttons on the left is probably a better idea.

If you guys come up with any ideas you want to implement & want any help with anything just let me know, I'de be happy to pitch in.

votan · 02/05/15, 04:07 AM

Ya, the problem I have with the "half" option is localization. Allowing/Enabling localization makes the definition of "isn't that long" very difficult. Text may small in english fitting "half" and when is squeezed in other languages.

One example always disturbing me a little bit:
Item tooltip:
"Bound upon equip"
=
"Wird beim Anlegen gebunden"

1.75x width. Causing a word wrap, effecting the line height on the left side, too.

Originally Posted by circonian

As for the empty space, that is what "half" width is for, well one of its uses. If your text isn't that long use "half" width.

circonian · 02/05/15, 04:41 PM

Originally Posted by votan

Ya, the problem I have with the "half" option is localization. Allowing/Enabling localization makes the definition of "isn't that long" very difficult. Text may small in english fitting "half" and when is squeezed in other languages.

One example always disturbing me a little bit:
Item tooltip:
"Bound upon equip"
=
"Wird beim Anlegen gebunden"

1.75x width. Causing a word wrap, effecting the line height on the left side, too.

Originally Posted by circonian

As for the empty space, that is what "half" width is for, well one of its uses. If your text isn't that long use "half" width.

I was only referring to the question someone asked about what to do with all of the blank space between the description text & the button, if the description text is short. IF the text is short, then it should probably be using "half" width, but "full" width should actually be "full" width.

I'm in complete agreement with you, that is why I suggested the change. Somehow it needs to be more flexible.

sirinsidiator · 02/05/15, 04:14 AM

Many good ideas! Keep 'em coming

I like the idea of using templates to change the style.
How about allowing two levels of customization?

Allow the user to download additional style packages that change the default look of libAddonMenu
Give addon devs a way to change the look of their own settings panel

That should cover all the things that where proposed so far and allow them without the need to update the main lib for every change in style.

For the settings I will have to use one of the methods proposed here.

Using the ingame savedvars to store the settings requires minimal change, but at the same time feels a bit wrong because it puts library related stuff in a file that is not owned by it.
Putting libAddonMenu into a standalone addon might look a bit inconvenient at first glance, but it would also open a few new possibilities.
- Enables saved vars
- Removes the need to bundle it with other addons and update every addon when a new version is released
- Changes the load order so that the newest version of libAddonMenu is loaded first
- Which in turn prevents problems like this

We could also add some kind of version check that allows us to put out a warning when libAddonMenu has not been updated and an addon requires a newer version.

edit: forgot about the subcategories...
I don't like them either. I think addon specific things should stay on the right side of the menu.
Maybe we can use tabs instead?

merlight · 02/05/15, 06:24 AM

I like the borderless look, fits better in the UI. Even better if you manage to give the add-on list a different background (like Achievements window, for example). If not, a vertical divider between add-on list and settings pane should suffice.
I don't like that a stand-alone LAM would be required. Somehow I got fond of how most add-ons bundle everything they need.
Categories... hell yeah! But there's a trap. ESOUI categories are too many, overlapping, and blurry. For me at least. There should only be a few.
While you're at it, please change CreateTopLevelControl to CreateControl in each and every control constructor: http://www.esoui.com/forums/showpost...99&postcount=2

votan · 02/05/15, 07:14 AM

For a large addon list we already know a lot techniques:
- recent list
- favorites (does it make sense here?)
- user-defined groups (but the users must organize themself)

Would work if we have saved settings, only

Automatic grouping:
- First Letter (A-D, E-H, G-M ...) sound easy, but can be tricky if you want the ranges to be dynamic.
- Author (Garkin would still have a large list

) Does a user look for an addon by a specific author. No...

There could be some symbols (ESO works with symbols) or a dropdown, to switch view mode.

But we must be careful not to overload the effort with super duper high-end wishes.
I would start with a recent list and when grouping. Both optional and off by default.
Where must be something left for r18

PS: I think it is dangerous and un-maintainable, that each control has its own revision mangement and basically can come from "anywhere".

votan · 02/05/15, 07:51 AM

I know what you mean, but if we keep the "embedded" style, I'm afraid, there is no choice.
If the namespace is unique, I think it's ok. And if where is a breaking change in future, you can use the version number for migration and swipe out.

Originally Posted by sirinsidiator

Using the ingame savedvars to store the settings requires minimal change, but at the same time feels a bit wrong because it puts library related stuff in a file that is not owned by it.

Ayantir · 02/05/15, 08:36 AM

Hi,

Posted Screenshot is nice.

Get the "ESO Menus font" at the left is really cool. No borders as real options in eso. I think the user need to think he's not into an addon setting but in its game settings.

As circonian says, maybe add submenus in the panel available as an option. I find them actually ugly, but they're needed. A revamp of them into the settings section is also needed.

Also for panel section make an embedded colorization (like my code snip below) with ZO_HIGHLIGHT_TEXT:Colorize

Lua Code:

local panelData = {
        type = "panel",
        ....
        displayName = ZO_HIGHLIGHT_TEXT:Colorize("pChat"),
        submenus = true,
        width = 600
    }

When you reset to default, a reloadUI is done when 1 option get a reloadUI in its code.
In fact I think the whole options are set back to defaut, without loooking if the actual option is maybe at the default value. It could be interesting to fix this.

A Wider panel is absolutly needed ! In French and German, it's really hard to put comprehensive labels. English get a majority of little words, other languages not.
PS : A better way would be to manually set this option in addons (in panel section!) with an option like in my code above. It will set the width of the right section of the options. (without the addon list). if under your min val, ignored, if its the max set it for all addons. Some addons really need a very long list.

Try to fix the \n problem in description!
Wrote a description, put some \n\n and put something under you'll see the bug.

A search window for options based on labels
Look at pChat, it's horrible to set an option , as I got tons of options inside this addon. think Wykkyds got same problem.

If it's possible, try to implement back the dual colorpicker button. But it was a puddy tweak. I don't really know if it will be interesting. It's a label and 2 colorpickers. it returns r1, b1, g1, r2, b2, g2 instead of r, g, b

An option or something for rebuild LAM !
In some of my addons, a part of the option table is build by code, not manually set. In fact a got a block per guild. and when user join/leave a guild, I rebuilt LAM. but if the user has already get a look into LAM before, it won't rebuilt. Please have a look.

Add invisible option.
If LAM got "disable" value, could you see if invisible is do-able ? the option will get a true/false value required, built by one of our function as disable work. When 1 option control 10 others, invisible could be nice. controlled by SetHidden and maybe a smooth option if it's possible

For other suggestion.. Categorys, It's really a trap. I got an adddon GuildNotificator, It notifys in "chat", "guildmates" connexions. Does this addon go in chat, guild, both ? Could an addon be in 1+ category?
If we add those, I really think we need to add categories only if a category is populated by 2+ addons. If user only got 1 guild, 1 chat, 1 pvp, and 1 craft addons, it won't be displayed. But if he get 2pvp per exemple, categorys could be displayed. And a little checkbox at the top of the addon list "regroup Addons per category"

votan · 02/05/15, 09:22 AM

I have a similar problem. My unreleased solution (using Harven's Addon Settings) is to make EVERY configuration property able to be a callback. It's basically:

Lua Code:

whateverControl:SetWhatEver(self:GetValueOrCallback(setting.whatever))

Every control is updated once the options fragment is re-opened or the selection has changed.
Harven's great implementation makes it smooth to do so.

GetValueOrCallback(arg) checks if "arg" is a function, and if so, calling it with "self", returning the value of the function. Otherwise returning "arg" itself.
In my case the number of controls is static, but for Ayantir a dynamic "setting.isHidden" could do what is needed to change the number of controls.

Originally Posted by Ayantir

An option or something for rebuild LAM !
In some of my addons, a part of the option table is build by code, not manually set. In fact a got a block per guild. and when user join/leave a guild, I rebuilt LAM. but if the user has already get a look into LAM before, it won't rebuilt. Please have a look.

Garkin · 02/05/15, 09:36 AM

After update to r16 because of Update 5, LAM doesn't properly select nodes in game menu tree when you open settings menu from slash command. Here is my (unfinished) solution:

Lua Code:

--METHOD: OPEN TO ADDON PANEL--
--opens to a specific addon's option panel
--Usage:
--  panel = userdata; the panel returned by the :RegisterOptionsPanel method
local locSettings = GetString(SI_GAME_MENU_SETTINGS)
function lam:OpenToPanel(panel)
    SCENE_MANAGER:Show("gameMenuInGame")
    zo_callLater(function()
            local settingsMenu = ZO_GameMenu_InGame.gameMenu.headerControls[locSettings]
            settingsMenu:SetOpen(true)
            SCENE_MANAGER:AddFragment(OPTIONS_WINDOW_FRAGMENT)
            KEYBOARD_OPTIONS:ChangePanels(lam.panelID)
            for i, child in pairs(settingsMenu.children) do
                if type(child) == "table" and child.data.name == KEYBOARD_OPTIONS.panelNames[lam.panelID] then
                    ZO_TreeEntry_OnMouseUp(child.control, true)
                    break
                end
            end
            panel:SetHidden(false)
        end, 200)
end

It is not finished yet, because there is still one issue - it doesn't properly select button in addon list and scroll list does not move to that button. If I want to fix that, I will have to get reference for addon button. Probably the best would be adding it to panel itself. I have to try what I can do without extensive changes to the code.

EDIT:
Button is selected, but scroll list scrolls to the button only if button list is already initialized, when you open LAM settings for the first time it doesn't work.

Lua Code:

--METHOD: OPEN TO ADDON PANEL--
--opens to a specific addon's option panel
--Usage:
--  panel = userdata; the panel returned by the :RegisterOptionsPanel method
local locSettings = GetString(SI_GAME_MENU_SETTINGS)
function lam:OpenToPanel(panel)
    SCENE_MANAGER:Show("gameMenuInGame")
    zo_callLater(function()
            local settingsMenu = ZO_GameMenu_InGame.gameMenu.headerControls[locSettings]
            settingsMenu:SetOpen(true)
            SCENE_MANAGER:AddFragment(OPTIONS_WINDOW_FRAGMENT)
            KEYBOARD_OPTIONS:ChangePanels(lam.panelID)
            for i, child in pairs(settingsMenu.children) do
                if type(child) == "table" and child.data.name == KEYBOARD_OPTIONS.panelNames[lam.panelID] then
                    ZO_TreeEntry_OnMouseUp(child.control, true)
                    break
                end
            end
            local scroll = LAMAddonPanelsMenuScrollChild
            for i = 1, scroll:GetNumChildren() do
                local button = scroll:GetChild(i)
                if button.panel == panel then
                    zo_callHandler(button, "OnClicked")
                    ZO_Scroll_ScrollControlToTop(LAMAddonPanelsMenu, button)
                    break
                end
            end
        end, 200)
end

votan · 02/05/15, 03:00 PM

New version including code from Merlight and Garkin.

Pic 1

But this is nice, too. The title is right aligned.
Pic 2

Source here. Changes effecting panel and submenu.

circonian · 02/05/15, 05:13 PM

Originally Posted by Ayantir

For other suggestion.. Categorys, It's really a trap. I got an adddon GuildNotificator, It notifys in "chat", "guildmates" connexions. Does this addon go in chat, guild, both ? Could an addon be in 1+ category?
If we add those, I really think we need to add categories only if a category is populated by 2+ addons. If user only got 1 guild, 1 chat, 1 pvp, and 1 craft addons, it won't be displayed. But if he get 2pvp per exemple, categorys could be displayed. And a little checkbox at the top of the addon list "regroup Addons per category"

Very good point and what happens when people start saying hey I'm going to put my addon in as many categories as possible so it shows up more to the user! It would just defeat the purpose of the categories. If categories need to be implemented it should not be up to the addon user what categories they are in. It should not be based on "features" but on something that allows each addon to ONLY fall under one category, for example some of the suggestions that have been posted, like a "recent" category or "A-D" "E-G", exc..just something that the addon dev does not get to choose multiple categories for, as much as some might say that is an unwanted restriction I think letting them choose might be worse.

Garkin · 02/05/15, 05:21 PM

Here is my update:

LibAddonMenu-2.0r17-Update6_beta.zip

- all widgets are now controls instead of top level controls
- submenu looks slightly different, label color now changes when menu is open/closed/mouseover

Randactyl · 02/05/15, 06:59 PM

Originally Posted by Garkin

Here is my update:

LibAddonMenu-2.0r17-Update6_beta.zip

- all widgets are now controls instead of top level controls
- submenu looks slightly different, label color now changes when menu is open/closed/mouseover

I like having the version and author right beneath the title. However, "Reset to Defaults" can look a bit orphaned especially on very short menus.

circonian · 02/05/15, 05:04 PM

Originally Posted by sirinsidiator

How about allowing two levels of customization?

Allow the user to download additional style packages that change the default look of libAddonMenu
Give addon devs a way to change the look of their own settings panel

That should cover all the things that where proposed so far and allow them without the need to update the main lib for every change in style.

I like the whole template/style package idea, BUT I think a user downloadable version should be restricted to the background. Like whether or not you want to see the original libAddonMenu borders, or no borders, or a darker background.

My main concern is a user downloadable style changing something it should not that messes up the layout/look of the addon panel we create for our addons. For example what if I had two settings set to "half" width, but a user downloads a style that widens the buttons/droopdown box and now they no longer fit next to each other in "half" width. I wouldn't want them changing any color schema I set up for my panel either.

Originally Posted by sirinsidiator

For the settings I will have to use one of the methods proposed here.

Using the ingame savedvars to store the settings requires minimal change, but at the same time feels a bit wrong because it puts library related stuff in a file that is not owned by it.
Putting libAddonMenu into a standalone addon might look a bit inconvenient at first glance, but it would also open a few new possibilities.
- Enables saved vars
- Removes the need to bundle it with other addons and update every addon when a new version is released
- Changes the load order so that the newest version of libAddonMenu is loaded first
- Which in turn prevents problems like this

I'm not sure I get this, what kind of settings are we talking about saving?
The ingame savedvars is what I used for LibNeed4Research, but I admit I too didn't really like the idea of putting the savedVars in there.
However, since this is used by so many addons & every addon has to include it I think the standalone idea is a pretty good one.

Just force everyone to depend on it or add some way to check (without watching for it to load in OnAddonLoaded) to see if LibAddonMenu has been loaded AND what the current version is, before creating the settings menu. This way addons could create the settings menu or not, depending upon if LibAddonMenu is installed & if it is the correct/up to date version, so that the addon could function either way the user just wouldn't be able to change settings without it.