New UI for LibAddonMenu r17 (update 1.6)?

[sirinsidiator]

I got some feedback from Seerah and also the OK to change the license in order to put LibAddonMenu on github.

Originally Posted by Seerah As for the conversation on the forums about LAM... My two cents' worth: A user should expect to download an addon and for it to "just work". This is why libraries get embedded. The "standalone libraries" usage is an "advanced users" concept over in WoW. That said, LAM and LibStub can already be installed standalone. LibStub is about 1.5 kb and LAM is about 58.7 kb. You're not saving much on your hard drive by pulling it out of 10 addons to have it installed standalone. And LibStub will only load the files into memory to upgrade a version previously in memory. If the first addon loaded is the newest, then the others return out as soon as they start to be read. If, by the end of the loading process, more than one copy of the library has been loaded into memory, they'll be tossed at the first garbage collection cycle. Libraries should not need saved variables. If a library needs saved variables, then the question should be asked whether it is a true library or an addon. Anything having to do with altering the look of the menu (templates, etc.) should be a separate addon. Most users won't care about that stuff, and fluff code like that does not affect the usage and purpose of the library itself. With it being a separate addon, you can then have a settings menu for it and saved variables. Oh, and there shouldn't really be a need to save what panel you're looking at across sessions. Convenient for a dev that's constantly reloading, yes. But that's a fringe-case scenario and not something the general user is concerned with. From a design standpoint, let me explain why the checkbox controls are as they are. LAM-1.0 used the game's own options control templates to create the LAM controls. When I made LAM-2.0, I kept them the same way so that they would be 1. consistent with both LAM-1.0 and with the default game settings, and 2. line up vertically with the other control types. If the general consensus is to make them different from the look of the game's settings, then so be it. For votan's comment PS: I think it is dangerous and un-maintainable, that each control has its own revision mangement and basically can come from "anywhere". The controls are in separate files than the main LAM core. To ensure that an older version of a control doesn't overwrite a newer one (because LibStub will only return out of loading the LAM core), they either have to register a version with LibStub or with LAM. I went with LAM so that it has full control over the controls. Also, other authors/addons can create their own control to register with LAM for their options. This could be contained in their addon, or a new library with addition control types could be developed. Also, an addon only including a few control types shouldn't have an effect on another addon that depends on a different control because that addon should be including LAM and the control files as well. As mentioned above, the controls get registered through LAM, and LibStub will only return out of an older LAM core, not the controls.

Following this advice I suggest that we either take all the extra things that are not required and put them into a standalone addon that always contains the newest LibAddonMenu and keep the library itself as simple as possible or scrap them completely.

Style templates are probably something nobody would use anyways. Might be easier and more useful to just add a settings panel where you can set line width, choose between a few different backgrounds and that's it.
The second level of customizations is probably also a bit over the top. Might be enough to let addon devs choose the column width of the panel, so they can adjust the layout for different languages.

The categories are something we can do without save vars in the base version and once a user installs the proposed addon, it will save the state.

Some possible names for the new addon that come to mind are "AddonMenuEnhanced", "EnhancedLibAddonMenu", "LibAddonMenuPlus", but I am open for suggestions

I'll set the github projects up later today or tomorrow.

[merlight]

Yesterday I mocked up some automatic grouping by the first letter, displayed it using ZO_Tree... and it looked and felt awful. So I scratched that.

In the process I really struggled with the main controls' construction and what the word "panel" means in different contexts, so I started reorganizing that a bit, properly parenting controls where they belong, and also pondering moving some definitions to XML. When I'm done with that I'll try adding a search filter, that seems like a lighter and easier-done-right alternative to categories.

[Garkin]

Originally Posted by merlight Yesterday I mocked up some automatic grouping by the first letter, displayed it using ZO_Tree... and it looked and felt awful. So I scratched that. In the process I really struggled with the main controls' construction and what the word "panel" means in different contexts, so I started reorganizing that a bit, properly parenting controls where they belong, and also pondering moving some definitions to XML. When I'm done with that I'll try adding a search filter, that seems like a lighter and easier-done-right alternative to categories.

