Thread Tools Display Modes
05/11/19, 07:22 AM   #21
Sordrak
 
Sordrak's Avatar
AddOn Author - Click to view addons
Join Date: May 2017
Posts: 52
So is this now going to be a thing or not?

I'm currently trying to shift to the new style, but i don't think the support for this is that huge currently.

Or maybe I do not see how to use some of the libraries in this new way.

Anyone got some feedback regarding:
LibCustomMenu
LibGPS
LibMapPing
LibMapPins-1.0
LibPotionBuff

Any feedback would be appreciated.
  Reply With Quote
05/11/19, 09:11 AM   #22
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,912
LibPotionBuff will be changed, already got a beta version for tests here if you want to try it out:
LibPotionBuff without LibStub

And the others will follow, I'm pretty sure. So I will definately remove LibStub from my libraries. It takes some time but e.g. LibFilters needed a new version for this (3.0) and 2.0 should be replaced with 3.0 soon!
I guess you should start to modify your addons to support both ways.
Either the global variable or LibStub like this:

Lua Code:
  1. local lpb = LibPotionBuff
  2. if lpb == nil and LibStub then lpb = LibStub("LibPotionBuff") end

In your addon#s manifest ttx be sure to add LibPotionBuff to the ##DependsOn: entry:

Code:
##DependsOn: LibPotionBuff
And remove LiBStub from the DependsOn and OptionalDependsOn as this should be handled in the library's own txt file (if installed as stadnalone and NOT included in your addon zip file) on it's own via LibPotionBuff.txt -> ##DependsOn: LibStub or even not anymore for the new version.

If you have the libraries included into your addon's zip archive you should start to remove them, or be sure to support them properly so either users containing older versions of your addon WITH LibStub libraries are able to use it AND new versions without it as well (as shown above in the example).
  Reply With Quote
05/11/19, 10:44 AM   #23
Sordrak
 
Sordrak's Avatar
AddOn Author - Click to view addons
Join Date: May 2017
Posts: 52
I guess i just ran into this here... LibAddonMenu present in an old version and me only supporting the new one.

No idea of how i should feel supporting both versions at the moment o_O

Thanks for the info btw.
  Reply With Quote
05/11/19, 12:00 PM   #24
Kyoma
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 125
Originally Posted by Sordrak View Post
I guess i just ran into this here... LibAddonMenu present in an old version and me only supporting the new one.

No idea of how i should feel supporting both versions at the moment o_O

Thanks for the info btw.
It should be fine if they have LAMr29 installed as a standalone
  Reply With Quote
05/11/19, 01:32 PM   #25
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,912
Originally Posted by Sordrak View Post
I guess i just ran into this here... LibAddonMenu present in an old version and me only supporting the new one.

No idea of how i should feel supporting both versions at the moment o_O

Thanks for the info btw.
I did it like described above.
First check if the global variable LibAddonMenu2 exists and use it for your local instance of LAM, and if not check if LibStub is loaded and load the lib via this way.
After this check if your local instance of LAM is there and if not abort your addon with an error message (e.g. use assert() function to do so).
  Reply With Quote
05/11/19, 02:39 PM   #26
Sordrak
 
Sordrak's Avatar
AddOn Author - Click to view addons
Join Date: May 2017
Posts: 52
Originally Posted by Baertram View Post
I did it like described above.
First check if the global variable LibAddonMenu2 exists and use it for your local instance of LAM, and if not check if LibStub is loaded and load the lib via this way.
After this check if your local instance of LAM is there and if not abort your addon with an error message (e.g. use assert() function to do so).
Yes and no.

I agree with the approach of moving the libraries directly to the AddOn folder and getting rid of lib directories within AddOns.

Furthermore, i agree with the approach of removing the LibStub part. That's actually why I began to change my AddOns.

Yet I didn't expect this behavior at the beginning and I don't think the benefit is really huge in the way things are currently.

What I expected was that the AddOn doesn't get loaded at all without the dependencies. The behavior should be managed directly by ZOS / ESO trough DependsOn. Yet, I find myself having to add additional code (instead of getting rid of it) to verify if there isn't a library loaded the old way.

