Download
(1 Kb)
Download
Updated: 12/01/21 10:10 AM
Compatibility:
Deadlands (7.2.5)
Waking Flame (7.1.5)
Blackwood (7.0.5)
Flames of Ambition (6.3.5)
Markarth (6.2.5)
Stonethorn (6.1.5)
Greymoor (6.0.5)
Updated:12/01/21 10:10 AM
Created:01/02/16 10:19 PM
Monthly downloads:1,432
Total downloads:272,832
Favorites:167
MD5:
LibLoadedAddons - OBSOLETE, Please remove from addons  Popular! (More than 5000 hits)
Version: 999 - OBSOLETE
by: uladz, Baertram
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!
Archived Files (6)
File Name
Version
Size
Uploader
Date
2
3kB
Baertram
10/17/21 08:26 AM
1.4
2kB
Baertram
05/26/19 12:25 PM
1.3
2kB
Baertram
05/19/19 04:44 PM
1.2
2kB
Baertram
09/17/18 04:34 AM
1.1
2kB
Baertram
08/30/18 12:10 PM
1.0
1kB
circonian
01/02/16 10:19 PM


Post A Reply Comment Options
Unread 01/03/16, 09:45 AM  
Baertram
Super Moderator
 
Baertram's Avatar
ESOUI Super Moderator
AddOn Author - Click to view AddOns

Forum posts: 4912
File comments: 5990
Uploads: 78
Thanks circonian, will implement it into my connected addons so other devs can use it to check stuff (in addition to checking for existing global varibales etc.)
Report comment to moderator  
Reply With Quote
Unread 01/28/16, 08:03 AM  
merlight
AddOn Author - Click to view AddOns

Forum posts: 671
File comments: 213
Uploads: 12
Sorry for nitpicking, but I think this library is superfluous.

1) Any add-on can check whether another add-on is loaded in their ON_LOADED handler. No need to have a library that does the exact same thing, and query that library. Plus, this extra indirection might conceal the otherwise obvious requirement that you can't make the query inside your ON_LOADED handler unless you have OptionallyDependsOn: in manifest.

2) This library adds version information. That looks nice at first, but encourages bad practice IMO. When you want to cooperate with another add-on, you shouldn't make your decisions around whether its version is >=2.5 or <=4.1. You need a feature/API to be present. That feature might be introduced in 2.5, so you check for version>=2.5, and if the feature is removed in 3.7 you're broken.
Report comment to moderator  
Reply With Quote
Unread 01/28/16, 06:36 PM  
circonian
AddOn Author - Click to view AddOns

Forum posts: 613
File comments: 804
Uploads: 27
Originally Posted by merlight
Sorry for nitpicking, but I think this library is superfluous.
I wrote it strictly for myself & my addons. I use it in several addons and one in particular that has to watch for several other addons for compatability. It was just easier & cleaner imo.

This wasn't written with other developers in mind and I had no intention of posting it. I only posted it because another user found it in one of my addons and requested to use it so I posted it for him.

I'm not disagreeing with the fact that this library doesn't really offer much, but as for the comments

Originally Posted by merlight
1) Any add-on can check whether another add-on is loaded in their ON_LOADED handler. No need to have a library that does the exact same thing, and query that library. Plus, this extra indirection might conceal the otherwise obvious requirement that you can't make the query inside your ON_LOADED handler unless you have OptionallyDependsOn: in manifest.
1) The same could be said for any library. If it can be done in a library it could be done in the addon itself.

As for the ON_LOADED, the OptionalDependsOn statement is true...but I don't see why any of it needs to be done in ON_LOADED, just because that's what everyone is used to doing is not a good reason.
  • Although your way you can watch ON_LOADED to see when an addon is loaded & you could immediately try to run your compatibility code, I can't think of any reason to need to run it immediately and it doesn't sound like a good idea. When your addon sees the addonName "JunkIt" that is the same time my addon sees "JunkIt" and that is when my addon STARTS to run code & initialize everything. So although you could immediately try to run some compatability code, my addon probably hasn't finished initializing yet so you probably shouldn't be calling another addons code or messing with their controls in ON_LOADED regardless of which method your using IMO.
  • If you need to run some of your own code, that does not need any access the other addon, then it could be done immediately. But if you don't need any access to the other addon, then why the dependency on it. I admit I'm sure there is an example out there for this, but I can't think of one, so even that seems like a moot point.
  • If your only watching to see which addons are loaded in ON_LOADED & you are running your compatability code later...then the point seems irrelevant, because both methods require code to be run later (outside of ON_LOADED) and then a dependency is not needed.
Originally Posted by merlight
2) This library adds version information. That looks nice at first, but encourages bad practice IMO. When you want to cooperate with another add-on, you shouldn't make your decisions around whether its version is >=2.5 or <=4.1. You need a feature/API to be present. That feature might be introduced in 2.5, so you check for version>=2.5, and if the feature is removed in 3.7 you're broken.
2) That comment is based off of the idea that a developer will use it improperly. The same argument could be made that any library used improperly could cause errors.

