Thread Tools Display Modes
02/05/15, 03:37 PM   #21
QuadroTony
Banned
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 828
two variants-ideas of list ofthe addons

1. scrollable list
2. pages, like 20 addons per page
  Reply With Quote
02/05/15, 03:37 PM   #22
Garkin
 
Garkin's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 832
If you are changing widgets, do not forget increase version number, otherwise it will not update older versions.

Lua Code:
  1. local widgetVersion = 7 --should be 8
  Reply With Quote
02/05/15, 03:45 PM   #23
votan
 
votan's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2014
Posts: 577
Jep. link updated.

Originally Posted by Garkin View Post
If you are changing widgets, do not forget increase version number, otherwise it will not update older versions.

Lua Code:
  1. local widgetVersion = 7 --should be 8
  Reply With Quote
02/05/15, 04:41 PM   #24
circonian
AddOn Author - Click to view addons
Join Date: May 2014
Posts: 613
Originally Posted by votan View Post
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 View Post
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.
  Reply With Quote
02/05/15, 05:04 PM   #25
circonian
AddOn Author - Click to view addons
Join Date: May 2014
Posts: 613
Originally Posted by sirinsidiator View Post
How about allowing two levels of customization?
  1. Allow the user to download additional style packages that change the default look of libAddonMenu
  2. 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 View Post
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.
  Reply With Quote
02/05/15, 05:13 PM   #26
circonian
AddOn Author - Click to view addons
Join Date: May 2014
Posts: 613
Originally Posted by Ayantir View Post
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.
  Reply With Quote
02/05/15, 05:15 PM   #27
circonian
AddOn Author - Click to view addons
Join Date: May 2014
Posts: 613
Originally Posted by QuadroTony View Post
two variants-ideas of list ofthe addons

1. scrollable list
2. pages, like 20 addons per page
I like the idea of pages a lot better than categories, except maybe "recent" category.
  Reply With Quote
02/05/15, 05:21 PM   #28
Garkin
 
Garkin's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 832
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
  Reply With Quote
02/05/15, 06:59 PM   #29
Randactyl
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 251
Originally Posted by Garkin View Post
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.
  Reply With Quote
02/06/15, 12:23 AM   #30
votan
 
votan's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2014
Posts: 577
Originally Posted by Randactyl View Post
I like having the version and author right beneath the title.
Within page or right-aligned?

Originally Posted by Randactyl View Post
However, "Reset to Defaults" can look a bit orphaned especially on very short menus.
This could be a "feature", too. This way, the button is not clicked by accident

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.
  Reply With Quote
02/06/15, 01:31 AM   #31
Randactyl
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 251
Originally Posted by votan View Post
Within page or right-aligned?
Within the page. Right aligned is too disjointed for my taste.

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.
  Reply With Quote
02/06/15, 02:11 AM   #32
votan
 
votan's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2014
Posts: 577
Just to clearify, what I am thinking about style addons:

Lua Code:
  1. --own version check
  2. local MAJOR, MINOR = "LibAddonMenu-2.0-classic", 1
  3. local lam, oldminor = LibStub:NewLibrary(MAJOR, MINOR)
  4. if not lam then return end  --the same or newer version of this lib is already loaded into memory
  5.  
  6. -- well known name registration
  7. MAJOR, MINOR = "LibAddonMenu-2.0", 17
  8. lam, oldminor = LibStub:NewLibrary(MAJOR, MINOR)
  9. if not lam then return end  --a settings addon is registered already

or

Lua Code:
  1. --own version check
  2. local MAJOR, MINOR = "LibAddonMenu-2.0-borderless", 1
  3. local lam, oldminor = LibStub:NewLibrary(MAJOR, MINOR)
  4. if not lam then return end  --the same or newer version of this lib is already loaded into memory
  5.  
  6. -- well known name registration
  7. MAJOR, MINOR = "LibAddonMenu-2.0", 17
  8. lam, oldminor = LibStub:NewLibrary(MAJOR, MINOR)
  9. if not lam then return end  --a settings addon is registered already

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
  Reply With Quote
02/06/15, 03:28 AM   #33
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 1,566
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.
  Reply With Quote
02/06/15, 03:42 AM   #34
Randactyl
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 251
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:
  1. lam.options = lam.options or {
  2.     isBorderVisible = false,
  3.     useStylizedLeftPanelBackground = true,
  4.     option3 = val,
  5.     option4 = otherVal,
  6. }
  7.  
  8. function lam:RegisterOption(key, value)
  9.     if lam.options[key] then lam.options[key] = value end
  10. end

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:
  1. local LAM = LibStub("LibAddonMenu-2.0")
  2.  
  3. LAM:RegisterOption("isBorderVisible", true)
  4. LAM:RegisterOption("useStylizedLeftPanelBackground", false)

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.

Last edited by Randactyl : 02/06/15 at 03:48 AM.
  Reply With Quote
02/06/15, 04:18 AM   #35
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 1,566
Originally Posted by Randactyl View Post
sirisidiator snuck in while I was typing haha.
I am a sneaky NB, so that's what I do :P
  Reply With Quote
02/06/15, 04:34 AM   #36
votan
 
votan's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2014
Posts: 577
Originally Posted by sirinsidiator View Post
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?
Yes, this way corrections, like Ayantir, Garkin and Merlight did, could easier be merged than posting dropbox links

Originally Posted by sirinsidiator View Post
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.
Yes, I agree, I mentioned this already, maybe not clear enough
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.

Last edited by votan : 02/06/15 at 04:40 AM.
  Reply With Quote
02/06/15, 09:13 AM   #37
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,912
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.
  Reply With Quote
02/06/15, 10:06 AM   #38
BornDownUnder
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 59
@ 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.
  Reply With Quote
02/06/15, 10:37 AM   #39
votan
 
votan's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2014
Posts: 577
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.

Originally Posted by BornDownUnder View Post
@ 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.
  Reply With Quote
02/06/15, 11:57 AM   #40
Randactyl
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 251
Originally Posted by Baertram View Post
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.
I agree. The more I try to think as a "typical user" the less I am interested in different visual options. A static style that fits in with the game is the more attractive option imo.

Also, I'm all for github too
  Reply With Quote

ESOUI » Developer Discussions » General Authoring Discussion » New UI for LibAddonMenu r17 (update 1.6)?

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off