Our records show that you have outstanding author rewards points. Please confirm your latest payment information and redeem your points balance via the Author Reward Store.
Has there been any answer to this question yet that I missed?
Perhaps explain a bit why a DO must be unregistered, meaning what exactly do you want to do with this functionality. It is (or it should be imho) the display's job to handle hiding/showing or even enabling/disabling.
I'm currently doing a Broker addon for display of the character skills, and tradeskill cooldown of all the characters on the realm.
What I would like to know is how can I create a tooltip with categories that can be shown or hided with a + / - button
(Sorry if this is not very clear English is not my first language)
Using LibSimpleFrame-1.0 I have been abble to make a clickable frame that is working as I wish expect that it is not attached to the icon of my ldb object, any idea how I can attach it to the icon?
Well lets say you have a mod that has a fubar and LDB plugin and they for some strange reason have both running and want to turn one of them off. Not a big issue it works now just have to reloadui to get rid of the frame but the fubar one disappears immediately.
I'm currently doing a Broker addon for display of the character skills, and tradeskill cooldown of all the characters on the realm.
What I would like to know is how can I create a tooltip with categories that can be shown or hided with a + / - button
(Sorry if this is not very clear English is not my first language)
IIRC, clickable tooltips were given the thumbs-down by tekkub, the LDB author, and there's currently no implementation of it.
Of course, that could've changed.. I've only recently come back to wow, after a 3month hiatus, when I left, LDB was still just a library in */branches :)
The 1.1 spec is kinda broken, and while some addons uses .label, .suffix and .value, Vharr just made me realize it is kind of silly the spec doesn't describe in exactly what situations they should be used, and how the displays should act if some of the values are present and others not.
I think it should started over, and that we should think long and hard if we even needed anything but .text. The problem right now is that you have no idea how your display is going to look if you use anything but .text.
Making the specs a little clearer would be really nice, because if you try and discuss how the spec is meant to be used right now it will most likely get you killed violently by club death. I hope somebody feels like discussing this without it ending in a huge flame war, because else the spec is just going to stay broken.
I agree some kind of consensus would be great. I for one would be in favour of dropping .text -since that seems to be the part that's open for interpretation- and go for something 'mathematic' and therefore less prone to confusion like this:
.Name (the name)
.Type (launcher/datafeed)
.Variable (The Variable)
.Value (The value, wich can be text of course)
.Unit (The unit in which the Value is given)
To me that seems kind of fool proof, but I'm sure some will see it differently :)
Anyways, I don't mind how it's done, but some kind of logical commonly accepted structure would be nice, because at the moment, there doesn't seem to be one.
"Broken" is a bit of a harsh/bold statement. Broken implies that are serious issues with it, plugins don't work as intended by their authors etc, which isn't really the case. Most if not all displays have minor issues (if any at all) and do what are expected to do.
I agree that having 3 attributes for basically a text value is a bit overboard but other than that most things are kept within reasonable limits.
Vharr just made me realize it is kind of silly the spec doesn't describe in exactly what situations they should be used, and how the displays should act if some of the values are present and others not.
Should it need to ? For instance it's pretty clear (to me at least) that let's say suffix and value are meant to be used together on a single, concatenated string. You may call it subjective from a certain point of view but really how many ways are there. Label is entirely optional and mostly applies to data sources. If you are starting to set "hard" boundaries on the spec, then we basically go back to the problems of the past, one display will eventually emerge "to rule them all". Although theoretically people would be able to create their own implementations, very few would bother because the users would have no compelling reason to use it over something already "complete". At least so far, displays seem to be almost equally divided amongst the general population, which is a good thing imo.
The problem right now is that you have no idea how your display is going to look if you use anything but .text.
That's the beauty of it. You don't really need to ! You basically set your attributes and pass the ball to the display, to render them however it likes to. I'm not saying its the best solution in the history but it is a working solution so far.
if you try and discuss how the spec is meant to be used right now it will most likely get you killed violently by club death.
I would assume that it was meant to be used, roughly as described in the wiki. I personally like it though, that most of the stuff are recommendations or "best practices", rather than something entirely restricting. That being said, I think most of the people here would be very interested in hearing your opinion, on a possible spec "refinement". At least I promise not to pull my club out prematurely :p:p
My main gripe atm with LDB (which really emerged through testing) isn't really anything related to the text but rather related to tooltip handling. I believe that there should be a way to make it easier on the authors to implement and handle a dynamically updated tooltip (something that you andreas brought up some time ago), perhaps an extra attribure/script handler we can (ab)use.
You're welcome to debate the specs all you want, nothing is set in stone. The deciding factor isn't if the spec is "official" or not, it's if display addons implement them. The reason that .text is the only required value is, while some of you might see need for all these other values like label and suffix, others of us don't. I, for example, only implement icon, text, and basic tooltips in my display. You simply cannot expect the display to handle all your fancy stuffs... but you could use those fancy bits to try to win users for your display.
In short, it's all open really, but the minute things become required we're opening ourselves up to the wonderful world of feature creep... Advanced designs are possible and welcome, just never forget the simplest use-case here... the basic text display.
The problem here is consistency, because for example Fortress and StatBlockCore can customize the color of suffix. But if someone creates a fps display that doesn't use suffix, it will just be plain white (or even a third color if the display puts a color in the string). This is quite confusing for the users?
And what happens if you set .text, .label, .value, and .suffix? The display feed author doesn't know if they're shown at the same time or not, so some displays could show that as "100fps 100fps", because the spec doesn't say how to implement them.
Not really that confusing. If users care about the color of the suffix, they will opt for Fortress, SBC, if not they will go with w/e just shows it.
If the author of the plugin sets all the attributes (which he shouldn't need to in the first place), then obviously the display needs to set some sort of priorities from scratch, for instance SBC uses this priority : show suffix + value if at least suffix exists, if not then show text (if it exists) which has some basic logic really. As for the label you can simply check if its identical to the text and if yes, simply show one of the two (I would opt for the one that can be optionally hidden, to help users that may simply want an icon). There are obviously other many cases of "overlap", meaning cases where attributes can be the same. It's really up to the plugin author to ensure that this doesn't happen or kept to a minimum.
whats that supposed to mean Tekkub?
Maybe an .enabled or .shown field should be added.
Perhaps explain a bit why a DO must be unregistered, meaning what exactly do you want to do with this functionality. It is (or it should be imho) the display's job to handle hiding/showing or even enabling/disabling.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumUsing LibSimpleFrame-1.0 I have been abble to make a clickable frame that is working as I wish expect that it is not attached to the icon of my ldb object, any idea how I can attach it to the icon?
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse Premiumlike if you have an addon with ldb that is only enabled while in a raid so it can hide itself when you leave the raid.
Or a DO for showing guild members online, to be disabled when not in a guild.
why would you show it in the first place on login when you are not in a guild? or how often do you leave a guild so that this would happen ? :)
IIRC, clickable tooltips were given the thumbs-down by tekkub, the LDB author, and there's currently no implementation of it.
Of course, that could've changed.. I've only recently come back to wow, after a 3month hiatus, when I left, LDB was still just a library in */branches :)
But yes, personally I highly discourage them.
-
View User Profile
-
View Posts
-
Send Message
Project Authorhttp://github.com/tekkub/libdatabroker-1-1/wikis
I think it should started over, and that we should think long and hard if we even needed anything but .text. The problem right now is that you have no idea how your display is going to look if you use anything but .text.
Making the specs a little clearer would be really nice, because if you try and discuss how the spec is meant to be used right now it will most likely get you killed violently by club death. I hope somebody feels like discussing this without it ending in a huge flame war, because else the spec is just going to stay broken.
.Name (the name)
.Type (launcher/datafeed)
.Variable (The Variable)
.Value (The value, wich can be text of course)
.Unit (The unit in which the Value is given)
An example would then be:
.Name = Broker_Groceries
.Type = Datafeed
.Variable = Ham
.Value = 200
.Unit = Grams
To me that seems kind of fool proof, but I'm sure some will see it differently :)
Anyways, I don't mind how it's done, but some kind of logical commonly accepted structure would be nice, because at the moment, there doesn't seem to be one.
I agree that having 3 attributes for basically a text value is a bit overboard but other than that most things are kept within reasonable limits.
Should it need to ? For instance it's pretty clear (to me at least) that let's say suffix and value are meant to be used together on a single, concatenated string. You may call it subjective from a certain point of view but really how many ways are there. Label is entirely optional and mostly applies to data sources. If you are starting to set "hard" boundaries on the spec, then we basically go back to the problems of the past, one display will eventually emerge "to rule them all". Although theoretically people would be able to create their own implementations, very few would bother because the users would have no compelling reason to use it over something already "complete". At least so far, displays seem to be almost equally divided amongst the general population, which is a good thing imo.
That's the beauty of it. You don't really need to ! You basically set your attributes and pass the ball to the display, to render them however it likes to. I'm not saying its the best solution in the history but it is a working solution so far.
I would assume that it was meant to be used, roughly as described in the wiki. I personally like it though, that most of the stuff are recommendations or "best practices", rather than something entirely restricting. That being said, I think most of the people here would be very interested in hearing your opinion, on a possible spec "refinement". At least I promise not to pull my club out prematurely :p:p
My main gripe atm with LDB (which really emerged through testing) isn't really anything related to the text but rather related to tooltip handling. I believe that there should be a way to make it easier on the authors to implement and handle a dynamically updated tooltip (something that you andreas brought up some time ago), perhaps an extra attribure/script handler we can (ab)use.
In short, it's all open really, but the minute things become required we're opening ourselves up to the wonderful world of feature creep... Advanced designs are possible and welcome, just never forget the simplest use-case here... the basic text display.
And what happens if you set .text, .label, .value, and .suffix? The display feed author doesn't know if they're shown at the same time or not, so some displays could show that as "100fps 100fps", because the spec doesn't say how to implement them.
If the author of the plugin sets all the attributes (which he shouldn't need to in the first place), then obviously the display needs to set some sort of priorities from scratch, for instance SBC uses this priority : show suffix + value if at least suffix exists, if not then show text (if it exists) which has some basic logic really. As for the label you can simply check if its identical to the text and if yes, simply show one of the two (I would opt for the one that can be optionally hidden, to help users that may simply want an icon). There are obviously other many cases of "overlap", meaning cases where attributes can be the same. It's really up to the plugin author to ensure that this doesn't happen or kept to a minimum.