yeah, LDBIcon is a display addon in library form that is shipped with your addon. Your addon provides the SV for storing the settings regarding displaying of its data object (whether to show the icon, position, ...) but that has nothing to do with the data object/LDB itself.
By not defining it as a separate spec, all you accomplish is:
more confusion for users, since your data object will not be displayed in a consistent manner between displays (eg. "addon is broken, doesn't look like the screenshot on the download page, fix plz!").
On the other hand, if you define a separate spec, then:
users are not confused -- if the display they use doesn't support statusbars, this fact is obvious, and they can either switch to a display that does support statusbars, or ask the display's author to add support.
So you think inconsistent display is confusing but not showing up at all (due to the display not supporting it) isn't? ???
They'll go "addon is broken" in both cases I think, maybe even more in the case it doesn't show up...
Also, even if you define a separate spec for statusbar, this doesn't mean it will look the same on all displays supporting that spec, it only means that it's a bit mor obvious that you as addon author want it as a bar (which contrasts to the idea of LDB since you should only be the one providing the data and the user should be the one to choose how to display it).
I personally never really liked the spec stuff in its current form since a LDB-DO can provide the elements of multiple specs at the same time.
So the spec filed should list all specs the DO provides (as bitmap or, to allow easier extension without having to assign flags to specs, as comma separated string). The addon author could than hint with another field that he intended to have his data displayed as bar but the user could still choose otherwise.
I know that my view on the topic may be a bit blurred, seeing mainly how it is intended to be used and not how people using it screw up (eg the .label stuff). That's what you end up as CS student... planning the perfect world first and raging about the users later... ;)
Wouldn't it make more sense to add fields like minValue, currentValue, maxValue to the spec which a display can use for creating a statusbar but for other representations, too? Meaning I wouldn't nail it to the bar representation since a display could also choose to display the data as cooldown on the icon or as simple "currentValue / maxValue" text or such. The color would then also be associated with the data and it's up to the display (or the user configuring it) to choose on how to use it eg for the bar itself or for the text.
Adirelle, I see one big problem in your idea and that's how you use LDB.
LDB's DOs are ment to be used by addons that want some sort of data displayed, not for addons that offer a service. While in theory, it would still work, the two sets of objects should be strictly seperated.
Elsia's suggestion is closer to how LDB is ment to be used though every change fires a callback so there is no way to change both the text and the icon for the new message. The only way to do so would be putting everything inside a subtable and replace the current subtable by thatone, resulting in using at least two additional tables.
Being the one that somehow started the whole LDB stuff, still don't see any attributes as required. The DO comes with a unique name and that's all what is needed in theory.
Marking a DO as being a launcher only is something that can be done by th coder to allow a display to group the available DO's isn't that bad in theory, but there is no clear line one can paint to distinguish between launchers and other DOs.
Some see DOs that also visually represent the status of an addon, eg being in standby or such, still as launchers only where others don't. That can make a difference in where the user would love to have them shown.
But in theory, that's more a problem of the display's coder or the way the user picks the display to use.
The list of specifications should more be seen as a list of how one can expect a display to handle specific attributes in case it does and also as a list of the most common attributes. If a display handles them in a non-standard way, users will most likely switch to another or, if the way it handles it is SOOO great, the other displays will adopt.
wrt what sylvanaar says: if the display decides to complain and you don't like it, blame its coder or drop it. There is no reason why "the spec" should tell the coders to use their brains...
In fact, it wouldn't be the data source doing that.
You would have an addon providing a data source and, besides that, doing other stuff, maybe using the LDB tooltip to provide some options to change the addons behaviour, too.
besides tooltips sucking as you say, I don't think the data addon should handle positioning of the tooltip even if it wants to have control about showing/hiding it, at least as long as there is no common way to position the tooltip sicnce this can easily lead to inconsistent positioning in the same display addon.
Maybe the display could pass a callback to the OnEnter function that can be used to have it position the tooltip.
(I really should test how easy the evil TabletLib can be used together with LDB for clickable tooltips...)
well, let's take my FactionsFu as an example, although there isn't use for the suffix but in theory it could set values. But the display has the form: "<faction>: <rank> - <current reputation>/<max reputation for rank> (<percentage>)"
imho it wouldn't make sense to split that into multiple DOs. And I think this also holds for other addons where the data shown is closely related.
On the other hand, you're trying to get launchers out to reduce the number of DOs shown in config but say that in such cases one should split into multiple DOs which could largely increase the number of DOs.