I'm not sure about XML - how do you want to update XML templates? I believe that you will just get an error that control has duplicate name.

[votan]

@Seerah/sirinsidiator:

Hopefully, we didn't misunderstood each other.
I like the idea of allowing to register custom controls.
What I meant is: If you want to update the core controls, e.g. to use a master-width, you have to update 13 versions (core + 12 controls). I have forgotten to update 2 extra versions already. And this could happen to others, too.
I meant: core controls should come from the core file been used.
If it is consens to copy 13 files over and over again, I accept it. I just wanted to talk about that.

If I understood you right:
- We keep the embedded style => stateless => no saved variables => no settings => no visual preferences
- embedded style => no xml

We updating the UI a little bit, adding the fixes from Garkin and Merlight and that's it, right?

Edit 1: And may find a solution for a large addon list.

[Sasky]

Note that Wykkyd initially listed his framework as a require but since moved to embedded because it was unworkable. If Minion pulled dependencies automatically (already stated as a long-term goal)

As far as if it's still a library: that can be a bit loose with GUI and themes. See GTK+ for example.

Currently a separate addon could overwrite controls but not the settings menu. LAM could be refactored a bit to put the overall panel as a 'control' (in effect) to make it easily replaceable. That would allow external themes an entry to change the look of the overall menu.

As far as themes go, the easy way to switch between would be to only enable the addon for the theme wanted. Only one theme could be activated at a time, though. A theme manager could be implemented (again as a separate addon) and themes would register there instead of overriding LAM directly. I think this would be a bit overengineered, but it is an option.

Summary: default UI changes, add fixes, perhaps refactor the settings menu to be managed similarly to controls. Leave all theming as separate addons and no SavedVars from LAM itself.

[sirinsidiator]

@votan: If it is true that you have to change every single file for something like the column width, it might really require some change in structure. But you also have to ask yourself how often a change like this really happens.
I will look into this once I had time to read the code of LibAddonMenu. I only saw bits and pieces until now so I can't really comment on it yet.

And yes. We let the library be a library and if we really want extra themes and saved vars and stuff, we put that into a separate addon which will augment the library.

What I actually wanted to say is, I just created the project on github: https://github.com/sirinsidiator/ESO-LibAddonMenu
Don't mind the eclipse project files and build directory. If you are interested in how to use them, I can write about it in a separate thread.

[merlight]

Originally Posted by Garkin I'm not sure about XML - how do you want to update XML templates? I believe that you will just get an error that control has duplicate name.

Damn you're right :x

[ZOS_ChipHilseberg]

Originally Posted by Garkin I'm not sure about XML - how do you want to update XML templates? I believe that you will just get an error that control has duplicate name.

If you're talking about modifying the children of a template then you'll have to set override="true" on them to have the XML attributes apply to the existing child (created by the inherited template) instead of trying to make a new one. This is new for 1.6.

[merlight]

I've been playing with the settings window for quite some time, today I finally cleaned the code a bit, you can check it out here: https://github.com/merlight/ESO-LibAddonMenu/tree/edge (be warned though that I'm a rebase addict, so anything you commit on top of that might later go through painful merge conflicts)

First I have an important compatibility question

In LAM r16- addon panels are top-level windows with their own background. That means they could be displayed directly with SetHidden(false). Are there any addons exploiting that? Because if the answer is yes and their motives are legitimate, I'm kinda screwed - I was pretty deep into the whole revamp when I realized this, I already had addon panels in a container and had just hopped onto OpenToPanel to make it work with everything else I changed.

Now the less important stuff...

I separated the LAM window from ZO_OptionsWindow completely, it now shows in LAM's own fragment. That's done by "inlining" the previously used function ZO_OptionsWindow_AddUserPanel and providing custom callbacks. I renamed CreateAddonSettingsPanel to CreateAddonSettingsMenuEntry (because that's what the function does), and only call it when the fragment is requested for the first time.

I copied RightPanelBackground and enlarged the window & option area accordingly, but didn't change any option control dimensions yet, so it looks awkwardly empty. Accidentally, I discovered votan's new style branch a few minutes ago, somehow I always forget to git fetch --all. I'll check that out later. (Actually I already have a few questions regarding votan's fork, but they're not LAM-specific so I'll create another topic for them later )

