Just as an aside. LibSink isn't really limited to one output. You can embed it multiple times if you want more than on output. Perhaps embed is the wrong term. You can give it multiple storage areas, and add it more than once to your options table.
I've never seen it implemented that way, though, so it's kind of moot from a user viewpoint.
Actually I proposed this because people were, a few pages earlier, in search of DO specs that would be different from existing ones. I think that a good example but I didn't think a moment it would be accepted.
I don't think it's a bad or invalid idea, and I'm not resistant to it. I just want to make sure that if it were implemented, that it would be done right (i.e., become something that I'd find worth using).
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.
What I'm basically doing in Titan when a .text attribute is present is implementing an additional check for .type and .label. If the type equals to launcher and a label is not provided by the DO, then set the label to the .text provided (that is the label in the internal addon table handling the attributes of a plugin and NOT the label on the DO itself).
Are there actually real cases in the wild of launchers that define and populate a .text attribute but not a .label attribute?
I have also had cases where a DO otherwise marked as a "launcher" would provide both a .label and a .text attribute being equal, at which case I'm simply electing to display only one of them (usually the .label since that can be optionally hidden by the display).
It sucks that display authors have to come up with a bunch of heuristic gymnastics in order to attempt to provide a consistent display experience to end users. Herding cats FTL. This should be a red flag that the LDB spec isn't robust enough to make things suitably simple and consistent for display authors, plugin authors, and users. Instead of minimap herpes, we now are seeing a new ecosystem of plugins behaving in weird and inconsistent ways due to a barebones spec that is open to wide interpretation.
"The nice thing about standards is that there are so many to choose from."
In general I think it'd be better if types (data source, laucher, other types) are semantics for expected standard fields, not prohibitives for any other fields. But that's me.
I think that's a terrible approach, because the USER should get some expectation of what the heck the plugin is trying to do based on what type of plugin it claims to be. For example, if the plugin says it's a launcher, then it has no business using the text field for useful data because the user will miss out on that data if the display doesn't support it (and it shouldn't have to since it's not listed in the spec - not that anyone is arguing that point though).
The Prat case was a grey area: it was a launcher that was using the text field for non-important data (a copy of the launcher's name). What I did was ask sylv to consider either removing the use of the text field, or - if he felt the text to be important for the users to see - to change its designation to "data source". I expected the former and he chose the latter, which annoyed other users who had depended on it being designated as a launcher (because that's functionally what it was for the most part).
As for DockingStation, it shouldn't be demonized IMO (if want to demonize something, pick me for instigating the whole thing). The complaining that it does is basically just debug logging of a sanity check (albeit possibly enabled by default) and a way to inform the user that a feature of a specific plugin is not supported - something they really might like to know.
he has to optionaldeps the fews ldb displays ouuta there & f2b/b2f not to optionaldeps ldb which is not standalone, since any ldb displays comes with anything required embedded thats just a waste of space to me to embed ldb everywhere unless you want to usesomething else than displays with but I don't really see what
I'd certainly hope it would be done by a more reliable and extensible method than manually optdepping LDB display addons, since it'd break for anyone who uses one it doesn't know about that loads after it.
I actually talked with Funkydude about this, and he had one thing to say which made total sense: people shouldn't be using a single plugin on multiple displays. (What's the point, really? Do you need to see your FPS in two different locations?)
As Elsia commented, I'm sure someone has or will come up with a valid use case for having a plugin show on multiple displays, so I don't think assuming that noone will ever want to do it (640k should be enough for anybody!) is a good idea.
Sounds like I can just have FuBar2Broker route OnClick events from the LDB display to both the OnClick and OnDoubleClick handlers in the FuBar addon and not bother with trying to catch or emulate OnDoubleClick at all then, because it sounds like it's not likely that any sane addon is going to try to use both for the same mouse button + keyboard modifier combo anyways.
The only downside would be that if double-clicking was the original input event used by the FuBar plugin, it was probably as a safety feature to prevent accidental clicks.