Thread Tools Display Modes
06/16/14, 04:44 PM   #1
Garkin
 
Garkin's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 832
LAddMin - display LAM-1.0 menus using the LAM-2.0

I was trying to make a bridge between LibAddonMenu-1.0 and 2.0. Something like Sasky's LibAddonMenu 1.0 to 2.0 Interface, but not just for developers. It works, but only for addons which doesn't add custom controls to the menu. As I don't know how to make it work for all addons, this will probably never be an official addon.

If anyone is interested, file is attached.
Attached Files
File Type: zip LAddMin-0.1.zip (29.7 KB, 1248 views)
 
06/16/14, 09:05 PM   #2
Sasky
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 231
I actually had that same sort of sorting code running to initially test some of LAM2 features, then toned it down to that release.

I'd suggest running a whitelist (instead of blacklist) and/or running something with its own menu so users can opt-in to an upgraded menu (and test themselves).

As well, why aren't you defining the blacklist/whitelist with the addon name/id as the key? Then you won't need to loop over the table to check.

-------------------------

There are several different levels of LAM usage I noticed:
1) Only use LAM-1.0 APIs to create windows and don't touch return values (except as passing into LAM functions)
This works with no issues.

2) Use LAM and the return values to adjust further.
This is trickier, but you could potentially register these calls and replay them later once the menu is created. It might be possible to do this in bulk with metatable programming (not entirely sure how the index table works with a function).

3) Get panel directly using ESO functions or directly modify LAM internal variables (lastAdded or whatever).
Even harder...

---------------

The one thing I'm not sure how you'd address is if addons define the panel immediately and not in any sort of initialization callbacks. That leaves it to the whim of the addon ordering.
 
06/17/14, 03:31 AM   #3
Garkin
 
Garkin's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 832
Originally Posted by Sasky View Post
I actually had that same sort of sorting code running to initially test some of LAM2 features, then toned it down to that release.

I'd suggest running a whitelist (instead of blacklist) and/or running something with its own menu so users can opt-in to an upgraded menu (and test themselves).

As well, why aren't you defining the blacklist/whitelist with the addon name/id as the key? Then you won't need to loop over the table to check.
I'm not really sure how to link addon name and panelID. Is there a way to find out which addon has called library? If I just display controlPanelID, it could look like "_mainPanel" which is not too helpful.

Originally Posted by Sasky View Post
-------------------------

There are several different levels of LAM usage I noticed:
1) Only use LAM-1.0 APIs to create windows and don't touch return values (except as passing into LAM functions)
This works with no issues.

2) Use LAM and the return values to adjust further.
This is trickier, but you could potentially register these calls and replay them later once the menu is created. It might be possible to do this in bulk with metatable programming (not entirely sure how the index table works with a function).
This can help with control adjustments (size, color, enable/disable...). But the main issue for me is when someone adds custom control to the panel (Inventory Insight, Undiscovered) - a simple table doesn't work here. Creating a dummy window, so they can set parent or anchor to it could work. But it also means that number of created controls will doubled.

Originally Posted by Sasky View Post
3) Get panel directly using ESO functions or directly modify LAM internal variables (lastAdded or whatever).
Even harder...

---------------

The one thing I'm not sure how you'd address is if addons define the panel immediately and not in any sort of initialization callbacks. That leaves it to the whim of the addon ordering.
I have used "hack" that I created dummy LibAddonMenu-1.0 foder with manifest, because most of the addons has set optional dependency to this library. It allows me to load my addon first.

Anyway, right now I'm thinking about different approach.
I can leave addons to create their menus and then just reanchor all children from LAM-1.0 settings menu to the LAM-2.0 panels.

By the way Harven is trying to do somethig like this addon, but for use with his HAS:
http://www.esoui.com/downloads/info5....html#comments
 
06/17/14, 07:05 PM   #4
Sasky
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 231
Originally Posted by Garkin View Post
I'm not really sure how to link addon name and panelID. Is there a way to find out which addon has called library? If I just display controlPanelID, it could look like "_mainPanel" which is not too helpful.
I'd think the easiest would be to show by menu name, which is easy enough to capture.

Originally Posted by Garkin View Post
This can help with control adjustments (size, color, enable/disable...). But the main issue for me is when someone adds custom control to the panel (Inventory Insight, Undiscovered) - a simple table doesn't work here. Creating a dummy window, so they can set parent or anchor to it could work. But it also means that number of created controls will doubled.
You could possibly re-use the same dummy window. When a new addon panel is created (or final event) you can just keep note of the window's child objects and move those over on panel initialization. The positioning code could get rather tricky to map, especially if you mostly kept it as an adapter.

Originally Posted by Garkin View Post
By the way Harven is trying to do somethig like this addon, but for use with his HAS:
http://www.esoui.com/downloads/info5....html#comments
I'll have to take a look at it, though I have my reservations about a 2nd "unified" panel.

