Authors CurseForge

A title for your feed, often shown to the left of the text, user might choose to hide this. If missing, the dataobject’s name may be used instead.

I don't know what could be much clearer than "A title"...

.label is a fixed string that describes your data object. For Broker_Garbage, the .label is "Garbage".

.text is a string that contains the actual data from your data object. For Broker_Garbage, the .text is the name of the current lowest-value item in your bag.

Plugins that use .label for their data object's data, or put their data object's label/title in the .text field, are doing it wrong. Plain and simple.

Displays should not treat .label and .text the same way. For data objects, .text is the data -- it's the most important thing to display. .label is an extra descriptive field that may help the user put the data in context, but should never be used for actual data, and thus is peripheral to the data object's primary function, and thus is not necessary to display.

.text is the only required field, it always has been. If you can't wrap your head around all the optional shit, don't use them. They were added by people that think they needed extra crap. .text is the only thing you can rely on every display handling correctly.

This is EXACTLY why I think status bars should be their own spec.

Quote from OrionShock

however how does .value play into this?

I have no idea, as I've never seen a plugin that provided a .value. Considering the name, I'd assume it is simply a wrongly named .text, and would expect it to be ignored by most displays.

Quote from Partha1

Well the plugin would still be a "source" of "data" for the display, whether it was displayed as text or a bar.

While logically you could consider the type of data conveyed by a status bar to be a "data source", implementation-wise it's just asking for trouble to ask displays to display some "data source" objects as a simple text string, and others as a status bar.

It may have been a poor choice to use a name as generic as "data source", but when that name was chosen, it was (IIRC) chosen to contrast with "launcher".

Quote from Partha1

The idea I had was to include everything from the current "data source" spec, just add the statusbar part. To make just a status bar spec without the parts already in the "data source" spec would be of no interest to me at all. Hence, what we are doing really is just adding to the current spec.

By the same logic, you could argue that the "data source" spec shouldn't exist at all because it includes everything from the current "launcher" spec and really just adds to the current "launcher" spec.

There's no reason that a new "statusbar" spec can't borrow from the "data source" spec.

Quote from Partha1

Might not be hard, but I wouldn't do it, I'd just tell people to get a better display. I think it would be very messy, not to mention that displays that support both would now have two entries for each plugin. ...
They either support statusbars or they don't, the user most likely wouldn't even know what a spec is.

Why would a display that supported both "data source" and "statusbar" have two entries for a "statusbar" plugin?

