I'm still not convinved that for my purposes I want the per table write callbacks at all. Typically a data provider (model) reads and populated a range of data, and then one callback would be appropriate, for my purposes callback per write is massive overkill, but I guess it's a case of different needs to begin with.
But even for icon+text blocks I'm not sure if it warrants 2 callbacks if someone refreshes icons and text. Rather I'd write text + icon and then call back to get a refresh. The problem there isn't the callback numbers but more that the addon that will get the callback will likely have to assume that it needs to update the display, and do that twice.
Of course one could bypass this by only registering a callback to a "refresh" entry, but...
Well my example are meant to be sketches that show the principle I've been talking about and they certainly neither want to be model implementation how one ought to do this specifically, or claim that the specific implementation is best.
In essence a lot is completely missing.
So yeah I could/should have used the attributechanged in place of Refresh, but it doesn't change anything in the concept.
Note that my display never changes any data stored, except to "register" a "callback" Refresh. If I replace that with attributechanged it doesn't even "look" as if it does. Don't take this implementation literally, I just wanted to have a quick way for the Display to let the DO know where to call back if a refresh is useful and I wanted to have explicit control the DO to decide when to do the callback (rather than table-implicit handling of the same). One can absolutely do this with a callbackhandler, I just had no time to polish any of this... just tried to get a working example going.
I see very little harm in the way I have implemented this actually except that there is no handle for the callback, so currently it's tricky to safely unregister, but that's details.
I don't understand at all why there is a need to split a DO from another addon that "updates the data". As you see my implementation works as is, there really is no need to separate those, in fact I don't see any benefit from doing so.
I do know that the intention of some with respect to the lib was not full data/display abstraction. The whole point of the example is to illustrate that this is possible regardless, if one loosens certain assumptions.
I actually disagree that this is a special case, rather it's a different approach to standardizing exchangable data interfaces.
The approach here is close to what open sound control (OSC) does for music data exchange (the MIDI successor) in that contributors to the exchange can define their data and provide model implementations. Other implementations can then be made given the now defined interface. This is a widely used method and works sensibly well in practice despite being mostly bottom-up.
And it doesn't proclude a "standard" core at all. I.e. to have a standard defined functionality call very well cohabitate with what I am doing. For example you have fubar, statblock and HUD type displays for your intentions, and you have a model implementation for durability via ArmoredMan and statusbar histogram. People can choose any set of any of these combinations as they see fit. If they want a ArmoredMan with a look that fits statblock they can implement the display without touching anything else.
If kgpanels want to also react to DO data they can too by just grabbing the data.
e.g. a kgpanel can change if durability is low or if repair bills are too high.
There is a lot of stuff currently hardcoded here but this is not necessary nor intended. It grabs DurabilityDO simply because I was too lazy to scan for DOs that provide armory slot information and then letting the user choose if they wanted to link those to the armoredman and if, to what attributes of it. But the design doesn't preclude this at all. All this is display side stuff that can be easily added. I just hadn't had the time to write any kind of user config UI. As said, treat it as a concept mockup not a finished product.
Hacking that scanning in shouldn't take me too long so I'll add that as soon as I get around to it. It wasn't really the concept I felt needed demonstrating.
It is kind of important to note that this is not meant to be hardcoded at all. Hence why I said I wanted to provide multiple DOs and Displays to illustrate the idea. I'll hack up some more DOs to show that the whole point is to not hardcore stuff. There is absolute abstraction in semantics between data and display, and yes if you wanted to map time to armored man pieces, you could, or durability to to anchor positions of statblocks, same.
The only thing that got defined is that there are DOs that will provide data that relate to inventory armor slots. That's all that.
If you look carefully, only those fields (plus the refresh callback) are the points of interaction between DO and displays. Everything else is really flexible, including the choice to even make the connection.
Any display that recognizes these can render that information in any way they want and any DO that decides to provide data for it can do so to be recognized. Hence why you can write a DO that will make the ArmoredMan or statusbar histogram dance without changing a line of code in the latter. Hence ArmoredMan can handle more than one DO, I just haven't gotten around to mock up a second one, but it's trivial to do so (I'll mock one up tonight).
And ArmoredMan as it's currently implemented doesn't support any of the attributes that were discussed so far (well except for .text). This isn't by design, it's mostly because my goal was to illustrate that you can do other things too. Certainly one can embed the current ArmoredManDisplay easily in a tooltip and have it live quite happily in a mouseover tooltip interaction. Just that the way it's currently written it doesn't have to be that way and it can also show up elsewhere.
There is a rather big issue of language confusion. Because what Elk calls DO isn't a DO in my case. And what I call display is often what Elk calls a DO. So it's tricky. I have tried to work around this by calling my DOs "pure" DOs (i.e. DOs which never ever have any frame or other display related actions to handle, they only ever handle data, their semantics/descriptions and its refreshing) and displays DODisplays (which "populate the tooltip" or any other display). Yes, in Elk's language you could make an ElkDO that essentailly is a set of "pure" DOs and DODisplays, as said earlier.
Maybe I should best make a separate thread to avoid having these two strands of ideas cause too much confusion and maybe come up with a new set of words to delineate display/data?
In any case the point of the mockup is to show that clean data/display separation is perfectly feasible.
I've implemented the armored man example discussed earlier with the kind of display/data separation I wanted.
(The one on the right is the smooth-durability but otherwise default armored man)
Basically you can have as many armored man as you want and you can link its armor pieces to any semantically matched data you want through a DO that provides this data via libdatabroker. In this example durability is actually mapped to scale of armor pieces, and non-existing armor is hidden and armor without durability is blue-colored. You can see that the shield is not scaled as it has no durability, compared to the other pieces. His arms are shortened due to the damage to them.
Mostly the armored man can actually take more than one set of DO data and map them to different visual dimensions of armor pieces, e.g. you could do scale for item value, color for durability, and alpha for item age and juggly motion for item sell value etc. Or you can map these to separate armored men or just a completely different display, like a text display in chat or a statusbar based one etc.
I currently only have the armored man display and one DO for durability and I wanted to do at least 2-3 displays and a few DOs to show the real flexibility in that setup. In any case I'll just put what I have on the branches tomorrow so people can have a look.
The DO provides data for each durability slot, but only marks the slot semantic and nothing else (i.e. a display knows that data for such a slot is available and the DO provides optional text explaining the meaning). hence you see that the data really could be anything as long as it fits the format. You could feed random numbers if you wanted to or a dance pattern ;)
The display grabs these and chooses how to render. If it needs to be informed about refreshes, it enters a Refresh function into the DO, that the DO calls upon data changes when available. This way the DO can actually inform the display about data refreshes but only when the display actually wants them. This isn't really a display refresh but a data refresh function hence the DO is still only ever worrying about data and not how it's displayed. Multiple displays can feed of a single DO so multiple Refresh's can be registered (e.g. you could have an armored man and a paper-doll durability display feeding from the same DO, guaranteeing that data is only ever polled once.)
In any case I understand that the majority doesn't think this is a worthwhile path, and so be it. I think this is really a separate project of a more full-fledged data/display separation that's removed from fubar like presets. These can then still live within elkano's idea, but then his type of DO's get split again into things that populate frames (what I call displays) and things that provide just actual data ("pure" DOs) once more.
Good news is though I do use libdatabroker-1.0 as is. That is a very open design that will facilitate all sorts of data sharing between addons.
Here's some ideas for you Elsia... most are quite common in the Fu/Titan designs:
I'm sorry. I don't understand the message those examples are supposed to deliver.
Problem there is, the DO must have some knowledge of the frame it's populating if you're doing anything beyond passing a simple string with newlines. The DO couldn't format colors or alignment... which in the end makes the tooltip two thirds useless. The DO couldn't use GameTolltip methods like SetHyperlink... It also means that the DO can't use a more complex frame, it'd be forced into a GameTooltip or whatever the display wants. Although it might seem counter to the design, the display's job in the matter is to DISPLAY the frame, while the DO's job is to populate it with data.
The DO can provide the semantics of its data. I.e. if one text has a different semantics than another. A display can then recolor different semantic meanings in different colors and hence the tooltip is colored. But because the color isn't fixed by the DO but rather chosen by the display one can redesign the tooltip. Same for hyperlinks, a DO can say, I want a hyperlink, and the display finds a way to deliver it. These are different ideas where the separation should be.
But I think that is indeed the crux. If one thinks of a DO as any addon it of course has to do its own display and do display population. That's not the only way to think about this though. Another is that the DO provides information and the display's task is to do the population of the display based on that information. If there are things you can't do, then the brokering isn't rich enough and you should be pushing the displaying that you do in your display population in your paradigm into the display of this latter paradigm, after you have enriched the brokering.
I guess the point I'm trying to make here is that the OnClick may not be a config launcher at all.
I see, well I never thought you meant OnClick will always lead to a config. My point is rather that even the semantics of clicking could be abstracted if one wanted to.
The DO in your picture seems to me a full fledged addon, and there really doesn't sound to be an display/data abstraction after someone clicks. Then it makes a whole lot of sense that the DO has a tooltip and takes care of its config because it's a full addon. It ought to create custom tooltips, because there never was an intend to abstract that display from its content.
That means the DO really only abstracts how the little thing that we may or may not click on is displayed. I guess that's where my difference in thinking is. Most of what we call a DO is really just a full fledged addon with an abstracted text/icon/onclick face and a tooltip text vis. DataBroker may be a misnomer for that though. There is not a whole lot of data being brokered if that's the paradigm.
But I get it now I think. It means that what I am thinking off is indeed a separate concept and might in the end plug and play with this well enough (though the fixed onclick paradigm will hurt). But I'll want to broker a lot more data (see the armor man example) and I'd want to have separation of display actions (onclick, onenter etc) from meaning and reaction of data.
I'll try to find some time to write a mockup of what I'm thinking so the idea becomes more clear.
I think what you're missing is where the config is all rendered in a DewDrop menu spawned off the frame (the current FuBar design), not in the new config GUI. While I can certainly understand having some quick configs available in a menu like this, which could be covered simply by providing an OnClick handler... full blown config in a menu only is a very bad idea. A simple menu with an "Open config" option, or just opening config on click would be much MUCH better.
Yes, I was missing that. It's interesting. I do seem to thing about the whole topic very differently.
When I say DO has config I do in no way refer that it means: "It has config dewdroppy fubar style"
I rather mean that "it has things that may need configuration, whichever way that's provided".
We already have data/display abstraction for config so why even worry about this? Statblock doesn't emulate fubar's config legacy, there is no need. I never had fubar as a rolemodel but I repeatedly realize that fubar is a dominant model in the discussion.
Would all be covered if the DO provides an OnClick. Then it can render a menu or open a panel. The Display could override the onclick to display it's own menu, ala FuBar, which contains the display options and an item that runs the DO's onclick.
See I'd rather have the DO just say: Look here is my config. Display, decide how the user gets to it. If the display decides it's on a click it'll have OnClick used, if it's decide it just hooks it into some blizz/waterfally thing without providing a button click, that's fine too. The display gets to define the access semantics.
If the whole point of a DO is to be a config click thing, it provides three things, the icon/text, and the info that it can trigger a config. The display then decides what to do. It can make a check list with icon text and if the check box is checked it shows the config, or any other UI paradigm. It's not predetermined to be onclick.
You can make global access preference chances that way. Say someone implements a lefty-fubar, where all the right and left clicks are switched. They can do that, it's all on the display side. Or an all keybound access etc.
I still don't see why a DO should handle any frame for visualization at all or be primed for any frame-type interactions like OnClick or OnEnter.
We already have a data/vis abstraction for config with ace3config. If a DO wants to have a config it provides ace3config tables and it automatically get a choice of config displays (waterfally, cmd, dewdrop, default blizz, or whatever one may come up with). It never ever needs to worry about handling this itself. Triggering a config display works as per above. Again the actual implementation is picked by the display.
The display would be the choice how the user gets to see the config and if the user chooses a dropdown paradigm display, that's what you got. You can do legacy fubar ("I want my DOs to look like fubar"), but as an option, you can as well say ("I want all this look like statblocks and have config just appear in ace3config without dropdowns") Or anything else really. I don't see why DO/display can't exactly act and look like fubar, statblock. And this should be doable without pushing tooltip or other on frame interaction stuff into the DO.
But again, maybe I just talk about something else. Or I'm missing yet another thing.
I still don't understand the config question/problem etc.
Taking FuBar and assume that the FuBar itself is a type of Display and a fubar plugin is a DO (ignoring the obvious differences), of course FuBar has config related to each plugin (where it should be, or should it appear at all) and each plugin as config (what it does). Similarly for StatBlocks, there are global options and there are those for each individually.
I don't understand why specifically in a DO/Broker pair you get any more options than in this setting.
Yeah I come to realize that there are essentially two different goals that are mixed here. One is basically fubar flexible, the other is true data/display segregation. Those are very different goals and I think they are both fine. Mostly I got tempted into believing that we talk about the latter because of the name data-broker and earlier discussion about data/display segregation.
Really statfuflex might be more appropriate description of what you seem to want. Essentially it's different skinning and alignment of fubar like addons where the "DOs" are really almost the same as fubar plugins except that they are just slightly more abstracted so they can be skinned easier in a broad layout (do they look like fubar, statblock or are they arranged on a circle), but there is no actual modification of their core function which is to display information in a tooltip (or serve as config button).
That is fine by me. I kind of talk about a different thing though. Maybe it's worth considering it for a separate project.
Hovering over X is a display function not a DO one.
Your DO has defined an icon, a text, and a custom interface that could be rendered a custom tooltip (or something else).
The display decides that this should be rendered as custom tooltip, when hovering over the icon/text. The DO knows nothing about this, it's all display's work.
The display could also alternatively decide that it should be rendered as a fixed frame and that it opens when clicking the text/icon. Or it could decide that it is always visible and there is no hovering/clicking. The display/interaction semantics is all with the display, and it really needs to be just one, not two displays.
Setup is simple if there is no display for a broker, nothing shows. If a valid display is there it can take on a broker. Nothing more complicated to set up than what it currently means to get a fubar addon onto fubar.
I'm not sure that's true. In essence it's the same code. You write your custom tooltip as display and deliver it with your matching broker. You define custom attributes to serve your special needs to interface data between custom tooltip display and broker. If now someone else wants to implement another display for this same broker they have to implement the custom broker interface that you defined to allow the custom behavior.
As long as there is no other valid display for this broker your first will do the service. But by it being set up this way, another display option can be implemented.
If however you implement the same custom tooltip into the DO it guarantees that no other display can ever replace it.
I'm still confused about the concept. My initial impression was that the idea is to separate data from its display, mostly so that people can switch the display around to their needs while keeping all data brokerage intact. If the DO creates the tooltip it is the display and it will be hard for the user to switch around the display for it. That's fine if that's the intend, but it'll mean that overall it's gonna be much closer to an actual fubar/statblock replacement than a layer on top of which once can do fubar, statblock or something else. One certainly can do dynamic content and still do the separation but it'll mean a different setup.
I can see this being the best route for code simplicity. Also if the DO can generate its tooltip directly, to its need, then porting certain FuBar addons will be trivial. But it isn't quite what I expect this to be I suppose.
To pick the Armor man tooltip example, if the display is abstracted, then the data broker only delivers what pieces of the armor man have what durability. The display then chooses to render this as the default armor man, as an item list with durability % or as a pie chart, depending solely on the display choice. It can even decide that this should be a tooltip display or be attached to a certain frame, or some other representation (HuD location icons of the items that are broken for example).
If one display implements an armor man tooltip it can easily be fed from different brokers, like the durability of an alt or a raid member or the item quality of the item or the time ("age") it has been in a slot. But this is only easy if the abstraction separation is at the right point.
If the display does the rendering, if a user wants to switch from the armor man to the item list, all is needed is switching the display and all the data brokers will still deliver the same data function, the display will remain consistent (or flexible, i.e. if a user wants to use display A for broker X and display B for broker Y they can do that too).
Just to give an idea how I was thinking about this initially. Maybe that's just way too out there.
There's another thing to discuss: Should data objects or displays handle the tooltip? I think this is part of the display, so all tooltips look the same and the data objects don't get bloated. In this case OnEnter/OnLeave would be useless and should be replaced by .tooltipText or just .tooltip.
Yep that's basically what I've been trying to say in a way too complicated way. Except that I called it .description but that's just semantics. .tooltipText or .tooltip works. I certainly find it preferable to leave the display handling (like tooltip visualization) to the display.
.text and .icon are good in my book. This is just data with a certain semantic (the data's core text and it's icon representation).
However .OnClick, .OnEnter, .OnLeave kind of assume a single frame representation ala fubar or statsblock. But a display may actually choose a different paradigm.
Maybe it's better to be closer with attributes to how data for config is defined. E.g. have a
.execute (was .OnClick)
.description (what would be an .OnEnter tooltip)
by offering a range of .execute (e.g. .execute1, .execute2) one can define that multiple data sets are available to execute on. A fubar/statblock could implement this as left/right clicks, or one could do a skill-booklet type representation where these are actually represented as buttons.
Once the semantics of the attributes are set it is completely up to the display to choose what to do with it. If it chooses to ignore some that's fine.
To compare to example displays for a simple case:
.text = "MeBrokerage"
.icon = /funkyicon
.description = "A pointless broker!!"
.execute1 = function --[[action]] end
.description1 = "Delete your harddrive"
.execute2 = function --[[more action]] end
.description2 = "Blame your mom"
Fubar/statblock could render this as:
In frame: [/funkyicon] MeBrokerage
On mouseover: Tooltip-frame:
"A pointless broker!!"
"Left Click to Delete your harddrive"
"Right Click to Blame your mom"
And it executes .execute1 on leftclick and .execute2 on rightclick.
A waterfall/skillbook type display would render it like this:
"A pointless broker!!"
Button1: "Delete your harddrive"
Button2: "Blame your mom"
There is no hover/onenter/tooltip functionality here.
The broker has only delivered data/execution and its semantics. The display renders it as fits the display philosophy. One can also have stuff like .cmdOnly (or .configOnly) to indicate that the broker means to provide access to a specific semantic function (config gui access). The display can then choose to render those differently (or not). Maybe .cmdOnly really should rather be some attribute for grouping. Like .group = "AddonConfig". Then displays can group data by their group attribute, i.e. have AddonConfig together and info displays elsewhere etc.
A last thing that I'm missing is data allowing to push to the display somehow. Say if you want to display a clock or DPS and want periodic update. That's different than static text that just pops up. Clearly you'd want the data to decide when the display needs to be informed about updates (though the display may choose to modify or ignore it).
The way I understood the core idea there shouldn't be the assumption of a tooltip but only the data that could go into a tooltip (or somewhere else, like a waterfall-rightside frame).
Fubar addons in the worst case have 3 components showing in the bar(each often optionally), icon, static label lext, dynamic info text.
I wonder if it does make sense to keep that structure, because updates are only needed if the icon changes or the dynamic text changes but never if the label text changes. Also the visualization can decide to treat these three aspects differently, say e.g. use the static label as a help tooltip in a waterfall-type display or a display where mouseover does not automatically pop up a large tooltip with info. Or it can choose to place dynamic information separately from the static label etc.
In fact one could think of supporting multiple icons, multiple static texts, and multiple dynamic texts (just give a table) and let the visualization handle what to do with them. Not sure if that has any real use (multiple icons can be used to display states for example).