--------------

I did start work on a the delayed call and got it working pretty well in a Lua console test. Interesting bit of metatable usage.
Attached Files
File Type: lua promiseTest.lua (1.7 KB, 1151 views)
 
06/17/14, 10:05 PM   #5
SektaNZ
Join Date: Apr 2014
Posts: 10
Why not make it an official addon? The before and after difference is amazing, even if it doesn't work for all addons. For me it worked for 23 addons and missed 7. Most people don't even know this exists and would love it to clean up their addon list.

Edit: Actually a couple addons break. Maybe you can filter certain addons? ggFrames for example breaks entirely.

Last edited by SektaNZ : 06/17/14 at 10:09 PM.
 
06/18/14, 01:32 AM   #6
Sasky
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 231
We have been sort of exploring and messing around to see if we can convert more addons and not really prepping the current for release.

Maintenance of this could be crazy if not done right. It's trying to sort addons into using LAM2 if it can or LAM1 if it can't. In its current state, it will cause several errors. What's worse is for every addon's panel that fails you have at a minimum broken controls up to that addon not working.

----------------

@Garkin - I'm game to help work this up for release for at least the first case that we know works.
 
06/18/14, 01:21 PM   #7
Sephiroth018
 
Sephiroth018's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 20
I don't think one can really cover all those different cases of manually adding controls and I also don't think that's the right way. Too much complexity, too much ways to really mess up addons.
My oppinion is: Give the authors some time edit their menues and help them doing that if possible by converting their menues for them.

For that I also initially thought about making an addon to convert the settings, but after looking at some really special menues I decided I would never be able to handle all the different ways of doing special things with the controls (at least not with my only moderate lua skills).
The solution I came up with is a non-lua based code converter, which can currently cover all cases where only the LAM-1.0 API was used, ignoring everything else. With that I converted 4 addons of other developers, doing the special things manually after using my converter, which wasn't much work. If anyone wants to you can use it yourself: Converter
It's still under development, I have some ideas to make it better and more comfortable (converting headers to submenues for example).
 
06/19/14, 06:30 PM   #8
Sasky
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 231
The issue isn't so much authors having trouble converting as they just don't, for whatever reason. Look at how many addons still haven't updated to the Craglorn API, even though in 99% of cases it's changing one line in the .txt file.

Besides, the first case can be completely converted, no issues.

------

I've been working on the menu, will probably put it up later tonight in a Git repo.
 
06/20/14, 12:40 AM   #9
Sasky
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 231
Code up in Git repo: http://git.esoui.com/?a=summary&p=LAddMin

Having issues with the settings persisting. Probably something obvious, but I'll come back to it later.

Auto-detect of addons using the menu works well, though.
 
06/20/14, 05:25 AM   #10
Garkin
 
Garkin's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 832
Originally Posted by Sasky View Post
Code up in Git repo: http://git.esoui.com/?a=summary&p=LAddMin

Having issues with the settings persisting. Probably something obvious, but I'll come back to it later.

Auto-detect of addons using the menu works well, though.
If you are interested this is what I have tried:
https://www.firedrive.com/file/E349DBD57CC7DADF (or whole folder)
 
06/20/14, 06:09 PM   #11
Sasky
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 231
Took a quick look and looks good. Added to Git and I'll look at merging the two -- the menu generation is a bit more fleshed out in what I made (separates by whether we know it's good or bad).

Might be a small issue in replacing the promise object with the actual object, depending on how the addon uses it. Example:
Control create - promise at index x100
_G[Control] = x100
returned value = x100

On control create, replace with actual object (x200)
Set _G[Control] to x200
However, if the addon kept the return value, it's still x100 and not pointing to the actual object.
Should be able to fix by adjusting the metatable.
 
06/21/14, 08:26 AM   #12
Sasky
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 231
Pushed merge. Got a little tricky since I ended up splitting your change into separate commits to make it easier to manage merging. (Want to setup Git, Garkin? )

Master branch is sitting without the Promise objects - those are on a separate branch at the moment.

So one of the main issues I was having was with settings initialization. I saw you poking around a little bit at that for handling addons that create the menu pre-init.

Is it something like this?
  1. Check all manifests to determine load order
  2. Load addons in that order, executing pre-init code
  3. Load all saved variables (any order?)
  4. Run through addon init (any order?)

Or is the init tied to the saved variables load?
  1. Check all manifests to determine load order
  2. Load addons in that order, executing pre-init code
  3. For each addon (order?):
    1. Load saved vars
    2. Fire addon init event for that addon
 

ESOUI » AddOns » Alpha/Beta AddOns » LAddMin - display LAM-1.0 menus using the LAM-2.0

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