I'm not saying the version check is an awesome feature or that it would even prove useful to many, but it was an easy additional feature that I thought might prove useful somewhere/sometime, it is optional, & it is harmless. If a developer checks the version number using a inequality like: >= 2.5 rather than a strict equality or based off of a set of version numbers that he knows it will work for....that's his own fault. Not to mention that your alternative has no way of knowing what version is loaded. How is that better? Even if a developer doesn't know any better and unwisely uses >= 2.5, they are still better off than someone using your method whos not checking a version number at all because at least it will exclude versions < 2.5. Your method is guaranteed to run into the problem/error that you mentioned since you can't check version numbers. But, with the version check option they have the ability to catch & prevent errors such as that.

Your example is actually a good example of why the version check could be a good thing. Because if its used properly with a strict equality or the proper inequality (including only versions that are known to be compatible) then when that other addon removes that feature in 3.7 your addon won't have any problems. If a developers complaint is then, but everytime they update their addon I have to update mine to change the dependent version number....then don't use it, its optional. You'll just have to deal with the consequences that when they remove that feature your addon is going to crash, which is no worse off than anyone is now. So I see nothing negative about having a version check.
Last edited by circonian : 01/28/16 at 06:43 PM.
Report comment to moderator  
Reply With Quote
Unread 01/28/16, 09:11 PM  
merlight
AddOn Author - Click to view AddOns

Forum posts: 671
File comments: 213
Uploads: 12
Originally Posted by circonian
Originally Posted by merlight
Sorry for nitpicking, but I think this library is superfluous.
I wrote it strictly for myself & my addons. I use it in several addons and one in particular that has to watch for several other addons for compatability. It was just easier & cleaner imo.

This wasn't written with other developers in mind and I had no intention of posting it. I only posted it because another user found it in one of my addons and requested to use it so I posted it for him.

I'm not disagreeing with the fact that this library doesn't really offer much, but as for the comments
I just wanted to give you a hint that this might be something not worth maintaining, since both its features are redundant.

Originally Posted by circonian
Originally Posted by merlight
1) Any add-on can check whether another add-on is loaded in their ON_LOADED handler. No need to have a library that does the exact same thing, and query that library. Plus, this extra indirection might conceal the otherwise obvious requirement that you can't make the query inside your ON_LOADED handler unless you have OptionallyDependsOn: in manifest.
1) The same could be said for any library. If it can be done in a library it could be done in the addon itself.
Of course. But a library should at the very least reduce code duplication, or simplify working with awkward API, implementation details and such.

Lua Code:
  1. local LIBLA = LibStub:GetLibrary("LibLoadedAddons")
  2.  
  3. local function mySomeFuncLongAfterLoad()
  4.     if LIBLA:IsAddonLoaded("Companion") then ... end
  5. end
  6.  
  7. local function myOnLoaded(evt, addonName)
  8.     if addonName == "ThisAddon" then myInit() end
  9. end

Lua Code:
  1. local seen_companion = false
  2.  
  3. local function mySomeFuncLongAfterLoad()
  4.     if seen_companion then ... end
  5. end
  6.  
  7. local function myOnLoaded(evt, addonName)
  8.     if addonName == "Companion" then seen_companion = true -- bloat
  9.     elseif addonName == "ThisAddon" then myInit() end
  10. end

Okay, so it reduces some bloat. If you need to check for many addons, that may pay off. With just one, not worth it.


Originally Posted by circonian
Originally Posted by merlight
2) This library adds version information. That looks nice at first, but encourages bad practice IMO. When you want to cooperate with another add-on, you shouldn't make your decisions around whether its version is >=2.5 or <=4.1. You need a feature/API to be present. That feature might be introduced in 2.5, so you check for version>=2.5, and if the feature is removed in 3.7 you're broken.
2) That comment is based off of the idea that a developer will use it improperly. The same argument could be made that any library used improperly could cause errors.
"A good library is easy to use, and hard to misuse." That's what I mean by "encourages bad practice". You provide the tool to check whether version >= 2.5. It's easy to misuse.


Originally Posted by circonian
Your example is actually a good example of why the version check could be a good thing. Because if its used properly with a strict equality or the proper inequality (including only versions that are known to be compatible) then when that other addon removes that feature in 3.7 your addon won't have any problems. If a developers complaint is then, but everytime they update their addon I have to update mine to change the dependent version number....then don't use it, its optional. You'll just have to deal with the consequences that when they remove that feature your addon is going to crash, which is no worse off than anyone is now. So I see nothing negative about having a version check.
If I wanted to call a function from another add-on, I'd first check that it exists, and then pcall(it). Who wants to test against each new version that comes out, and manually bump version numbers?

In my previous post I actually thought the version info was more useful than plain presence check. Now I'm 100% convinced version info is superfluous. LibStub does that. If an add-on has a public, versioned API, it should publish it via LibStub. Why have another dependency doing the exact same thing?
Last edited by merlight : 01/28/16 at 09:14 PM.
Report comment to moderator  
Reply With Quote
Unread 01/28/16, 10:15 PM  
circonian
AddOn Author - Click to view AddOns