Addon list is now ZO_ScrollList, and there's a search filter box below it. Thanks to ApplyTemplateToControl (i.e. only on PTS) the box displays a hint when the box is empty, although I'm not sure whether it has suitable translations (SI_ITEM_FILTER_BY_TEXT is used in inventory item filter).

Edit: oh and panelData for RegisterOptionsPanel may contain additional .keywords for search, currently the filter searches addon .name + .author + .version. For example SousChef could set .keywords = "crafting provisioning", that way whenever I search for "craft" I get all addons with "craft(ing)" among their keywords, not only in their name. I should document that in source

[Garkin]

Originally Posted by merlight I've been playing with the settings window for quite some time, today I finally cleaned the code a bit, you can check it out here: https://github.com/merlight/ESO-LibAddonMenu/tree/edge (be warned though that I'm a rebase addict, so anything you commit on top of that might later go through painful merge conflicts) First I have an important compatibility question In LAM r16- addon panels are top-level windows with their own background. That means they could be displayed directly with SetHidden(false). Are there any addons exploiting that? Because if the answer is yes and their motives are legitimate, I'm kinda screwed - I was pretty deep into the whole revamp when I realized this, I already had addon panels in a container and had just hopped onto OpenToPanel to make it work with everything else I changed. Now the less important stuff... I separated the LAM window from ZO_OptionsWindow completely, it now shows in LAM's own fragment. That's done by "inlining" the previously used function ZO_OptionsWindow_AddUserPanel and providing custom callbacks. I renamed CreateAddonSettingsPanel to CreateAddonSettingsMenuEntry (because that's what the function does), and only call it when the fragment is requested for the first time. I copied RightPanelBackground and enlarged the window & option area accordingly, but didn't change any option control dimensions yet, so it looks awkwardly empty. Accidentally, I discovered votan's new style branch a few minutes ago, somehow I always forget to git fetch --all. I'll check that out later. (Actually I already have a few questions regarding votan's fork, but they're not LAM-specific so I'll create another topic for them later ) Addon list is now ZO_ScrollList, and there's a search filter box below it. Thanks to ApplyTemplateToControl (i.e. only on PTS) the box displays a hint when the box is empty, although I'm not sure whether it has suitable translations (SI_ITEM_FILTER_BY_TEXT is used in inventory item filter). Edit: oh and panelData for RegisterOptionsPanel may contain additional .keywords for search, currently the filter searches addon .name + .author + .version. For example SousChef could set .keywords = "crafting provisioning", that way whenever I search for "craft" I get all addons with "craft(ing)" among their keywords, not only in their name. I should document that in source

I have just briefly checked code and it seems that you didn't read my comments to LAM.

- All "half width" widgets in LAM have height set to 55 units. If you want to make custom widgets with different height, widgets will be incorectly anchored. See LAM comments where is possible fix.

- comboboxCounter in dropdown widget should be panel specific, otherwise you can get an UI error because of duplicate names when creating widget controls manually. Again, better explanation is in my LAM comment.

- I don't like colorized addon names in the list. Any chance of using panelData.name instead of panelData.displayName or at least stripping color codes?

Warning: Spoiler

panelData.displayName:

panelData.name:

- panel.container should be probably anchored to panel.info (if exists), rather then to panel.label.

panel.lua:

- 107:	container:SetAnchor(TOPLEFT, label, BOTTOMLEFT, 0, 20+13)
+ 107:	container:SetAnchor(TOPLEFT, control.info or label, BOTTOMLEFT, 0, 20)

- addon panel is too wide. You should either change panel width or width of all widgets. Take a look to any submenu, it looks just ... not right.


A few changes are included in this version of Azurah. Azurah uses coustom made settings and even custom made widget, so it could be good compatibility test.

[votan]

Originally Posted by merlight In LAM r16- addon panels are top-level windows with their own background. That means they could be displayed directly with SetHidden(false). Are there any addons exploiting that?

I'm wondering myself, too. Because OpenToPanel handles that.
I think, we answer is "Basically, they could, but nobody does it (anymore)."

This version is also very nice. With better highlighting.

@Merlight: Can you test "SkyShards" with german displayname? Although the list is 10units wider than mine, there are ellipsis?!? 290 units would be good.

[votan]

Originally Posted by Garkin I have just briefly checked code and it seems that you didn't read my comments to LAM. - All "half width" widgets in LAM have height set to 55 units. If you want to make custom widgets with different height, widgets will be incorectly anchored. See LAM comments where is possible fix. - comboboxCounter in dropdown widget should be panel specific, otherwise you can get an UI error because of duplicate names when creating widget controls manually. Again, better explanation is in my LAM comment.

@Merlight: You can copy the function CreateOptionsControls and the whole Dropbox.lua from my branch in update6 https://github.com/votan73/ESO-LibAddonMenu

[Garkin]

Originally Posted by votan @Merlight: You can copy the function CreateOptionsControls and the whole Dropbox.lua from my branch in update6 https://github.com/votan73/ESO-LibAddonMenu

Or from the modified LAM included in Azurah (link in my previous post). I like my dropdown. ;-)

[Seerah]

One thing to point out, that I don't think anyone ever took advantage of... The widgets/controls in LAM did not need to be used with the regular addon settings panels. You could use them as templates for any sort of display you wanted.

At least, this was the intention when I redesigned LAM for 2.0. Not 100% sure if any changes with the core made that moot...

http://www.esoui.com/portal.php?&id=5&pageid=10
See: LAM2 for the Experienced Author and Exposed Methods on LAM2

[sirinsidiator]

@Garkin
Your half width height fix is already on its way in as well as some others mentioned in this thread. Once votan changed the thing I mentioned in my last comment on github I will merge his pull request and use it as base for further changes.

@merlight
Could you please keep the style changes and the search box for the addon list separated and also coordinate with votan in this ticket regarding the style changes. I will only be able to use one version in the end.

I would generally prefer if you could make tickets or use the few that I created for discussing the different changes and features that we are going to add instead of spreading everything into this thread, the comment section and pms

[merlight]

Originally Posted by Garkin I have just briefly checked code and it seems that you didn't read my comments to LAM. - All "half width" widgets in LAM have height set to 55 units. If you want to make custom widgets with different height, widgets will be incorectly anchored. See LAM comments where is possible fix.

Short answer to this and some other questions - I just ignored the option panels for this step. I knew there were some issues/fixes, but wanted to get the container window out for some feedback; the patch grew much larger than I anticipated.

Originally Posted by Garkin - comboboxCounter in dropdown widget should be panel specific, otherwise you can get an UI error because of duplicate names when creating widget controls manually. Again, better explanation is in my LAM comment.

What's in a name? It is nor hand... I mean, does that combobox need to have a name?

Originally Posted by Garkin - I don't like colorized addon names in the list. Any chance of using panelData.name instead of panelData.displayName or at least stripping color codes?

Sure. Forgot to revert that, I was flooding the list with dummy entries for testing and wanted to find actual addons quickly.

Originally Posted by votan Can you test "SkyShards" with german displayname? Although the list is 10units wider than mine, there are ellipsis?!? 290 units would be good. You can copy the function CreateOptionsControls and the whole Dropbox.lua from my branch in update6 https://github.com/votan73/ESO-LibAddonMenu

Originally Posted by Garkin Or from the modified LAM included in Azurah (link in my previous post). I like my dropdown. ;-)

Ok I will install Skyshards, Azurah, any other notable addons that put stress on the menu?

Regarding CreateOptionsControls: I need to ask a few off-topic questions first.