Users already know that there is a difference between a "data source" (a plugin that shows information) and a "launcher" (a plugin that doesn't show any information, and usually just provides a shortcut to it's parent addon's configuration).

Furthermore, if your data object is intended to be rendered as a statusbar (or in some other way that conveys progress along a range), why would you want to cripple it by either (a) providing a second data object with less but otherwise identical information, or (b) having a display that doesn't understand the statusbar stuff render only some parts of your data?

Quote from Partha1

Problem is, I would want it to display both, the bar and the text. Also the text would mostly be far more complex than the simple "current / max" text I put in that sample XP bar.

How does providing a min, max, and current value stop you from also providing a text? Providing those values in an unambiguous way means that displays can meaningfully represent your data in a variety of ways -- either as a statusbar, or as a cooldown spiral (as was suggested by someone else), or as an "ASCII statusbar", or as a color gradient, or in some other way nobody in this thread has through of yet.

Displays should not have to guess whether a "data source" should, or can, be rendered as a status bar. No matter what you do, you're going to have to get display addon authors to add code to render data objects as status bars, so why not make it less of a pain in the ass by making it unambiguous?

Additionally, by defining a separate spec for objects that should be rendered as statusbars, you make it simple for displays to use alternative visual presentations. Others have already mentioned icon cooldown spiral. Another possibility would be the sort of "ASCII status bar" that a few plugins already provide.

By not defining it as a separate spec, all you accomplish is:

• more work for display authors, since they now have to use heuristics to guess how your data object is supposed to be rendered.
• 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!").
• a poorer experience for users, since displays that don't support statusbars will only display parts of your data object.

On the other hand, if you define a separate spec, then:

• display authors can simply add support for the new spec as it was intended to be supported.
• 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.
• you don't have to duplicate data, or compromise the way you provide data, to accommodate displays that don't include the necessary code to heuristically differentiate your data object from others that are intended to be displayed with only text.

All this confusion caused by the tacked-on shit in the data source spec... I might just rewrite the damn spec docs to clear this shit up. Stupid wikis, starting to dislike them. Ugh.

Quote from Elkano

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...

As a user, I'd much rather have an addon just not work at all, than have it only work halfway. As an author, I'd much rather that my plugin simply wasn't displayed, than have it butchered by a display that didn't understand half of it.

Plus, having a separate spec means that, assuming there is sufficient user interest in data objects using your spec, there is more pressure on display authors to add real support rather than just letting things slide with partial support.

Quote from Elkano

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

As with "data source," there is probably a better name that could be used. Let's stop calling it "statusbar," and call it "range" or something instead.

Quote from Elkano

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.

Well, with launchers and data sources, you can think of the type as answering the question: "what is the highest level of functionality this object provides?"

Launchers provide very little. Data sources provide everything that launchers provide, plus some more. A new range spec could provide everything that data sources provide, plus some more.

Essentially what is emerging is a heirarchy of increasingly complex/specific object types, and this is a good thing. It means that data objects can provide all kinds of information, and their authors don't have to worry about displays that don't support that level of complexity/specificity neutering their data object.

Quote from Elkano

how it is intended to be used and not how people using it screw up (eg the .label stuff).

I don't see anything wrong with .label; separating the static label from the dynamic data is not only semantically sensible, but practical too.

If there was no label attribute, then in order to turn off those space-wasting titles, I'd have to wade through the separate options menus of 20 different addons and turn them off individually -- if the addon's author even bothered to put in the option to turn it off. Likewise, someone who had space and wanted to see titles would have to wade through 20 different menus to turn them on -- again, if the author bothered to provide them.

Having the label separate means that it's a simple matter for me to tell my display "don't show labels", and equally easy for someone else to tell their display "do show labels".

Quote from myrroddin

/derails current train of thought\
Is it still preferred to have LDB-1.1 embedded, and make it non-"nolib"? In the .pkgmeta I am using Tools-Used since that was on the info page, and I made sure my .toc no-lib section does not include LDB.

Yes. As Tekkub has stated on multiple occasions, there is not, and will never be, a standalone version of LibDataBroker-1.1. You should always hard-embed it, and make sure references to it aren't stripped for no-lib versions.

Somebody had the idea of a comma separated list of specs (I can't find the post at the moment), I think that quite a good idea.

How about something like this:

A basic broker looks has the following form:

{
    type = "extended", -- or something else, just for compatibility
    specs = <string>, -- comma separated list of specs
  
    label = <string>, -- I think every broker could use a label
}

The specs show what sort of information the broker is offering. They could be for example:

text = {
    text = <string>,
}

value = {
    value = <string>,
    suffix = <string>,
}

tooltip = {
    OnEnter = <function ()>,
    OnLeave = <function ()>,
        
    tooltip = <frame>,

    tooltiptext = <string>,
    
    OnTooltipShow = <function (tooltip)>,
}

range = {
    min = <number>,
    max = <number>,
    value = <numer>,
}

icon = {
    icon = <string>,
    
    iconR = <number>,
    iconB = <number>,
    iconG = <number>,
    iconCoords = <table>,
}

action = {
    OnClick = <function (button)>,
}

Some fields of the specs may be optional.

A clock broker would be something like this:

clock = {
    type = "extended",
    specs = "text,icon",
    label = "ExampleClock",

    text = "00:00",

    icon = "Path\\To\\Clock\\Image"
}

A launcher would be

myLauncher = {
    type = "extended",
    specs = "action",
    label = "MyAddonLauncher",

    OnClick = function(btn)
        MyAddon:ShowConfig()
    end,
}

The main advantage of this idea is easy extensibility.

With the old type = "..." system adding something is always the choice between expanding (or bloating) an old type, or creating a new one with the risk of missing something (like tooltips, for the statusbar example).

With specs, something new would be just another spec, that gets implemented by the displays after a while.

There are some disadvantages though.
The spec system misses a clear distinction between what is now called "data source" and "launcher", they would just differ in what specs the use.
And (I think this is the main drawback) it would take some time until all displays and brokers have switched to the new system.
I think, this could be done in a compatible way, supporting the old types for some time but only extend the new system. It would be very important, that all displays make the move to the new system, to allow addon developers to support it without the problem that some displays don't understand their brokers.

Two issues with that plan... every display would have to be updated or risk missing DOs with multiple types. Also, what about key naming conflicts? "text" might be used for different things in different specs... what if a dev wanted to use both.

I'll raise the question again... what is wrong with simply registering multiple DOs? It's not that hard to do, and it's really simple to update them all at the same time in your event handlers.

I've no idea if this is way off as far as design goes, but would some kind of toggle control, to tell displays to show/enable or hide/disable your feed, be reasonable? I have more than one feed in my addon, and they're displayed based on settings. Merging them into a single feed won't be pretty in my case.

Mainly because they all display different tooltip info, which may very well be too much to fit in a single tooltip, not to mention annoying to read. I also prefer for them to have their own proper icons (and labels).