This library is obsolete and will be disabled at 2021-12!
Please change your addons to remove this library, see the description and comments of LibLoadedAddons.
-> Added obsolete message to chat upon dependency to this library
-> Addon users: Check your addon's txt files for entries like ## DependsOn: or ## OptionalDependsOn: LibLoadedAddons and tell the devs of these addons to read the description text of LibLoadedAddons, and change their addons prior to 2021-12
This library will be removed soon. Please change your addons to not use it any longer!
Please use global variables and the txt files of addons/libs' ## AddOnVersion: <unsignedInteger> to detect other addons/libs, and add dependencies properly via your own addons/libs txt file's tag ## (OptionalDependsOn): <otherAddonName> >= <OtherAddOnsAddOnVersion>
[Version 999 - OBSEOLETE]
This library is obsolete now. Do not use it anymore and remove it from your addons.
Please use global variables and the txt files of addons/libs' ## AddOnVersion: <unsignedInteger> to detect other addons/libs, and add dependencies properly via your own addons/libs txt file's tag ## (OptionalDependsOn): <otherAddonName> >= <OtherAddOnsAddOnVersion>
[Version 2.0]
This library is obsolete and will be disabled at 2021-12!
Please change your addons to remove this library, see the description and comments of LibLoadedAddons.
-> Added obsolete message to chat upon dependency to this library
-> Addon users: Check your addon's txt files for entries like ## DependsOn: or ## OptionalDependsOn: LibLoadedAddons and tell the devs of these addons to read the description text of LibLoadedAddons, and change their addons prior to 2021-12: https://www.esoui.com/downloads/editfile.php?id=1266
[Version 1.4]
Fixed: Function to register a version was not writing the version properly in some cases.
[Version 1.3]
-Updated API fopr Elsweyr
-Added ##IsLibrary: true tag to manifest txt
-Added ##AddOnVersion tag to manifest txt
-Removed usage and dependency to LibStub
[Version 1.2]
Changed loading of the library: Older verisons of this library will register addons loaded already before LibStub "overwrites" the older version of this library with the more up2date one.
Already loaded addons will be kept in the variable "loadedAddons" now, and will not be cleared again.
[Version 1.1]
Updated: API
Added: Manifest TXT file, dependency to LibStub, included obligatory library LibStub
You might remove the library LibStub from this library and just install LibStub as standalone version (like a normal addon via the Minion addon manager e.g.) too!
Nope, it is intended to nerve and show again each time so you tell the devs. Else it will be ignored (had this in the past too often already).
Once the addon in question is changed it will be gone and this could be tomorrow if the devs react
If not, the devs got no time, do not play anymore and maybe the addon in question could be exchanged with another as well then.
As I know there are only a few addons using this lib this should be fine, as you said. Most were changed already. Others I don't know yet will be made visible "by repeated messages" until the users decide it's annoyingly enough to get changed
Originally Posted by Onigar
-> Added obsolete message to chat upon dependency to this library
This is fine and worthwhile to indicate a player has one or more addons which depend on this lib.
Just, this message is repeated at every zone change or similar like thieves den, house, dungeon....
Maybe, for the next 6 weeks, one message per login could be enough
Edit: After searching, for me it is just 1 Addon, MailBuddy
we can just use the ingame vanilla AddonManager to make sure the version needed for the other addon is given.
Please tell the other addon's dev to add the ## AddOnVersion: tag to their addons so you can use them.
In Addition the other addon's could also provide a global lua variabe which one would be able to reference after EVENT_ADD_ON_LOADED to checkif it exists, if a .version is given or if any .functionName ~= nil you wish to use in your addon.
If you cannot wait for the devs to respond/do something:
Remove the ## DependsOn: LibLoadedAddons or ## OptioanlDependsOn: LibLoadedAddons line from the addon's txt file.
Make sure other named libraries and addons "in the same line after the :" ARE KEPT/NOT REMOVED!
In the addon's code you will find lines like
Code:
local LIBLA = LibLoadedAddons
if not LIBLA then d("The library LibLoadedAddons is missing! This addon won't work without it and aborts now!") end
Search the addon files for this LIBLA or LibLoadedAddons lines and simply comment them by addin -- up in front of each line, or deleting the lines.
The problem I have with authors using other people's libraries is this. When the library goes out of date they have to rely on the original author to update them. I have 4 lib addons that are in my addons menu that are currently out of date but as they don't appear in my addons folder by themselves I must assume they're loaded under one of my addons and have to hunt them down and manually update them myself. End users should not have to do this to keep their addons up to date.
LibAsync
LibLoadedAddons are two of them.
First of all, this is not due to the addon or library authors. Libraries previously did not, and generally will not show up on the addons list, outside of a few libraries which have settings or are commonly installed as stand alone addons. (e.g. LAM or LibGroupSocket) The only reason those libraries are now showing up is because of a change in how add-ons are detected.
Second, regardless of if a library is kept updated or not, there's many addons which would not exist because of one library or another.
The problem I have with authors using other people's libraries is this. When the library goes out of date they have to rely on the original author to update them. I have 4 lib addons that are in my addons menu that are currently out of date but as they don't appear in my addons folder by themselves I must assume they're loaded under one of my addons and have to hunt them down and manually update them myself. End users should not have to do this to keep their addons up to date.
LibAsync
LibLoadedAddons are two of them.
Last edited by SteveCampsOut : 02/07/18 at 03:39 PM.
Technically correct, logically not correct. Libraries do not have any use on their own, only when another code uses to perform some actions via their APIs. Libraries are a sort of factories, or frameworks, or whatever you call it. For example LibAddonMenu has not use if I just drop it into my Addons directory, it's a facility that another addon can re-use to standardize how setting are published and managed. Libraries give up purely APIs but not a complete user facing product, which is in this case would happen to be an addon. So there is a huge different in design between libraries and addons. And of cause libraries are shared between addons, addons can interact with each other on contrary.
If you really want to make that distinction, you're making it on the wrong level. LibAddonMenu, the thing you download here, is an add-on. When the add-on is loaded, it publishes an API via LibStub, the registry of libraries. That's only to not pollute the global namespace, some libraries publish global functions. Library=API. I could create an add-on that provides LibFoo, LibBar and LibPuzzles. Of course that would be silly and confusing. The convention is to package those separately.
When another add-on wants to use LibAddonMenu, it asks LibStub to give it the API table. It doesn't care whether the API was registered by ThisAddon/Libs/LibAddonMenu.lua, UnrelatedAddon/Libs/LibAddonMenu.lua, stand-alone LibAddonMenu/LibAddonMenu.lua, or FakeLAM/LibAddonMenu.lua. The only reason we embed Libs/* we use inside add-on zip is convenience, so that users don't have to install and update all dependencies separately.
Let me put it this way. You want your add-ons Joe and Bob to know each other's version, and publish some functions so they can communicate. Why not use LibStub, which is already there, used by many?
Lua Code:
-- bob.lua
local bob = LibStub:NewLibrary("Bob", 3.2)
function bob.pingJoe()
local joe, joeVer = LibStub:GetLibrary("Joe", LibStub.SILENT)
if joeVer and joeVer >=3.0and joeVer <4.0then
pcall(joe.ping, "hey, Bob's here")
end
end
-- joe.lua
local joe = LibStub:NewLibrary("Joe", 3.3)
function joe.ping(msg)
df("ping: %s", tostring(msg))
end
That's it. There's no reason to have another namespace for APIs whose only difference is that they don't have "Lib" in their name; and another library duplicating LibStub.
And beside this brain****.. Which addons should communicate together ?.. Which authors are ready to do this ?.. And what is the purpose ?.. Are we even capable (addon community) to build new things, we are losing more and more authors, projects are becoming very hard to update due to lack of time, skill, motivation ..
Well, for what it worth I'm trying to get ahold of ESO API and pick up development of some of the addons that were left behind now. Yes lack of time and something that puts many things on hold. Another problem is that there is no documentation or any reference so I have to dig it piece by piece from source code of other addons. The questions I ask are not from thin air, this is something that I come across and find it missing from current implementations. I might tend to over-engineer some things that may be done over simpler but less systematic way, but that's more of my professional nature takes its toll here .
Technically correct, logically not correct. Libraries do not have any use on their own, only when another code uses to perform some actions via their APIs. Libraries are a sort of factories, or frameworks, or whatever you call it. For example LibAddonMenu has not use if I just drop it into my Addons directory, it's a facility that another addon can re-use to standardize how setting are published and managed. Libraries give up purely APIs but not a complete user facing product, which is in this case would happen to be an addon. So there is a huge different in design between libraries and addons. And of cause libraries are shared between addons, addons can interact with each other on contrary.
Originally Posted by merlight
Originally Posted by uladz
Addons and libraries should not be mixed together.
Except that libraries are add-ons, which only happen to be embeddable without conflicts thanks to LibStub. And if your add-on has public API, it is a library.
And beside this brain****.. Which addons should communicate together ?.. Which authors are ready to do this ?.. And what is the purpose ?.. Are we even capable (addon community) to build new things, we are losing more and more authors, projects are becoming very hard to update due to lack of time, skill, motivation ..
In 2 months, VR will be removed, ALL addons with a single call to GetVeteranThing() will be to rewrite, we will have lot of addons to rewrite, that's a huge amount of thing to do.. ESO has its base of addons, if you want to improve them.. there is a ton of addons to rewrite with a poor level of coding which could be optimized, there is less than 10 addons with a GUI which are Gamepad ready.. less than 10.. I do think improving those points are more important than to bring addon communication, especially when you can write a public func in 30sec.
Technically correct, logically not correct. Libraries do not have any use on their own, only when another code uses to perform some actions via their APIs. Libraries are a sort of factories, or frameworks, or whatever you call it. For example LibAddonMenu has not use if I just drop it into my Addons directory, it's a facility that another addon can re-use to standardize how setting are published and managed. Libraries give up purely APIs but not a complete user facing product, which is in this case would happen to be an addon. So there is a huge different in design between libraries and addons. And of cause libraries are shared between addons, addons can interact with each other on contrary.
Originally Posted by merlight
Originally Posted by uladz
Addons and libraries should not be mixed together.
Except that libraries are add-ons, which only happen to be embeddable without conflicts thanks to LibStub. And if your add-on has public API, it is a library.
Addons and libraries should not be mixed together.
Except that libraries are add-ons, which only happen to be embeddable without conflicts thanks to LibStub. And if your add-on has public API, it is a library.
I understand, that is why I proposing to extend it.
What the reason to do not have API publishing alongside with announcing loaded addons? Spawning single-use libraries just to facilitate interaction between two addons is absolut nonsense as it defeats the meaning of a library. Having a global (public) function in addons is something I want to prevent to minimize global namespace pollution and collisions.
As it is right now the LibLoadedAddons has very little to none of use. With addon API publishing is gets on an importance piece of functionality that actually make the addon usable as a inter-addong glue layer.
[quote=Ayantir][quote=uladz]
Originally Posted by merlight
Originally Posted by uladz
Versus this LibLoadedAddons library, which suppose to provide singleton type inter-addon communication facility. Addons and libraries should not be mixed together.
LibLoadedAddons don't do that. To make 2 addons discuss together, use a shared lib between addons or add public functions in both addons.
LibLoadedAddons is just telling you if an addon is loaded by looking to AddonManager.
Versus this LibLoadedAddons library, which suppose to provide singleton type inter-addon communication facility. Addons and libraries should not be mixed together.
LibLoadedAddons don't do that. To make 2 addons discuss together, use a shared lib between addons or add public functions in both addons.
LibLoadedAddons is just telling you if an addon is loaded by looking to AddonManager.
Not exactly, the whole purpose of LibStub is completely different and should not be mixed with LibLoadedAddons. LibStub should be used for libraries to resolve multiple versions conflicts and provide only one the most recent library API to all addons loaded. it has own mechanism of "registering" libraries and selecting the most recent version. Versus this LibLoadedAddons library, which suppose to provide singleton type inter-addon communication facility. Addons and libraries should not be mixed together.
Guys, how do you manage development of this library? I have some changes that I want to contribute back. I've tried to PM @circonian but did not get any reply yet. My address what I have proposed in my previous post - sharing of APIs between addons without exposing global objects/functions.