When I was testing the implementation I do remember of at least one case where .text was provided and no .label. And no, it wasn't Prat :p In all honesty, I don't remember which plugin it was (it was surely hosted on WoWI, I do remember that much).
As for the rest, well the open spec is both a blessing and a curse. Blessing because plugin authors have far too many choices (though realistically speaking they will try to implement something that "plays nice" with most if not all displays) and a curse because the display authors need to find a way to provide a consistent display, preferably without being intrusive on the code provided by plugin authors and trust me it's not easy. Sometimes you are either forced to implement hackish stuff or simply "sacrifice" a feature to keep everyone happy.
And if you think that's bad enough, you are going to love the following "exceptions" :
1) What happens if .launcher is provided but no .label (or .text) and you have an option to display label ? Do you disable the option or revert to the DO name ? (I chose the later). There is no clear guideline.
2) What happens if a DO does not provide .text on load (after registration) but sets .text after let's say a timed event ? (yep it does exist) Answer : You probably need to register a callback anyway :p
3) What about plugins that can "write" to .label and alter it depending on their functionality as stated in the "Extension or Deviations of Data Source and Launcher" ? Again you probably need a callback anyway (I haven't even bothered with this case, as I have no practical experience) to change the .label according to what the DO dictates.
I have tried to simplify the .label situation a while back and all I got is the alteration of it on the Wiki.
Yes there are DOs that do not provide .label simply because the standard doesn't demand it! Displays per standard should use the DOs name in this case, it's not clear what that means for localization though. And it certainly is at odds with any .text -> .label heuristics if .label is empty. And it's at odds with the practice of label editing.
I have tried to point out that the .label definition is at the core of confusions but all one gets is called endless discusser for trying :P
I wish .label was just mandatory and always be the primary descriptive label of the DO per definition, expected to be localized by the DO. .text is any extra data after the descriptive label per definition and should not be used to label the DO ever.
This is pretty close to the standard but yes there is a lot of confusion and deviation.
As far as I am concerned there should be no ambiguity about this, really there is no need. All any confusion does here is cause these irresolvable messes of trying to cover any case.
As far as I am concerned there should be no ambiguity about this, really there is no need. All any confusion does here is cause these irresolvable messes of trying to cover any case.
Label is not required. If you want a label and the DO doesn't provide one, then use the DO name. There's no ambiguity there at all, DOs don't *need* a label, so it's not required. It's that simple.
If it was required, the DOs that don't provide one currently would end up simply copy/pasting their name into that field. That doesn't solve any of the issues you mention.
Label is not required. If you want a label and the DO doesn't provide one, then use the DO name. There's no ambiguity there at all, DOs don't *need* a label, so it's not required. It's that simple.
If it was required, the DOs that don't provide one currently would end up simply copy/pasting their name into that field. That doesn't solve any of the issues you mention.
You don't tell me anything I don't know. I know that you want that DOs should not *need* a label, but what are the consequences of that choice.
But lets look beyond personal preference at the consequences:
1) How about localization? Does the display now have to figure out how to localize the name?
2) How about the issue that the fact that labels can not be present causes confusion for displays how to handle .text fields as discussed above by a few people and causes confusion for DO authors how to do things as well?
3) How about label editing?
Wait I already know "the answers":
1) It's moot because the DO doesn't have to provide a label and the display only "may" but is not required to pick the name either. If the DO doesn't provide a label we simply don't care about localization. That it may create incoherend displays (with some labels present and some missing) is bad luck.
2) People should just follow what's written or make up their own shite.
3) I don't need it so I don't care.
Also people endlessly discuss...
Right?
Here is how .label being require solves things:
1) Localization is always present and with the DO.
2) The meaning of .text vs .label is absolutely clear and there is never any special case in code to handle .label (see Tristanian list of special case handlings for what the reality is). There is no need for conditional code to handle this case anymore, by standard or by practicality.
3) It's possible if you don't care that's fine. If you do care it's fine too!
So don't give me that crap that this doesn't solve anything. It's true that it doesn't improve anything on what you personally want. But it improves things for a few of the rest of us.
P.S. I'm a tab person, or rather I'm an "editor that's smart enough to format nicely for me and don't care if it's tab or space under the hood" person.
1) Localization is totally the DO's problem, label or not. The display can't make up for a DO that provide a label but doesn't loaclize it.
2) Yes, people SHOULD follow the spec. The spec says that .label is the title, why is there confusion that .text ISN'T the title?
3) No, I don't need it and don't care. If a display chooses to implement that, then they are choosing to go beyond the spec and do something that's it's been recommended they don't do.
Seriously, this runaround got old months ago. If you don't like the spec and want something more TAKE MATTERS INTO YOUR OWN HANDS AND IMPLEMENT WHAT YOU WANT. That's what I did with LDB, and I'll be damned if I'm going to take shit about my design decisions. The whole damn spec system is open for this exact reason.
1) Localization is totally the DO's problem, label or not. The display can't make up for a DO that provide a label but doesn't loaclize it.
Don't twist the case. The case I mention is if _per your rule_ the DO doesn't provide a label and hence the name is taken, not a label not being localized. But nevermind.
2) Yes, people SHOULD follow the spec. The spec says that .label is the title, why is there confusion that .text ISN'T the title?
It's confusing because the label can be missing which is obviously unintuitive for both display and DO authors if you actually read the thread.
3) No, I don't need it and don't care. If a display chooses to implement that, then they are choosing to go beyond the spec and do something that's it's been recommended they don't do.
Yep I got that one right...
Seriously, this runaround got old months ago. If you don't like the spec and want something more TAKE MATTERS INTO YOUR OWN HANDS AND IMPLEMENT WHAT YOU WANT. That's what I did with LDB, and I'll be damned if I'm going to take shit about my design decisions. The whole damn spec system is open for this exact reason.
Yep, this stonewalling got old months ago too. I'm not going to take this shit anymore either. The spec system is not open, but we don't need to have that discussion. But I appreciate the suggestion and I'll go ahead with this. I'll start a new thread when I'm ready. Thanks for your suggestion.
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.
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?
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?
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.
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).
I do dislike the single-output limitation of LibSink.
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.
The problem is that unless you funnel it through LibSink (thus gaining little to nothing over just using LibSink directly), you'll have to educate and convince every scrolling text author to act as an LDB display for this new data type, plus you'll have to implement some kind of wrapper addon to support everything else LibSink can use as an output that is part of the default UI (as if they were LDB displays). Otherwise you'll have, as you say, market penetration issues.
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.
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.
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.
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.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
As for the rest, well the open spec is both a blessing and a curse. Blessing because plugin authors have far too many choices (though realistically speaking they will try to implement something that "plays nice" with most if not all displays) and a curse because the display authors need to find a way to provide a consistent display, preferably without being intrusive on the code provided by plugin authors and trust me it's not easy. Sometimes you are either forced to implement hackish stuff or simply "sacrifice" a feature to keep everyone happy.
1) What happens if .launcher is provided but no .label (or .text) and you have an option to display label ? Do you disable the option or revert to the DO name ? (I chose the later). There is no clear guideline.
2) What happens if a DO does not provide .text on load (after registration) but sets .text after let's say a timed event ? (yep it does exist) Answer : You probably need to register a callback anyway :p
3) What about plugins that can "write" to .label and alter it depending on their functionality as stated in the "Extension or Deviations of Data Source and Launcher" ? Again you probably need a callback anyway (I haven't even bothered with this case, as I have no practical experience) to change the .label according to what the DO dictates.
Yes there are DOs that do not provide .label simply because the standard doesn't demand it! Displays per standard should use the DOs name in this case, it's not clear what that means for localization though. And it certainly is at odds with any .text -> .label heuristics if .label is empty. And it's at odds with the practice of label editing.
I have tried to point out that the .label definition is at the core of confusions but all one gets is called endless discusser for trying :P
I wish .label was just mandatory and always be the primary descriptive label of the DO per definition, expected to be localized by the DO. .text is any extra data after the descriptive label per definition and should not be used to label the DO ever.
This is pretty close to the standard but yes there is a lot of confusion and deviation.
As far as I am concerned there should be no ambiguity about this, really there is no need. All any confusion does here is cause these irresolvable messes of trying to cover any case.
Label is not required. If you want a label and the DO doesn't provide one, then use the DO name. There's no ambiguity there at all, DOs don't *need* a label, so it's not required. It's that simple.
If it was required, the DOs that don't provide one currently would end up simply copy/pasting their name into that field. That doesn't solve any of the issues you mention.
This label vs text thing has become like spaces vs tabs. (spaces are better)
You don't tell me anything I don't know. I know that you want that DOs should not *need* a label, but what are the consequences of that choice.
But lets look beyond personal preference at the consequences:
1) How about localization? Does the display now have to figure out how to localize the name?
2) How about the issue that the fact that labels can not be present causes confusion for displays how to handle .text fields as discussed above by a few people and causes confusion for DO authors how to do things as well?
3) How about label editing?
Wait I already know "the answers":
1) It's moot because the DO doesn't have to provide a label and the display only "may" but is not required to pick the name either. If the DO doesn't provide a label we simply don't care about localization. That it may create incoherend displays (with some labels present and some missing) is bad luck.
2) People should just follow what's written or make up their own shite.
3) I don't need it so I don't care.
Also people endlessly discuss...
Right?
Here is how .label being require solves things:
1) Localization is always present and with the DO.
2) The meaning of .text vs .label is absolutely clear and there is never any special case in code to handle .label (see Tristanian list of special case handlings for what the reality is). There is no need for conditional code to handle this case anymore, by standard or by practicality.
3) It's possible if you don't care that's fine. If you do care it's fine too!
So don't give me that crap that this doesn't solve anything. It's true that it doesn't improve anything on what you personally want. But it improves things for a few of the rest of us.
P.S. I'm a tab person, or rather I'm an "editor that's smart enough to format nicely for me and don't care if it's tab or space under the hood" person.
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.
2) Yes, people SHOULD follow the spec. The spec says that .label is the title, why is there confusion that .text ISN'T the title?
3) No, I don't need it and don't care. If a display chooses to implement that, then they are choosing to go beyond the spec and do something that's it's been recommended they don't do.
Seriously, this runaround got old months ago. If you don't like the spec and want something more TAKE MATTERS INTO YOUR OWN HANDS AND IMPLEMENT WHAT YOU WANT. That's what I did with LDB, and I'll be damned if I'm going to take shit about my design decisions. The whole damn spec system is open for this exact reason.
Don't twist the case. The case I mention is if _per your rule_ the DO doesn't provide a label and hence the name is taken, not a label not being localized. But nevermind.
It's confusing because the label can be missing which is obviously unintuitive for both display and DO authors if you actually read the thread.
Yep I got that one right...
Yep, this stonewalling got old months ago too. I'm not going to take this shit anymore either. The spec system is not open, but we don't need to have that discussion. But I appreciate the suggestion and I'll go ahead with this. I'll start a new thread when I'm ready. Thanks for your suggestion.
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 :
Missing boolean members evaluates to false, as usual.
This is intended to be used that way:
Any thought ?
Oh. I wasn't clear enough. Think about the areas of SCT, MSBT, Blizzard's Floating Combat Text, etc...
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?
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.
I do dislike the single-output limitation of LibSink.
The problem is that unless you funnel it through LibSink (thus gaining little to nothing over just using LibSink directly), you'll have to educate and convince every scrolling text author to act as an LDB display for this new data type, plus you'll have to implement some kind of wrapper addon to support everything else LibSink can use as an output that is part of the default UI (as if they were LDB displays). Otherwise you'll have, as you say, market penetration issues.
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.
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.
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.