can anyone provide a VIABLE USE situation for anything that has been presented, that isn't already handled better by another addon (xpt for fubarplugin ofc)
The problem is that fubar has a monopoly and as long as nothing changes, that will continue. Now I don't have a problem with fubar being popular, I use it myself, the problem lies in that every addon under the sun is forced to conform to fubarPlugin. This means it's virtually impossible for anyone else to make use of that information, the only solution is to make an api of their own and hope that others want to port their plugins. How likely do you really think that is at this point?
The other side of this is that we're forced to conform to the wishes of ckknight. He's of course free to use whatever framework he wants, in fact I salute him for rolling his own instead of following the beaten path. However, it pisses me off that I'm forced to follow him just to get some basic i/o in my addon. Everyone's so gung-ho about framework agnosticity, and yet you're telling me that writing a generic i/o library is a waste of time?
The point I'm trying to make is that we have three choices.
a) Everyone includes Rock in their mods to be able to use libFubarPlugin-3.0.
b) Someone ports libFubarPlugin to Ace3.
c) We make a generic addon interface which can work with anything people care to code for.
A is, at least for me, completely out; I refuse to clutter my addons with two frameworks. And yes I realize I already have Rock running with fubar, I just think it's retarded that I should need to use two frameworks for something this simple. B is better, but it's still just a band-aid fix. It means we're still stuck with fubar as the only interface of choice. It's also a waste of developer time if you ask me.
C is imho the only sane solution to this, and it's about time that someone thought of it. We're not even talking that much work for an interface like this. All it needs to do is expose a few bits and bobs, and let implementation take care of the rest. Considering that libFubarPlugin likely needs to be ported in the first place, it should be a relatively small issue to make it talk to an interface instead.
All I'm saying is that this has to be solved some time quite soon. Once ace3 rolls out there needs to be fubar support, and I hope people don't cop out.
The thing about (c) is that it also provides a minimal amount of code to embed, which is the main reason noone wants to do (a).
I've not poked at this much myself because I've been moving away from the fubar plugin stuff. The only things I run right now that would be on fubar are... Cork (I'm rewriting), GuildBlock, FriendsBlock, EXPBlock and PerfBlock. In all honesty, I'm more inclined as of late to make a simple all-inclusive addon that displays those few little vital stats.
If someone does flesh out and release an official data-broker lib, I'll gladly start using it in the addons that could benefit.
We do have a Data Broker lib out, it just needs testing. I was starting work on a bar mod to test it with (ZanziBar), but I haven't been able to do any more work on it as of late. All we need to do is test the library, work out any bugs, and then it's ready to go.
The lib is here.
The point is that to make a single data block, the bar addon would simply have to create a frame, take only the attributes that it cares about from the data block, and apply them to the frame. Eg. the bar gives the addon 'foo' a data frame. It calls .foo.icon:SetTexture(icon attribute), and .foo:SetScript("OnClick", OnClick attribute).
This makes it nice, easy, and lightweight for the bar addon, and then gives the author of the addon 'foo' the greatest flexibility in what he can set the attributes of his addon's data frame to.
True, this does give the author of 'foo' extra work, but other libraries could be used to make it easier. (eg. DewDrop)
Tah-dah! This makes it easier for the authors of the bar addons and the misc. addons that use the bar addons, and only requires more effort from the people writing the libraries that communicate between the two.
set an attribute of "cmdOnly" and then TADAA, the display addon can choose to show it or not.
Of course it's that simple. That name just needs to be nailed down and added to the spec.
To clarify: What I want is a way for addons to signal that they're just a stupid quicklaunch button to the displaying addon / barmod / whatever. I know that this cannot be enforced. I'm fine with that, I'm good at whining at authors as well as dropping addons I don't like :)
All it adds is a few error calls on invalid data, and creation with a set of attributes. I added the error to the RegisterObject, cause even the test cases fail to check the return value to make sure the object actually registered. Namespace collisions ftl.
Also as you can see I changed the register, and atrbiute changes messages. Since you add the callback for this lib, prefixing with LibDataBroker seemed un-needed. Same for Attribute changed, you get the name, key and value that changed, so there is no need for creating a new 'event' for each registered object.. all it ended up doing was causing people to ignore the name anyways
Im sure we need to go over it a little more and really flesh out failure points, error conditions that need checked. Also why was CallbackHandler removed from the externals without creating a dummy stub of some type? Also why do the Name_Attrbiute for custom attributes? Again this seems unnecessary and going to end up being totally un-used or is every display mod going to have to build custom strings every time to see if some attribute is there OR we end up having dataobjects crafted specifically for a display mod via custom attrbiutes?