GroupFu provides data, it's not a launcher... it just has an onclick action as well. Simplest way to tell if it's a launcher: did the author pull in FBP and all those libs just to get a minimap button that opens a panel? That's a launcher!
It only provides an icon? I vaguely recall FBP allowing a "hasNoText" setting that was essentially meant for launchers. However I bet there will be a metric assload of exceptions, so you might just want to hardcode a list of plugin names that don't provide data.
Docs have been updated with some more bits in the spec, and example of how to provide data to an LDB dataobject. Docs on using LDB data might happen tomorrow, if I'm up to it... we'll see.
Anyone who has a display addon in the works (or done) let me know the name and a link, and I'll get it added into the LDB readme. I doubt I'll try to keep a list of the plugins, but I'd like to at least provide links to displays so people can find them easily.
Also, I've pushed up the first of my data source addons, picoFPS. I'll be converting the rest of my old Blocks soon (okey so they're already converted, I just need to rename them, get the additional info added in, and push them to github). I also have my display, tekBlocks, that I guess I'll push up, though I doubt I'll ever put out a "real" release of it, since I don't plan on having any customization options there.
These would be features for the display addon, I suppose...
Hide tooltip in combat
Font face, size, color
Aye, those would all be implemented by the display, they wouldn't matter at all to the plugins. Well, if the plugin is using OnEnter/OnLeave to do it's tooltip, it would have to handle the combat thing itself, but that's certainly not hard to do.
Quote from Zidomo »
The single feature of FuBar plugins (as opposed to FuBar itself) I use time and again, if they provide it: interactive tooltip menus provided by Dewdrop. They provide Dewdrop menus when they have minimap herpes too, so unrelated to FuBar.
Menus and clickable tooltips would have to be implemented in the plugin using OnClick/OnEnter/OnLeave. There's absolutely no way it can be implemented on the display side without forcing people into using specific libraries or display addons to get those features of the plugin. OnClick/OnEnter/OnLeave is very simple for the display to implement, leaving the complexity of the menus up to the plugin to handle. Which really is how it should be, why should the display load up all that crap on the CHANCE that a plugin might use it?
I will, however, point out that addons that do this should aim to make their menus short and sweet. Put the full blown config in a proper config panel in the UI options, just use your menu for access to the most commonly changed things. For example, ClosetGnome would provide a menu with your outfits in it for swapping, but not any of the other config options.
Having skimmed over the FBP3 API, I don't really see anything else besides tooltiptext that can't be covered with the current spec. But I'm still open to thoughts.
Maybe via some common description of the DO like whether it has static icon/text/tooltip. So in theory it would be even possible to have the user decide on how to group the DOs in the config windows.
That's exactly what "launcher" does. It says "I have NO DATA WHATSOVER, hell I don't even have 'text'". Yes, I agree that the display *could* show these items if it chooses to provide that feature. By labeling them as "launchers" we're grouping them together and saying "these don't provide data" so that data-only displays can ignore them. Besides that, I think StatBlocks ignores any DO that does not provide at least "text", so without specific support added to StatBlocks that whole argument is kinda moot. Still, it's Funky's choice if he wants SB showing launchers, and noone can force him to go either way on that.
As for providing info in the tooltip, that's really up to the plugin addon to decide if it's a "launcher" or not I guess. The intent of "launcher" is to say "I provide no useful data". But then, I don't think I've seen a fubar plugin that provides data in the tooltip only... I'm sure someone will prove me wrong there. Quickie lets the DO override the tooltip if it wants it's own custom one, but other launchers might not do that.
There's nothing that says a display addon can't support both. There's nothing that says you must "lock out" the launchers... it's all up to the display addon!
However, I see no merit to the "it doesn't work on my friend's PC" argument. A user should damn well know what they've installed on their own box, and that unless the EXACT SAME things are installed on his friend's box, he won't have the exact same UI. But then, I also don't care at all about those users so I guess my views on that one don't matter at all.
"It's better to be pissed off than pissed on..." :)
Lets see if I can address everything here...
* 1.1 because 1.0 just kinda sat on the ace svn and stagnated. I wanted to work on it and get it to a useful state, and I don't use svn, and I didn't want to conflict, so I went with 1.1. I could have just as well called it LibTekLikesBalls-1.0 :P
* Oh, I understand. I've been fighting the goddamn things since the days of Titan, I REALLY understand. I totally agree that these days they should just use the config panels. However, people will still want to make minimap herpes, there's no stopping that. So my thought here is, provide something that is smaller and simpler than embedding FBP+libs and maybe, hopefully, people will use it. It can still work with FuBar if someone writes a display addon that does exactly that... I provided what I felt was a much better display than that (I've always loved Auc's Slidebar, just not the way they made it an embed)... and the best part of this implementation is that the user has to "opt in" to get the launchers by installing an addon specifically for them. If you hate the things with a passion, just don't install a display addon and they'll never bug you! If someone doesn't set the launcher field that should, bitch em out. If you want these to show up in statblocks, convince Funky that they should, or write your own display. This whole change is about promoting user choice in how and where they display their stuff, not being forced to use Titan/FuBar/StatBlocks/whatever.
* Man that last one was a rant...
* Putting things in trunk, no comment. However, I DID provide documentation for my stuff, and I gave you guys a link to it. I don't know if you should consider trunk a "public release" or not, but I've not pushed out one of Quickie, and I don't know if I will without further refinement (I'm torn between making it very configurable, or no config at all).
Oh, and re: launchers... there actually are a few launcher-esque plugins out there that I think are good. Like NameToggle and, uh, okey that's the only one I can think of off the top of my head. Still, not every launcher button will open a config, that's just the most common case. We can't force people to stop making them, so why not provide them with a better system that will make many more people happy, not just the "I want a fubar button!" people.
Well then it should be included no matter what, just like LegoBlock is in Fortress. Right now, downloading without externals means that LDB is *not* included.
Someone apparently put LDB-1.1 in the ace svn trunk. It has been removed. As you say, it should be included directly in the addon as a "normal" file. "No externals" downloads should still include the library, because there is no (and will be no) "standalone" version.
...kinda begs the question if there is a need for a .owner type feild to be implemented so that if a user is running both SB and Quickie that the 2 of them don't start displaying the same plugin and taking up screen space? or should it be left to the user to use some brain power to know better.
The user should have the brainpower to not run two addons that do the same thing, or to configure them to display the info they want displayed.
As for format, the data source could set "format", "text1", "text2" ... "textN"... but I think that's going to get messy. It's all to save a little bit of memory with strings, so it's really up to the addon to decide if it's being wasteful. When you consider it's going to have to "waste" the memory for the "text" field... it all seems a little moot. I don't know, maybe it's just me, but I don't see the memory savings here to be worth the extra bits (which might actually overcome those savings). *shrug* my aim is to keep things super simple and super small.