In disembedded mode, loading Ace3 automatically loads libstub and callbackhandler, as they are included in the Ace3 lib. in standalone, they'll need to be included as an external.. AND referenced by the toc (or embeds.xml if the toc references this).
Failure to do so will result in errors unless some other addon gets loaded first and properly references those two libraries.
From what I have learned in this thread is that
- there are many gotchas with lsm, and using lsm 3 is the most complicated choice.
- the only difference between lsm 2 and 3 are asian fonts and callbacks... both features that I don't need.
So this thread perfectly suggested the use of lsm-2.0 for me.
CALLBACKS ARE A REQUIRED PART OF THE ENTIRE SHAREDMEDIA IDEA! EVERYBODY MUST USE THEM! LSM-2.0s LACK OF COMPLETE CALLBACK API IS A DESIGN FLAW IN THE LIBRARY MEANING YOU SHOULDN'T USE IT!
Why do people not understand this. Makes me want to svn del everything else just to force people to use LSM-3.0 so they'll stop thinking they don't need to upgrade.
Instead of getting upset about, why don't you explain to us exactly why call backs are needed? This is exactly why I started this thread, because this and other things like it are not documented anywhere that I know of. I sure don't use callbacks right now with LSM and all my LSM 2.0 mods work just fine with all the other LSM files/mods I have installed.
I assume you have the 'SharedMedia', try adding your mod as a reqdep to SharedMedia so that SharedMedia loads after your mod then see how much media is available in your addon. You can also try making SharedMedia LoD then loading it after you login. And no, adding SharedMedia as an optdep to your own addon is not a solution since any addon can register media. SharedMediaLib-1.0 had callbacks too btw, they were called events from AceEvent-2.0. Media getting registered after your addon has loaded and done LSM:Fetch(...) will always have issues depending on load order unless you use Callbacks.
So you do LSM:Fetch() on PLAYER_LOGIN (or some other event that fires after all addons load) and then do LSM:Fetch() after all ADDON_LOADED's that fire after that first event? Ok that does work without needed to use the media registered callback but you still aren't doing anything for when the global override changes, and LSM-2.0 doesn't have any way to tell you to LSM:Fetch() again when the user changes the global override. LSM-3.0 has a callback for when the user changes the global override so that you can do LSM:Fetch() again (SML-1.0 fired an event too when the global override was changed, this is the major API flaw in LSM-2.0 that kept it from being converted to using CBH-1.0 and requiring a major version number change).
Most people haven't tried to do anything like you have to work around the issue and instead just do LSM:Fetch() once. The worst are the 'upgrades' that do nothing but change the name. I don't know why some people don't understand that major version number increases happen when API changes, so only changing the name gets them on my shitlist and I will revert the changes (if I can) if its a completely broken upgrade like CooldownCount recently did (which broke every mod that uses LSM-3.0 when CooldownCount was loaded first with embedded libraries).
LibSharedMedia-3.0 is really easy to use. Basically you grab the lib to use as before with something like:
local SM = LibStub:GetLibrary("LibSharedMedia-3.0")
In your OnInitialize you register the callbacks:
function MyAddon:OnInitialize()
SM.RegisterCallback(MyAddon, "LibSharedMedia_Registered", "UpdateMedia")
SM.RegisterCallback(MyAddon, "LibSharedMedia_SetGlobal", "UpdateMedia")
end
where you have a function to update your media:
function MyAddon:UpdateMedia()
for _, v in pairs(MyAddon.mystatusbarframes) do
v.StatusBar:SetStatusBarTexture(SM:Fetch(SM.MediaType.STATUSBAR, thebartextureilike))
end
FontFile=SM:Fetch("font",fontiwant) -- Could use SM:MediaType.FONT instead of "font"
for _, v in pairs(MyAddon.FontStrings) do
_, Height, Flags = v:GetFont()
v:SetFont(FontFile, Height, Flags)
end
-- Any other media updates one needs here.
end
What one gets for doing that one callback is that load order or optdeps never matter. One wouldn't optdep SharedMedia anymore because the callback will take care of it if it's present. It will also work in odd cases where new media is registered late by a third addon etc.
Elsia gave a very basic example. The callbacks from LSM-3.0 will rarely get called so its not that big of a deal to still have them registered while an addon is in standby. The callbacks both return the mediatype and name as args but in the most basic of uses you don't need to worry about the args since you can just re-fetch everything when the callbacks are fired. More advanced uses might care about which mediatype and the name of the media before doing any fetching.
Point is really that using LSM3 is easy. It's like LSM2 with one callback function and 2 callback register (and unregisters if you want). I'm just trying to give an explicit example to show it in code so people who are unsure have a base to start with. And yes there is detail the example doesn't cover, e.g. there is no check if the correct media is already used but people can fill in that detail I think. If anyone wants to write down a more fine-grain example, go for it.
Basically for that one callback function one gets the whole checking that one needs to do and Grayhoof has described, plus also correct behavior of media arrives under other conditions.
I'd argue that's very simple to code in comparison and works under all imaginable conditions. That doesn't really change if one decides to move the registration into OnEvent or decides how precisely to update media from the events.
Of course.. an addon that registers textures and fonts could be load on demand... but adding those to other addons that are always loaded is totally senseless in my eyes.
E.g. an addon only loaded when in raid adds that wonderful bar texture and font and that I might select for my unitframes when I'm currently in raid. I relog and whuush the font and texture is gone because the addon is not loaded.. and no clue why it's only sometimes available.
I add all sharedmedia I use in my own small addon .. so I know it's always available and I will never need callbacks.
I see this pragmatically. Before I switch to LSM3, I had persistent bug reports, mostly because another addon screwed their dependencies which caused issues for recount. Ever since I switched to LSM3 Recount is immune to dependency messups of other addons and will get the media it needs, independent of much gymnastics watching if media is there (and yes people at least used to be horribly confused over SM vs SM2).
Basically LSM3 offers a solution that will work in all contexts and is clean and safe vs how other addons act. It completely removes all worries if a shared media repo is opt-dept'd or not. (For example there are other shared media repos, like SharedMediaFonts and SharedMedia-Blizzard that you'd need to optdep without callbacks to be sure to get them sensibly, or alternatively you'll have to go through the routine Grayhoof outlined). If someone creates a SharedMedia-FunkyFonts, that most won't want, LSM3 will support this without optdep worries. LSM2 you'll have to do some gymnastics to achieve the safe "is this actually loaded" functionality. LSM3 just wraps this up for you in one nice callback.
In short LSM3 is just a clean universal solution that will work for any addon. LSM2 you can make work in your context but it's less safeguarded against misbehavior deps etc. There really is no drawback of using LSM3 over LSM2, while the inverse isn't really the case. In a sense LSM2 is certainly more delicate to use, just to avoid providing one simple callback.
More importantly switch to LibSharedMedia-3.0 before you send me on a rampage and I delete LibSharedMedia-2.0 from the svn. <3
I wholeheartedly support this rampage. Please get rid of 1.0 while you're at it. Having three versions of the same fucking library installed and running just looks retarded.
I wholeheartedly support this rampage. Please get rid of 1.0 while you're at it. Having three versions of the same fucking library installed and running just looks retarded.
ok.. just fix all addons that still use those libraries first.
Oh, for those interested, I have edited each and every one of my local copies of addons to use LibSharedMedia-3.0.
I've been using them for a while, making sure there'd be no issues, and it appears that they all function fine.
These are the ones I can think of, off the top of my head. Unless stated otherwise, the changes -only- affect my local copy, and are nowhere to be found on the svn
Aloft
Quartz(Ace3) (yes, the ace3 version works now, its in branches btw.. and Nymbia, if you read this.. I fixed the config issues, everything seems to work)
ag_UnitFrames (the branch called "break19" its a modified copy of ag's Ace3 branch, LSM-3.0 is not the only change, I also added LibMobHealth4 support.. )
BigWigs
well, simply changing only the author to ck is also a bad idea... simply compare the code the SML-1.0 and you'll see what he did. So at least some sort of "based on SML-1.0 by Elkano" should be included I think.
well, simply changing only the author to ck is also a bad idea... simply compare the code the SML-1.0 and you'll see what he did. So at least some sort of "based on SML-1.0 by Elkano" should be included I think.
coming from a point of view where im still using ace2, my mod currently does not need libstub nor callbackhandler, i just want to embed libsharedmedia3 like any other lib, so
local SM = LibStub:GetLibrary("LibSharedMedia-3.0")
if i do that i presume i have to include libstub/ace3 in my opt and req deps as my mod is now using it directly?
(i currently have SharedMedia = AceLibrary( "LibSharedMedia-3.0" ) )
function MyAddon:OnInitialize()
SM.RegisterCallback(MyAddon, "LibSharedMedia_Registered", "UpdateMedia")
SM.RegisterCallback(MyAddon, "LibSharedMedia_SetGlobal", "UpdateMedia")
end
same again? i presume i have to include callbackhandler in my opt and req deps as my mod is now using it directly?
just trying to figure this out as currently i just want to embed LSM3 like any other normal lib but it barfs because LS and CBH are not there (i presume that LSM3 is not setup correctly for some reason???) to get around this i have to specifically include LS and CBH in my svn properties (so they download for me and get added to the zips) but not include them in my toc (as i recently found out) because if i do then it stuffs up downloads for standalones.
i guess i'm trying to figure out why LSM3 has to be different to every other lib/mod in this regard?
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Failure to do so will result in errors unless some other addon gets loaded first and properly references those two libraries.
break19
CALLBACKS ARE A REQUIRED PART OF THE ENTIRE SHAREDMEDIA IDEA! EVERYBODY MUST USE THEM! LSM-2.0s LACK OF COMPLETE CALLBACK API IS A DESIGN FLAW IN THE LIBRARY MEANING YOU SHOULDN'T USE IT!
Why do people not understand this. Makes me want to svn del everything else just to force people to use LSM-3.0 so they'll stop thinking they don't need to upgrade.
An no, I don't use SharedMedia or put OptDepts to it in any of them.
Most people haven't tried to do anything like you have to work around the issue and instead just do LSM:Fetch() once. The worst are the 'upgrades' that do nothing but change the name. I don't know why some people don't understand that major version number increases happen when API changes, so only changing the name gets them on my shitlist and I will revert the changes (if I can) if its a completely broken upgrade like CooldownCount recently did (which broke every mod that uses LSM-3.0 when CooldownCount was loaded first with embedded libraries).
In your OnInitialize you register the callbacks:
where you have a function to update your media:
What one gets for doing that one callback is that load order or optdeps never matter. One wouldn't optdep SharedMedia anymore because the callback will take care of it if it's present. It will also work in odd cases where new media is registered late by a third addon etc.
Basically for that one callback function one gets the whole checking that one needs to do and Grayhoof has described, plus also correct behavior of media arrives under other conditions.
I'd argue that's very simple to code in comparison and works under all imaginable conditions. That doesn't really change if one decides to move the registration into OnEvent or decides how precisely to update media from the events.
Of course.. an addon that registers textures and fonts could be load on demand... but adding those to other addons that are always loaded is totally senseless in my eyes.
E.g. an addon only loaded when in raid adds that wonderful bar texture and font and that I might select for my unitframes when I'm currently in raid. I relog and whuush the font and texture is gone because the addon is not loaded.. and no clue why it's only sometimes available.
I add all sharedmedia I use in my own small addon .. so I know it's always available and I will never need callbacks.
Basically LSM3 offers a solution that will work in all contexts and is clean and safe vs how other addons act. It completely removes all worries if a shared media repo is opt-dept'd or not. (For example there are other shared media repos, like SharedMediaFonts and SharedMedia-Blizzard that you'd need to optdep without callbacks to be sure to get them sensibly, or alternatively you'll have to go through the routine Grayhoof outlined). If someone creates a SharedMedia-FunkyFonts, that most won't want, LSM3 will support this without optdep worries. LSM2 you'll have to do some gymnastics to achieve the safe "is this actually loaded" functionality. LSM3 just wraps this up for you in one nice callback.
In short LSM3 is just a clean universal solution that will work for any addon. LSM2 you can make work in your context but it's less safeguarded against misbehavior deps etc. There really is no drawback of using LSM3 over LSM2, while the inverse isn't really the case. In a sense LSM2 is certainly more delicate to use, just to avoid providing one simple callback.
I wholeheartedly support this rampage. Please get rid of 1.0 while you're at it. Having three versions of the same fucking library installed and running just looks retarded.
ok.. just fix all addons that still use those libraries first.
I've been using them for a while, making sure there'd be no issues, and it appears that they all function fine.
These are the ones I can think of, off the top of my head. Unless stated otherwise, the changes -only- affect my local copy, and are nowhere to be found on the svn
Aloft
Quartz(Ace3) (yes, the ace3 version works now, its in branches btw.. and Nymbia, if you read this.. I fixed the config issues, everything seems to work)
ag_UnitFrames (the branch called "break19" its a modified copy of ag's Ace3 branch, LSM-3.0 is not the only change, I also added LibMobHealth4 support.. )
BigWigs
break19
done
local SM = LibStub:GetLibrary("LibSharedMedia-3.0")
if i do that i presume i have to include libstub/ace3 in my opt and req deps as my mod is now using it directly?
(i currently have SharedMedia = AceLibrary( "LibSharedMedia-3.0" ) )
function MyAddon:OnInitialize()
SM.RegisterCallback(MyAddon, "LibSharedMedia_Registered", "UpdateMedia")
SM.RegisterCallback(MyAddon, "LibSharedMedia_SetGlobal", "UpdateMedia")
end
same again? i presume i have to include callbackhandler in my opt and req deps as my mod is now using it directly?
just trying to figure this out as currently i just want to embed LSM3 like any other normal lib but it barfs because LS and CBH are not there (i presume that LSM3 is not setup correctly for some reason???) to get around this i have to specifically include LS and CBH in my svn properties (so they download for me and get added to the zips) but not include them in my toc (as i recently found out) because if i do then it stuffs up downloads for standalones.
i guess i'm trying to figure out why LSM3 has to be different to every other lib/mod in this regard?