well, I just think we shouldn't have displays lock out specific DOs only because the author thinks they are bad. The main idea behind LDB was user choice so don't make this choice for the user. Also since there is no sharp line that can be drawn. A DO you would consider a launch button snce clicking it does only fire a function could alos provide some data via a tooltip.
Anyways I wonder how long it takes until the first users complan about addons not showing stuff although on their friends PC (using a different display) everything shows fine... maybe I should get a popcorn machine ;)
The main problem with these launcher stile DOs is that they can become legion so instead of locking them out via a .launcher we should rather group them (and others) somehow. Maybe via some common description of the DO like whether it has static icon/text/tooltip. So in theory it would be even possible to have the user decide on how to group the DOs in the config windows.
actually I'm a bit pissed about the sudden rush to put the stuff into trunk...
- why bringing a LDB-1.1 to use if there wasn't even a 1.0 released?
- Broker_* sucks as naming schema... the lib is a broker, but these addons aren't
- wrt the .launcher stuff I'm not happy either... for config-only stuff we now have the addon panel so instead of telling the people "when you setup a config launcher using LDB, set the launcher filed" tell them to not use LDB for that at all... and even if they do, many won't set the launcher field anyways... (and what about those who would want to have such thing showup in eg StatsBlocks?)
- putting stuff into trunk "to have more people use it " is fun, but without any dokumentation, especialy on which are the basic attributes and how they are intended to be used, this whole stuff can easily get out of control :/
OK, maybe I'm over-pessimistic once again but I still belive we should have cleaned up the whole stuff before doing a public release...
Elisa, the DOs aren't ment to have libs embedded since this can result in unexpected behaviour. The DO uses metatable magic in order to fire callbacks whenever a value is changed so any internal operations could result in unexpected callbacks fireing that may be misinterpreted by the display. Every value set on the DO is an attribute so keep the number small. Or use namespaces in case the attributes are very specific.
So you should split your addon into the addon part that updates data in the DO as needed and the DO itself only holding the data.
Also should the display never change the data stored in the DO, that's the job of the addon providing the DO.
To stick with your code: The DO would have attributes containing the durability of the different slots and the display would subscribe the the DO's AttributeChanged callback to get informed if one of these durabilities changes in order to update its display.
But as you may notice this is a very special case of DO/display where the display is written specificaly for the DO and that wasn't the intention behind the lib.
The intention was that in theory any DO could be shown on any display / any display could show any DO. So in that case your whole armorman would be part of the addon providing the DO (or your addon would have an interface of its own for such displays).
Sure, the idea of using LDB for this task works out somehow but at least currently your displays are hardcoded to a specific DO and in that case there is no reason to use LDB for that task.
But wrt further development, an attribute on the DO stating that the DO provides other attributes that should be interpreted as durability values in some way (eg for player, party members, raid, inventory..) and your display using that attribute to filter its list of available DOs in order to have the user chose from... that would work out with the idea I had when initialy designing the lib. But your display should then be able to handle more than one DO.
Well, for FuBar direct support isn't really needed although it would be nice. But it shouldn't be hard to create an addon that will create FuBar plugins from DOs.
if the displays would handle everything, we would have to write a spec to allow customization and hardly any display would fully implement taht rendering it almost useless... have a look at CORBA ;)
so in this matter I agree with tekkub: have the DO create/supply and populate the frame, the display only anchors it. I think show/hide can be handled by the DO, too, since if the display doesn't want the tooltip to show it simply doesn't fire OnEnter.
well, you said if I want a custom display I should ship it with my addon that provides the DO. But then many addons come with their own display and nothing is solved since these displays don't interact eg by sticking together and such.
The main idea for a display was something that displays eg the icon + text, like FuBar does or like StatsBlock does it. But these displays know nothing about any custom stuff an addon may want to display...
Well, that would mean the custom tooltip is a display. But how to tell the game that once hovering over your DO's representation in a eg FuBar-style display to show that tooltip display? sure, the primary display could connect the DO to the secondary display and so on, but do you really want John Doe user to have to set THAT all up?
no, it is intentional that the DO can handle the tooltip in order to allow interactive and custom tooltip frames.
examples would be a frame showing the armor man or DOs from FactionsFu/FriendsFu/GuildFu that allow interaction with the data shown.
back from a abour 10-day vacation without inet and a lot of discussion going on in here :)
it was decided that CBH should be handled like LS meaning the libraries come with it but don't load it if they are embedded.
When seeing ag removed CBH and LS from the lib's directory it remembered me I wanted to reorganize the directory structure in a way similar to the one posted (but with LS in its own subdir, too, in case we ever manage to get fixed externals working in the zip-script)
- callback prefix
I prefixed the callbacks like I did in LSM-3 in order to allow authors to use a generic dispatcher if they want (though I don't know why they would) without risking to have two libs fire the same callback with different syntax
- callback suffix
this was to allow the display addon to register only for callbacks from the data objects it actually listens to. I was talking about that to tekkub on IRC and it was some kind of compromise when he suggested to narrow it further down to attributes. Also I think it safes some CPU cycles due to smaller tables especially when many static data objects are registered.
The lib isn't intended as a replacement for option tables but to provide a registry for data objects. So the On* attributes correspond to seeing the visual representation as object that is interacted with.
- forcing .text
as it was said I vote against forcing any attribute. There's always the DO's handle as fallback and why should someone register a DO without showing anything?
- addons using DOs for config access icons
noone forces you to have any display addon subscribe to these DOs so this is fine.
- categorizing / .cmdOnly
I'm not a fan of that attribute. I'd rather have some sort of categorizing for the DOs since that's what the attribute would be used for
(I wonder if anyone will try to build action bars with LDOB ;) )
- namespacing attributes
that's a bit of a problem. Good ideas tend to be promoted into standards but then the namespace prefix is no longer needed. Though as long as it's a singe addon providing someexotic stuff I think it should be namespaced. the DO providers can be changed once an attribute is promoted to the standard.
- initial display
A question that remains: what to do with new DOs? Since the setting to show is done per display setting up stuff will get a bit harder with the lib since most likely all displays will show the DO at first but that#s still better than none showing it and the user not noticing. Though I wondered if we should 'include' lib code for a basic minimap display like it was with FBP. Though not in the broker lib itself.
btw, ag, I don't think Broker_ is a good prefix for your DO provider addons, why not use DO_ as prefix? Or anyone having a better idea? also keep in mind that an addon can register as many DOs as it wants.
changes since the pastey are, in case I didn't forget anything else:
- callbacks are named a bit different: LibDataBroker_AttributeChanged_* and LibDataBroker_DataobjectRegistered
- LibDataBroker_DataobjectRegistered now also bringst the dataobject itself as argument
Besides that, as I said code is only a small part of the whole concept. We now need a list of attributes (values + callbacks) and their meanings so:
- an addon providing data object knows what it has to set to get the specific effect from the displays
- a display addon knows what to look for
btw: do we need a way to iterate over all attributes in an object? that would mean we need a reserved keyword for that since pairs won't work.