According to the LDB wiki, it is intended for no particular purpose : "Due to its simple generic design, LDB can be used for any design where you wish to have an addon notified of changes to a table."
This is correct, it can do things like this. However I feel that if LDB was to move this direction it would need either a fairly strict sense of spec or be hosted though a different name altogether with practically the same internal workings.
Adirelle The problem with "converting" LibSink to LDB sources is that now the addons will need to reCreate the options table that libsink provides. This is a big drawback, despite the market penetration.
About the label war^^
I also don't see a reason why the label field should be required.
For ChocolateBar I chose to hide the existence of labels from the user.
Since most launchers don't have a text field I check the label and display that as text. But only if the DO does not provide text and the user has show text explicitly enabled for the launcher.
Why is there a value + suffix field in the spec?
Just to save the DO author from adding 2 simple options about how the user wants to see the text displayed?
As i see it, and this is quite logical, the label war started really when launchers and data sources where seperated. Launchers by nature don't have displayable text, they shouldn't. If a luancher has any text it should be it's name or a very simple enabled/disabled style. Lanunchers thus use labels as that ideologie being what and how labels are used in general.
Data Sources by nature SHOULD have a textual dipslay that is somewhat more important than tagging an icon as something. For example, feeds that display current gold on the toon, the text is important to the effect that with out it, the whole feed would be almost useless. However, there are feeds, like performace monitors that change their text feild often and frequent, thus they requested to have a "prefix-value-suffix" method where the feed only had to update 1 element. As they could use the text option and just concatonate them all togeather and send that to LDB, exerianced users prolly don't want a huge ugly string cluttering up their display addon. That is seriously one of the reasons and it holds to true still.
The reason they finally moved to the label-value-suffix method is because they wanted to shift the responsibiltiy to the displaying addon and let it do the configureation and not require the source to have one. This has bennifits and drawbacks. Bennifits is that the source dosn't need to have a config window for 3 options, the display can do that inherantly in it's own config because it's going to naturally have one for each feed. The single most annoying drawback is that the displays now have to add support for something else. We all know how that turns out with LDB.
--I Submit therefor a common standard, or at least convention for textual displaying for "data source"'s. Easily expressed as:
( (label..value..(suffix or "") ) or text )
Where if a feed provides a label, it must provide a value and an optional suffix. This is a single "word". For example, a feed showing JUST memory use for just Adddons (excluding blizzards addon memory use), the label would be "Memory Use:", the value would be the used memory, and a suffix of "MB". This is what would be called the single word. The display then has the option to show the label or not. Text in this case is not ever used.
For Feeds that supply a "multi-word" text should do all the formatting an options on it's own and provide only text, no label value or suffix at all.
With regards to Launchers, they should not supply a text at all, but only a label, no value or suffix.
This method is quite logical and fits right. With regards to coding it, launchers and data sources both require the "type" feild to be set, so it shouldn't be too taxing to check a few table values :)
Granted this will require some recoding in display addons, but it would solve this label war, as yess has put it.
Vezzilus, considering it's his Lib that we're talking about.. he's got the place to say what the intended method is and isn't.. that doesn't prevent the actions of others, but simply gives them a fundamental to gauge their addons from.
where type is the style of options, a drop down would require a anchoring frame where a dialouge would not. The AppName ofcourse would be the registered name that you setup when you registered your option table. The Display would then just do a call to the ConfigRegistry:Open(AppName) and end there. For a dropdown you'd need to provide the anoring frame, prolly the display's main frame for that ldb block. If set as a func, then the app field would be passed along with an anchoring frame, like a tooltip :D
Do what i do Arkayenro. Make a folder called ~/WoWAceSVN or what ever, then check out the entire lib repo into it's own folder from there. All the repo locations are on the project pages. Then cross-reference where the tag is.
Now now, lets not complicate things by yet another layer.
To me, I believe that nothing needs to change at all. Any/all display addons should be able to control which feeds to show/hide and store this within the display addon. Should the user use more than one display addon, then the flexibility to launch an addon from multiple locations (i.e be displayed in 2 or more displays) can possibly be what the user wants, otherwise why run 2 displays?
The problem doesn't lie with LibDBIcons-1.0's implementation either, the addon that is including LibDBIcons should be providing the show/hide mechanism directly.
my 2c, for what it's not worth...
The ."WhoIsDisplayingMe" attrib should be added simply for the sake of completeness. It is part of the system that something pick the feed up and do something with it, this thing should tell the registry that it has it. It can be as simple as a comma seperated list where the value is the global object for the display addon or at worst a soft name for the display addon.
While it should not be an enfoced spec for the display addons, nor the lib, Authors should be advised and encouraged to follow a common convention with LibDBIcons-1.0 so that if their LDB object does get's picked up that the MiniMap icon via LDBI dosn't get enabled by default.
I think this is a happy middle ground that can be worked with.