Forum posts: 613
File comments: 804
Uploads: 27
Of course. But a library should at the very least reduce code duplication, or simplify working with awkward API, implementation details and such. Okay, so it reduces some bloat. If you need to check for many addons, that may pay off. With just one, not worth it.
I have one addon that watches for 6 other addons.

"A good library is easy to use, and hard to misuse." That's what I mean by "encourages bad practice". You provide the tool to check whether version >= 2.5. It's easy to misuse.
I would argue that even in that worst case scenario of someone using it poorly >= 2.5 that they are still better off than someone not checking a version number at all. It eliminates versions < 2.5, assuming those are known to be incompatible (otherwise there was no point in the check). It may be minor, but that's the worst case scenario and there is only benefit there & no loss.

If I wanted to call a function from another add-on, I'd first check that it exists, and then pcall(it). Who wants to test against each new version that comes out, and manually bump version numbers?
I would also recommend checking first...but if your doing that, then that nullifies the original comment. If that user checked the existence of the function first it really doesn't matter if he uses >= 2.5 and the other addon removes the function. However that wouldn't catch a problem if the users updates the addon & changes the function. I'm just saying, the existence of the function isn't always the problem. I agree that I wouldn't want to bump version numbers either & wouldn't use the check, but that doesn't mean its not beneficial if used. More work to keep it up to date, but it would prevent problems too.

As I said I never had any intention of posting it, because I agree it is a bit superfluous, but someone asked me for it and I still see no harm or downside, so I wasn't going to tell them no.
Report comment to moderator  
Reply With Quote
Unread 03/22/16, 10:55 PM  
uladz
AddOn Author - Click to view AddOns

Forum posts: 11
File comments: 223
Uploads: 2
suggestion

I would suggest to add an additional API method to get addon object in case if you want to access its API
Lua Code:
  1. LIBLA:RegisterAddon(string ADDON_NAME, number ADDON_VERSION, table ADDON_OBJECT)
  2. local addon = LIBLA:GetAddon("QuestTracker")
This would decouple internal addon main object defition from public. Now I see that people just declare it as global variable allowing every other addon to see it it case if then want to inter-connect. I need to do the same thing now to make to addons work together but I'm far from liking this solution. This library seems to be the right way to go but I'm missing GetAddon functionality.
Please consider extending this library API, this can be done 100% backward compatible. Thanks!
Last edited by uladz : 03/22/16 at 10:56 PM.
Report comment to moderator  
Reply With Quote
Unread 04/05/16, 09:29 PM  
uladz
AddOn Author - Click to view AddOns

Forum posts: 11
File comments: 223
Uploads: 2
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.
Report comment to moderator  
Reply With Quote
Unread 04/06/16, 05:35 AM  
merlight
AddOn Author - Click to view AddOns

Forum posts: 671
File comments: 213
Uploads: 12
Originally Posted by uladz
sharing of APIs between addons without exposing global objects/functions.
There's LibStub for that.
Report comment to moderator  
Reply With Quote
Unread 04/06/16, 12:35 PM  
uladz
AddOn Author - Click to view AddOns

Forum posts: 11
File comments: 223
Uploads: 2
Originally Posted by merlight
Originally Posted by uladz
sharing of APIs between addons without exposing global objects/functions.
There's LibStub for that.
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.
Report comment to moderator  
Reply With Quote
Unread 04/06/16, 04:56 PM  
Ayantir
 
Ayantir's Avatar
AddOn Author - Click to view AddOns

Forum posts: 1019
File comments: 1531
Uploads: 31
[quote=uladz][quote=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.
Report comment to moderator  
Reply With Quote
Unread 04/06/16, 06:06 PM  
uladz
AddOn Author - Click to view AddOns

Forum posts: 11
File comments: 223
Uploads: 2
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.
Report comment to moderator  
Reply With Quote
Unread 04/06/16, 06:08 PM  
merlight
AddOn Author - Click to view AddOns

Forum posts: 671
File comments: 213
Uploads: 12
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.
Report comment to moderator  
Reply With Quote
Unread 04/06/16, 06:14 PM  
uladz
AddOn Author - Click to view AddOns

Forum posts: 11
File comments: 223
Uploads: 2
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.
Report comment to moderator  
Reply With Quote
Unread 04/06/16, 07:22 PM  
Ayantir
 
Ayantir's Avatar
AddOn Author - Click to view AddOns

Forum posts: 1019
File comments: 1531
Uploads: 31
Originally Posted by uladz
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.
Last edited by Ayantir : 04/06/16 at 07:29 PM.
Report comment to moderator  
Reply With Quote
Unread 04/06/16, 08:01 PM  
uladz
AddOn Author - Click to view AddOns

Forum posts: 11
File comments: 223
Uploads: 2
Originally Posted by Ayantir
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 .
Report comment to moderator  
Reply With Quote
Post A Reply



Category Jump: