New UI for LibAddonMenu r17 (update 1.6)?
If it is time for a new revision for update 1.6, it is may also time for a refresh of the UI?
Does someone like it? It is just some change to the main file: Making borders invisible, changing base class of the buttons, a bit wider.... Shall I continue and send the source code changes to sirinsidiator or should I go away? :o |
I kinda like the idea to change the look a bit to mark the beginning of a new era.
Maybe change the background to the one seen in the skill menu behind the categories? I was also thinking about introducing toggleable addon categories and a search box to bring some order into the list when there are many addons installed. As this library is used in so many other addons, I appreciate all input and I will do my best to keep it up to date. |
Having categories that we could set for our addons like on ESOUI would be kind of neat, though it would be somewhat unnecessary if a user only has a few addons.
Kind of makes me wonder if our settings library would need a settings panel of its own XD |
That's what I meant with toggleable. I would put a checkbox or icon somewhere above the list so you can switch it on when you need it. :D
|
I like the idea of a customizable look of the settings library addon too.
Possible options could be: -Show categories -Show search field -Change font size & look in the addons list (if you got plenty of installed addons the list gets very long and reducing the font size by 2points would show more addons on one page e.g.) -Maybe templates to choose from (like plugins for libAddonMenu). This way Votan could build a look he likes and use it and others can download and use the same, or just stay with the original one. Imo this all is nice to have and I even like the current version like it is. As human beings are lazy I guess the seach box or categories would be cool features ;-) btw @Votan: I like your new layout very much! The borders always kind of disturbed me |
I actually like the borders, at least some kind of divider between the addon name list & the panel.
But if were making suggestions the one thing I would really like to see is the ability to register sub-panels. Something like when you click on an addon name the list updates & you get a list of sub panels for that addon under it, rather than being restricted to only using sub menus. Something like this: When setting something to full width, checkboxes for example, it would be nice if the ON/OFF aligned to the right of the panel to allow for longer descriptions, no since in wasting that space. If were marking the control for full width it should be full width, not 60% width, in my opinion. |
I personally do not like look of submenus in original layout, but other then that is fine. As for the new look I think that with divider between addon list and options it will look better.
But it should be possible to make menu skinable using the new ApplyTemplateToControl function and let user decide which template he wants to use. |
Quote:
The template idea is simply brilliant, I often used others' UI design as a basis then tweaked initially when I started out customizing UI in WoW, many years ago now. For me personally, the borders I like, though increasing transparency of them would be nice. Perhaps time for LAM to have customizable setting options of its own? |
Thanks to all, for the kind words. :)
A divider: Yes, I tried to get the look of the lore library already. (Not a border, but a divider) But it was a bit late I think :) Own settings: Yes. Allowing to change some perferences would be good. Another example: Allowing to colorize the buttons or not. The question is: like the chat window (with the gear) or as part of the left-side list (easier: all there) A bit more space for text: Yes. Aspecially german can be awful long. But that is true for all controls. Maybe word wrap? @Garkin: Templates. Wow. Sounds great, but also a bit beyond my current LUA skills. And a bigger change than pimping the look. :D Let's do it! Step by step and see how far we come. First changes: here |
Without the divider, for short addon panels it looks like the Author+Version string is about LAM not the addon. While a divider would help, it'd probably be even better to put it directly under the title.
Quote:
As far as skins, there's a couple different levels. One would be the overall layout and the other would be the individual controls. |
Quote:
As for the Fixed width...Just change it and make it a different "fixed" width :p 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. |
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. Quote:
|
Many good ideas! Keep 'em coming :)
I like the idea of using templates to change the style. How about allowing two levels of customization?
For the settings I will have to use one of the methods proposed here.
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? |
|
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 :D) 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". |
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. Quote:
|
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:
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 :p 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" |
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:
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. Quote:
|
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:
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:
|
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. |
two variants-ideas of list ofthe addons
1. scrollable list 2. pages, like 20 addons per page |
If you are changing widgets, do not forget increase version number, otherwise it will not update older versions.
Lua Code:
|
Jep. link updated.
Quote:
|
Quote:
Quote:
I'm in complete agreement with you, that is why I suggested the change. Somehow it needs to be more flexible. |
Quote:
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. Quote:
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. |
Quote:
|
Quote:
|
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 |
Quote:
|
Quote:
Quote:
I like the idea of allowing to change settings away from default, if a "settings"-addon is installed, only. Maybe allowing "styles" via activating different addons? Changing the width (dynamic or not) of the right-side requires to change all controls, because the layout is hard-coded in every control without a master-width. At this point, I wanted to wonder, if everybody is happy with this "thousand" files to include approach. But, if it is one addon only, this question is obsolete. This would also reduce the size of the other addons and the "thousand" version checks at startup. |
Quote:
It's been a while since I messed with it, but I seem to recall an issue with addons only including the lua files for the controls they use. Only the controls included with the addon that loaded first (or the addon with the most recent version of LAM included) were loaded. If this truly is an issue, maybe a fix can be found to reduce each addon's footprint. Really, I think the first question that needs to be answered is whether LAM is going to have its own settings panel and would therefor need to be an independent addon that is included as a dependency in the addons that utilize it. Because, as you said, this answer would help to determine the answer to other questions. |
Just to clearify, what I am thinking about style addons:
Lua Code:
or Lua Code:
I would restrict additional control manipulation to what is possible with the setup data. This way an addon author can not work against the choosen style. ANY settings addon author "just" needs to supply a compatible API and register to the well known name "LibAddonMenu-2.0". I just have to finalize my thoughts. But now, I have to work first :) |
I was thinking about the following when I was mentioning two levels of customization:
The downloadable packages are things that change the style of the LibAddonMenu window without changing the layout. For example removing the border, replacing the background, changing the used font and such things. Maybe even change the size of buttons, but only inside certain restraints from the basic layout which is not supposed to change. And the addon dev side customizations will allow to change the style and layout inside a panel in any way they want, but nothing outside of that. e.g. align all buttons however they want, add an image to the background (only inside the panel) They should not be able to influence the settings dialogs of other addon authors or the addon list in any way I haven't looked into the technical details and limitations yet. Categories are certainly hard to define in this case. I think if we where to use types, one addon would only be allowed to specify a single one from a predefined list. Separating them by first letter or pages also sounds good. Maybe add all of these and allow the user to switch between them? Settings would be things like which theme is in use, what is the current view mode of the addon list and other things that will probably come up over time. I am also thinking about putting LibAddonMenu on github, so everybody can send me pull requests. This would make it a lot easier to integrate all the different ideas that you already seem to have started to implement. What are your thoughts? Also one last note, I don't thing it is a good idea to change too many things at once when there are so many addons depending on LibAddonMenu. We should take small steps and only put up one change at a time to see how it works with other addons. For the launch of 1.6 we should only make the necessary changes to make it work and from there only add one new feature every one or two weeks. |
Ahh. Well, it's already possible to use custom controls. Why not use a similar system for library options?
First, we'd need to identify what LAM's settable options would be. Then, do something in LibAddonMenu-2.0.lua like: Lua Code:
The values in the options table could then be used instead of hard-coded values. I imagine some kind of refresh or reinitialization would need to be performed too. Then you could distribute options addons dependent on LAM-2.0 rather than redistributing the whole library in different forms (and then having to maintain all of them when things need fixing). LAM-2.0_classic.lua Lua Code:
It's late and I kinda feel like I'm rambling :) I'll come back after some sleep. edit: this was in response to votan. sirisidiator snuck in while I was typing haha. |
Quote:
|
Quote:
Quote:
Just the changes we did, that is enough change already. As every addon author has to switch to r17 this time, the policy of using shared addon or embedded files must be established now. If not everybody must update everytime, more revisions can be released. edit 1: And the callback thing Ayantir needs for the guild addon. |
I like the template ideas to change the whole look of this library.
But allowing each addon author to individually change their addon's menu (inside the templates of the library) may result in blinking, attraction hunting menus (imo). So I don't like this idea about background images, etc. Like others have mentioned I'd prever a look that integrates into the game's menu style and won#t change that much in total. |
@ Votan, pic 2 of your post #21 looks great, apart from the lack of vertical alignment for the title with the right side of the drop-down menus, etc.
|
hehe, yes. :) But this heavily depends on the types of used controls. If it were checkboxes or colorpicker only, this would be true anyway. We better keep version 1.
Quote:
|
Quote:
Also, I'm all for github too :) |
I got some feedback from Seerah and also the OK to change the license in order to put LibAddonMenu on github.
Quote:
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. |
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. :mad:
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. |
Quote:
|
@Seerah/sirinsidiator:
Hopefully, we didn't misunderstood each other. :o 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. |
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. |
@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. |
Quote:
|
Quote:
|
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 ;) |
Quote:
- 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
- panel.container should be probably anchored to panel.info (if exists), rather then to panel.label. Code:
panel.lua: 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. |
Quote:
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. |
Quote:
|
Quote:
|
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 |
@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 ;) |
Quote:
Quote:
Quote:
Quote:
Quote:
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. |
Quote:
XML Code:
Of course, you can create combobox without template, but it will be much more complicated. |
Quote:
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. |
Quote:
|
Quote:
Quote:
|
All times are GMT -6. The time now is 07:13 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2014 - 2022 MMOUI