Authors CurseForge

Going back and reading the thread and reading my own posts I had forgotten I'd made was fun.

This label vs text thing has become like spaces vs tabs. (spaces are better)

I feel like this is the big fight at the xmas dinner table. Every so often we get together and push each others buttons.

I do think the spec is really something that view authors should be contributing to more actively.

Unfortunately the only person who really would have a vested interest is someone who writes both a display addon and data objects.

Ckk is supposed to be supporting LDB in an upcoming FuBar release. That at least should stir the pot some.

Just got an example of alternate dataobject spec, which may turn unusable because of market penetration issues.

The idea is to publish text scrolling areas through LDB, so any addon could just enumerate them whatever addons are installed. There should be one dataobject by scrolling area, following this spec :

do = {
  type = 'text scrolling area', -- mandatory
  label = 'Bla', -- mandatory, user-friendly name of the area
  isEnabled = true or false, -- optional, is the area enabled ?
  hasSticky = true or false, -- optional, does the area honors sticky flags ?
  showsColor = true or false, -- optional, does the area honors color values ?
  showsIcon = true or false, -- optional, does the area shows icons ?
  Pour = function(self, message, r, g, b, a, sticky, iconTexture) -- Mandatory
    -- Display the given message in the area.
    --   self : mandatory, the scroll area dataobject
    --   message : mandatory, string, the message to display
    --   r, g, b, a : optional, numbers, color and alpha
    --   sticky : optioanl, boolean
    --   iconTexture : optional, string, full path to a texture to be displayed as an icon
    -- This is the area provider responsability to check if the area is enabled or not
  end,
}

Missing boolean members evaluates to false, as usual.

This is intended to be used that way:

local area = GetScrollingAreaDO(someName)
area:Pour("MyMessage", 1, 1, 0, 1, false) -- send a non-sticky, yellow message without icon.

Any thought ?

Quote from Torhal

I thought it would be clearer after I'd gotten some sleep, but I just can't seem to translate your spec into a tangible idea. Is it a scrolling area as in the manner of left-right scrolling text?

Oh. I wasn't clear enough. Think about the areas of SCT, MSBT, Blizzard's Floating Combat Text, etc...

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?

Quote from HunterZ

How is that better than LibSink?

That's what I meant by "which may turn unusable because of market penetration issues" in my post.

There is already LibSink, which does a bit more (like configuration options and storage) to the cost of less flexibility (only one output can be selected).

Moreover, it requires one less library, and as lots of addon provides/uses LDB, it has a very light overhead. It would not be to hard to have libsink support it.

Quote from yess

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.

Quote from HunterZ

Also, I'm not quite sure I'm understanding what you originally posted, but it sounds like a one-scroll-area-per-DO is being proposed. This would be a really, really bad limitation (kind of mirroring the current LibSink limitation, in a way). These scrolling text plugins would have to be able to share scroll areas just like LibSink lets you do, or else you'd never be able to use more than a couple addons that provide that DO type before your screen gets too cluttered.

Let's call :
- providers: code (addons) that handle the display (like SCT, MSBT) and would create the DO,
- clients: code (addons) that have messages to display.

Several clients could send text to the same DO, like LibSink actually allows, or even send the text to all of them.

By example, say the provider MyScrollingTexts defines 3 scrolling area : Incoming, Outgoing, Alert. It exports 3 DO, probably named "MyScrollingTexts-Incoming", "MyScrollingTexts-Outgoing", "MyScrollingTexts-Alert".

Any client can then iterate the LDB dataobjects, looking for these objects. And then present a list to the user so he could choose one or several of them as the client output.

I threw in a basic sample client : http://paste.wowace.com/x60lp89u7j3ycwhd/

You can have a client that sends to multiple areas with very few changes.

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.