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 :) |
All times are GMT -6. The time now is 11:01 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2014 - 2022 MMOUI