Which actually means for me that the benefit isn't huge. If I want the AddOn to run everywhere fine, I would still have to add the library to my AddOn as otherwise it wouldn't run and I would have to handle that case. I don't see an assert / printing a message as very useful or the way I'd like it to be.

Not sure how I'll adjust my AddOn now... guess I'll see.
  Reply With Quote
05/11/19, 02:58 PM   #27
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,912
If you don't want the library to be loaded without dependency then maybe include/or not the library within your addon's folder BUT don't load it from your addon's txt file but let it have it's own librray's txt file and use the DependsOn in your addon's txt file.
This way you provide the lib and your addon should work as expected and NOT load if the lib is missing/get's removed.

Adding additional code is curently only needed for the phase where libraries might exist as version with and w/o LibStub.
My approach would be to remove LibStub completely and let addons crash so they need an update but this will break older unmaintained addons as well and thus is not the wanted behaviour (I wouldn't mind as it's easy to ask and fix them as well but some ppl here just want everything to be running smooth and fine. Remembering the wide user reactions on the library changes in the past I can understand them... Not all of the users seem to wish to get a fix but love to simply complain and rage )
  Reply With Quote
05/11/19, 03:04 PM   #28
Kyoma
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 125
You don't actually need the assert/debug line to see if the library isn't loaded because you are already using ##DependsOn and users need to install it seperately anyway. Even if the LAM instance that is loaded comes from an (older) addon that had it embedded (with its manifest) it still loads with LibStub through that.

I agree you'd still need this (taking LibPotionBuff as an example):
Code:
    local lpb = LibPotionBuff
    if lpb == nil and LibStub then lpb = LibStub("LibPotionBuff") end
Instead of this tho
Code:
    local lpb =  LibStub("LibPotionBuff")
But that is mainly because the user might have a LAM version installed that still used LibStub because this is kind of a transition period.
  Reply With Quote
05/11/19, 03:47 PM   #29
Rhyono
AddOn Author - Click to view addons
Join Date: Sep 2016
Posts: 659
If you're relying on a library that hasn't switched yet: you're stuck for now, but this is just the first step in getting away from it.

In regards to LAM, if someone hasn't updated to the version of LAM that allows direct access to LAM (r28+) and they use my addons that requires that: I'm just letting it break. I'm not bothering to support old versions of LAM when there's a new version.
  Reply With Quote
07/29/19, 08:40 AM   #30
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,912
Updated the Wiki with some library information:
https://wiki.esoui.com/Libraries
  Reply With Quote
07/29/19, 10:36 AM   #31
Drakanwulf
 
Drakanwulf's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2017
Posts: 50
Nicely done, Baertram. Thanks for updating the wiki.