... and while looking for a commit I saw earlier, another question @votan:
Do you use some automatic commit message "gluer"? I find the list of affected filenames in messages pretty inconvenient (moreso when it's at the beginning, pushing the interesting part to ...), also sometimes there's just the filename and the actual message follows on the next line, which requires a click to unfold on github.
Locally I use tig, it lists affected filenames itself along with how many lines have changed, and also shows only the first line in overview. So commits that don't say what they are on the first line are a mystery at first.

[Garkin]

Originally Posted by merlight What's in a name? It is nor hand... I mean, does that combobox need to have a name?

This is ZO_ComboBox template used in dropdown widget:

<GuiXml>
    <Controls>
        <Control name="ZO_ComboBox" mouseEnabled="true" virtual="true">
            <Dimensions x="135" y="31" />
            <OnInitialized>
                ZO_ComboBox:New(self)
            </OnInitialized>
 
            <OnMouseUp>
                ZO_ComboBox_DropdownClicked(self)
                PlaySound(SOUNDS.COMBO_CLICK)
            </OnMouseUp>
 
            <Controls>
                <Control name="$(parent)BG" inherits="ZO_InsetBackground"/>
 
                <Label name="$(parent)SelectedItemText" font="ZoFontGame" color="INTERFACE_COLOR_TYPE_TEXT_COLORS:INTERFACE_TEXT_COLOR_SELECTED" wrapMode="ELLIPSIS" verticalAlignment="CENTER">
                    <Anchor point="TOPLEFT" offsetX="8" />
                    <Anchor point="BOTTOMRIGHT" offsetX="-20" />
                </Label>
 
                <Button name="$(parent)OpenDropdown" inherits="ZO_DropdownButton">
                    <Dimensions x="16" y="16" />
                    <Anchor point="RIGHT" offsetX="-3" />
 
                    <OnClicked>
                        ZO_ComboBox_DropdownClicked(self:GetParent())
                    </OnClicked>
                </Button>
            </Controls>
        </Control>
    </Controls>
</GuiXml>

As this template has named controls which use $(parent), they needs named parent. Otherwise all named children will have duplicate names.
Of course, you can create combobox without template, but it will be much more complicated.

[Garkin]

Originally Posted by Seerah One thing to point out, that I don't think anyone ever took advantage of... The widgets/controls in LAM did not need to be used with the regular addon settings panels. You could use them as templates for any sort of display you wanted. At least, this was the intention when I redesigned LAM for 2.0. Not 100% sure if any changes with the core made that moot... http://www.esoui.com/portal.php?&id=5&pageid=10 See: LAM2 for the Experienced Author and Exposed Methods on LAM2

Actually I have tried how LAMCreateControl works and I'm using it in FakeLibAddonMenu-1.0 (kind of LAM1 to LAM2 interface) and in the latest version of Azurah + Srendarr - I have created "subpanels" which are toggled by buttons on the top of the settings menu and all LAM controls are anchored to that panels.

You can see a little bit how it works on screenshots in spoiler in my previous post - there is active panel "Attributes" and pressing another button will show different panel with different set of controls. There is also visible custom widget "fontblock" which is pretty handy for font settings.

[votan]

Originally Posted by merlight ... and while looking for a commit I saw earlier, another question @votan: Do you use some automatic commit message "gluer"? I find the list of affected filenames in messages pretty inconvenient (moreso when it's at the beginning, pushing the interesting part to ...), also sometimes there's just the filename and the actual message follows on the next line, which requires a click to unfold on github. Locally I use tig, it lists affected filenames itself along with how many lines have changed, and also shows only the first line in overview. So commits that don't say what they are on the first line are a mystery at first.

I use a subversion client, not github, so I don't have problems with multiline. I will stop this.

[merlight]

Originally Posted by sirinsidiator @merlight Could you please keep the style changes and the search box for the addon list separated and also coordinate with votan in this ticket regarding the style changes. I will only be able to use one version in the end.

Sure, I will rebase before creating any pull requests anyway, so should be straightforward enough. Separating the search feature also makes sense.

Originally Posted by sirinsidiator I would generally prefer if you could make tickets or use the few that I created for discussing the different changes and features that we are going to add instead of spreading everything into this thread, the comment section and pms

Roger.