And thanks for the information about why a "/libs/..." directory has to exist. I did not know that the game automatically overwrites existing add-on programs in the /AddOns/... folder when embedded or included add-on programs are included at the same level as their host add-on (the one that's being loaded) program.
  Reply With Quote
07/29/19, 11:15 AM   #32
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,912
Basically it's the zip extraction software which will do this or Minion (if used).
If you build a zip archive containing 2 folders, 1 for your addon and 1 for a library (or like another addon did in the past "Libraries for addon xyz": All needed libraries as own folders in a zip archive) the software will extract the zip and extract all folders to the "AddOns" directory directly then.

Minion will overwrite other exisitng folders afaik (maybe only those which got the name of the installed Addon, but I'm not sure about this).
If you manually extract the zip archive and the popup says "Overwrite existing ..." and you press Yes (what you will do if the addon existed already ) it will overwrite the existing library folders as well.

Edit:
It does not need to be a /libs/ directory. You could also ship the library within your addons directory directly, without a subfolder.
/Addons/YourAddon/LibAddonMenu-2.0/LibAddonMenu-2.0.txt
Maybe it's easier to "find" and "read" though if it's a /lib/ subfolder.

Just don't add the library directly to the zip's folder depth 0 (which will be the AddOns directory after extraction).

Last edited by Baertram : 07/29/19 at 11:17 AM.
  Reply With Quote
07/29/19, 02:37 PM   #33
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 1,566
Yeah. Minion 3 will simply overwrite the folder without any warning. The worst part, it won't even recognize that it just replaced your new and shiny LAMr29 with an old LAMr23 and will continue to show it as up to date. Not entirely sure yet how to properly solve this in Minion 4. One idea I have discussed with Dolby is to reject uploads that contain folders named after the manifest of another addon on the root level of the archive, but that won't help with the addons that already exist and do this.
  Reply With Quote
07/29/19, 02:42 PM   #34
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,912
The worst part, it won't even recognize that it just replaced your new and shiny LAMr29 with an old LAMr23 and will continue to show it as up to date.
Not sure how Minion works there but I guess it stores the updated version from the server into the Minion.xml and that's it (today).


Couldn't Minion 3/4 scan the addons directory after finishing an update/an update batch for multiple addons and read the manifest txt files to check if the versions in there are the same as the Minion server's version of the addon/library? Something like a check after update again.
Outdated addons or libs should then be shown the "Update" button again.
  Reply With Quote
07/30/19, 11:24 AM   #35
Drakanwulf
 
Drakanwulf's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2017
Posts: 50
Or Minion could scan and retain the folder names in the ##DependsOn: directives family and use the ESOUI catalog versions for any embedded folders whose names already exist in the ESOUI catalog.

The ESOUI catalog maintenance program(s) could also scan and retain folder names from any subordinate directories they find as well. This option would close the door on developers who don't like or don't use Minion and write their manifest.txt files that way too.

I think adding these options might give users who insist on embedding libraries in their add-ons the debatable benefit of automatic updates to the latest and greatest versions of the embedded libraries in their add-ons.

I think I may have read something about doing something like this in another set of posts on Gitter or here.
  Reply With Quote
08/08/19, 03:16 AM   #36
Hydra9268
 
Hydra9268's Avatar
AddOn Author - Click to view addons
Join Date: May 2018
Posts: 33
Originally Posted by Scootworks View Post
BURN IT ALL DOWN! :-)
bUt dO YoU hAvE fIRe?!
  Reply With Quote
08/15/20, 04:25 AM   #37
Marazota
AddOn Author - Click to view addons
Join Date: Sep 2015
Posts: 257
Originally Posted by sirinsidiator View Post
I believe this can be done in 3 "easy" steps:

1) Update libraries to provide an alternative way of being accessed.
This step shouldn't introduce any major compatibility issues as we still keep everything as is and addons that have not been updated can use LibStub as a method to access the library as before. It's just to pave the way to phase out library access via LibStub in addons
All that should be necessary is to extend the code like this:
Lua Code:
  1. local MAJOR, MINOR = "LibSomething", 3
  2. local lib = LibStub:NewLibrary(MAJOR, MINOR)
  3. if not lib then
  4.     return
  5.     -- already loaded and no upgrade necessary
  6. end
  7.  
  8. LibSomething = lib -- new way to access it without LibStub


In the manifest we also add the "AddOnVersion" and "IsLibrary" directive:
Code:
## AddOnVersion: 3
## IsLibrary: true
That's not strictly necessary until after LibStub has been removed from the lib, but it will ensure that only the newest standalone version is loaded (embedded versions will behave as before) and also move it to the new library section in the addon menu once Elsweyr is released.

2) Find all addons that use a library and change them (or request it) to access dependent libraries via the newly introduced global variable instead of LibStub, remove its files from the addon manifest (so it is no longer embedded) and change from OptionalDependsOn to DependsOn.
Lua Code:
  1. local LS = LibStub("LibSomething")
should become
Lua Code:
  1. lobal LS = LibSomething


3) Update libraries to no longer use LibStub. This will likely cause compatibility issues with any addons that have not been updated in step 2, but at some point we just need to pull the trigger, otherwise LibStub won't ever disappear completely.

Lua Code:
  1. local lib = {}
  2. LibSomething = lib

Let me know what you think. Did I miss anything? Who's on board?
I will start with step 1 in LAMr28 and will introduce the new global variable "LibAddonMenu".
i did step 2 but still got errors
what to change?

need to change something here? commenting libstub line didnt help

Code:
-- INITIALIZATION
-----------------------------------------------------------------------------------------------------------------------------------
function IA_InventoryAssistant:New ( control )
  local inventoryAssistant = ZO_Object.New ( self )
  inventoryAssistant:Initialize ( control )
  return inventoryAssistant
end
-----------------------------------------------------------------------------------------------------------------------------------
function IA_InventoryAssistant:Initialize ( control )
  EH:RegisterForEvent ( self.name, EVENT_ADD_ON_LOADED, function ( event, addonName )
      if addonName ~= self.name then return end
      EH:UnregisterForEvent ( self.name, EVENT_ADD_ON_LOADED )

      self.settings = ZO_SavedVars:NewAccountWide ( "InventoryAssistantSettings", 1, nil, self.defaults )
      --self.async = LibStub( "LibAsync" ):Create ( self.name ) 
      
      self.onlyDuplicates = self.settings.onlyDuplicates
      self.onlyMarkedItems = self.settings.onlyMarkedItems
      self.onlyLoots = self.settings.onlyLoots
      self.groupLoots = self.settings.groupLoots
      self.showCrafted = self.settings.showCrafted
lines i changed now looks like this

Code:
-- LOCAL FUNCTIONS
-----------------------------------------------------------------------------------------------------------------------------------
local EH = LibEventHandler
local menu = LibCustomMenu
local LAM = LibAddonMenu
errors in game

Code:
user:/AddOns/InventoryAssistant/InventoryAssistant.lua:471: attempt to index a nil value
stack traceback:
user:/AddOns/InventoryAssistant/InventoryAssistant.lua:471: in function 'IA_InventoryAssistant:Initialize'
|caaaaaa<Locals> self = [table:1]{}, control = ud </Locals>|r
user:/AddOns/InventoryAssistant/InventoryAssistant.lua:466: in function 'IA_InventoryAssistant:New'
|caaaaaa<Locals> self = [table:2]{version = "1.15.180704-beta", name = "InventoryAssistant"}, control = ud, inventoryAssistant = [table:1] </Locals>|r
user:/AddOns/InventoryAssistant/InventoryAssistant.lua:1499: in function 'IA_InventoryAssistant_OnInitialize'
|caaaaaa<Locals> control = ud </Locals>|r
IA_Main_Initialized:3: in function '(main chunk)'
|caaaaaa<Locals> self = ud </Locals>|r
  Reply With Quote
08/15/20, 11:18 AM   #38
Kyoma
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 125
A quick fix (most likely), change it to this:
Code:
self.async = LibAsync:Create ( self.name )
  Reply With Quote
08/15/20, 01:37 PM   #39
Marazota
AddOn Author - Click to view addons
Join Date: Sep 2015
Posts: 257
Originally Posted by Kyoma View Post
A quick fix (most likely), change it to this:
Code:
self.async = LibAsync:Create ( self.name )
thanks, tried that, same error

Code:
user:/AddOns/InventoryAssistant/InventoryAssistant.lua:471: attempt to index a nil value
stack traceback:
user:/AddOns/InventoryAssistant/InventoryAssistant.lua:471: in function 'IA_InventoryAssistant:Initialize'
|caaaaaa<Locals> self = [table:1]{}, control = ud </Locals>|r
user:/AddOns/InventoryAssistant/InventoryAssistant.lua:466: in function 'IA_InventoryAssistant:New'
|caaaaaa<Locals> self = [table:2]{version = "1.15.180704-beta", name = "InventoryAssistant"}, control = ud, inventoryAssistant = [table:1] </Locals>|r
user:/AddOns/InventoryAssistant/InventoryAssistant.lua:1499: in function 'IA_InventoryAssistant_OnInitialize'
|caaaaaa<Locals> control = ud </Locals>|r
IA_Main_Initialized:3: in function '(main chunk)'
|caaaaaa<Locals> self = ud </Locals>|r







may be its because this library, using withing addon, not ready to work without libStub ?

https://www.esoui.com/downloads/info...ntHandler.html
  Reply With Quote
08/15/20, 02:38 PM   #40
Rhyono
AddOn Author - Click to view addons
Join Date: Sep 2016
Posts: 659
You'll have to remove the LibStub dependency from there too.
  Reply With Quote

ESOUI » Developer Discussions » General Authoring Discussion » Let's get rid of LibStub!

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