For what are we looking for a name currently? The lib that is in between the addons and the display? Or a display that can be used for addons following the things proposed in this thread and that works similar to FuBar/Titan/...?
In the first case the name shouldn't include'bar' since eg minimap buttons aren't no bars nor does the lib itself provide any functionality like that.
In the second case we aren't talking about a lib anymore.
How about libErty for the lib providing the layer between addons and the displays? Since it provides the freedom to chose where to show your data as it was noted in one of the first amendments to the WoW constitution that our forefather had written down so many years ago...
oh wait, I'm messing sth up there...
Nah, I think you misunderstood. What I'm saying is that if you wanted to add a bit of optional FuBar support to your addon, you wouldn't have to include a bunch of stuff in your own addon. All you need is to check if FuBar is loaded and run your support code if it is. It would have almost no impact on users without FuBar.
You can use optional libraries and still have addons that can happily live as standalone... In fact most of my addons have at least 1-2 optional library support.
Heck if someone has sharedmedia installed, they can use it, but not having it surely should never break my or any addon, I provide fonts that I know are available. Same with fubar support, it's completely trivial to make an addon that works standalone and has fubar support if fubar is present.
In fact this is the spirit of true modularity. If someone happens to have a library installed that would be benefitial, an addon supports it for extra features, but works fine without.
My little SimpleRangeIndicator addon works without RangeCheck-1.0, but if it finds RangeCheck-1.0 present it uses it for better range check resolution from the library. It's standalone and supports optional libraries at the same time.
I'm pretty sure that's what Bam means and he's quite right that optional library support doesn't break the standalone state of an addon if done properly.
Nice start. But something strikes me. This seems very general. So general that is must have ben done before. :)
Isn't this in fact a generalized "object-broker"? Think CORBA, think COM. We have a set of data providers (objects that can provide data), and we have a set of hungry consumers that eat these data (sorry missing the terminology here lol). But they know nothing of each other. They need a mediator of some sort so the consumers can discover these providers.
I'm not saying it needs to be anything close to the complexity of CORBA/COM. But perhaps it's worth looking a bit into what's been done before anyway. :)
what should be attributes and what should be call backs? These wouldn't be enforced by the lib but something we can point at and say that it should be there and is expected to be there.
Attribs:
-Name : Hard name of the addon
-Icon : Properly escaped icon path
-"ShortDisplayText", like a title
-LongDisplayText, this would be like a ticker display... or if there is information to be there as a primary display
-Description,
Callbacks / Methods:
-OnClick: Passes the button that it got clicked with. This one will also produce the menu if programed correctly
-ShowTooltip: would pass the anchor frame
-OnToolTipUpdate: Called when the UI wants to refresh the tooltip
-HideTooltip: obvious, needed for clean up of tooltip
-GetDisplayTable: --an interesting idea, this would return a table or a string text used to display extended information that would not necessarily be found on the tooltip, borderline something that the data addon itself should provide. this would be an indexed table with each index being a new line. Recycled by the UI Addon.
You'll also have to inform the display, that your data has changed in order to remove the necesarity to poll all addons for changes.
Also instead of providing short and long texts why not have the addon provide the text either as a string or a relation between lables and text strings? This would allow any number of styles per addon... hmm... or should an addon be able to return more than one "data stream"?
WRT callbacks and methods:
- a callback to inform the display that our data changed (split that for icon and text?)
- a method to be informed about clicks on the display frame (shall that handle all clicks?)
- a method to be informed that a tooltip was requested
- a method to be ordered to terminate the tooltip
While the tooltip is handled by the data addon the decision to show it should be done by the display. Still I don't see a need for "OnTooltipUpdate".
/?dith has found some other things to think about:
- where should a new addon display by default? Everywhere?
- should the display be able to inject options into the addons config menu (like it is with FuBar eg left/center/right placement)?
But in general I wouldn't define the whole thing too general wrt attributes and such since that will lead to 'special' features per addon that hardly anything supports. (Didn't CORBA suffer from that, too? ;) )
You'll also have to inform the display, that your data has changed in order to remove the necesarity to poll all addons for changes.
Also instead of providing short and long texts why not have the addon provide the text either as a string or a relation between lables and text strings? This would allow any number of styles per addon... hmm... or should an addon be able to return more than one "data stream"?
no one steam per object. so in order for an addon to run 2 streams it would have to create a 2nd table object to embed onto.
WRT callbacks and methods:
- a callback to inform the display that our data changed (split that for icon and text?)
- a method to be informed about clicks on the display frame (shall that handle all clicks?)
- a method to be informed that a tooltip was requested
- a method to be ordered to terminate the tooltip
the OnClick method handles all clicks, modified and such,
OnTooltipShow / Hide is called by the UI to tell the data addon to display it's tool tip. if the dataSource want's to make the UI create the tooltip for it and manage it that's where "GetDisplayTable" comes in. OnTooltipUpdate is something the UI calls internally in case it wants to update the tooltip for some reason, otherwise that's up to the control of the data addon to update it's own TT (prolly though the same function)
While the tooltip is handled by the data addon the decision to show it should be done by the display. Still I don't see a need for "OnTooltipUpdate".
/?dith has found some other things to think about:
- where should a new addon display by default? Everywhere?
- should the display be able to inject options into the addons config menu (like it is with FuBar eg left/center/right placement)?
But in general I wouldn't define the whole thing too general wrt attributes and such since that will lead to 'special' features per addon that hardly anything supports. (Didn't CORBA suffer from that, too? ;) )
special features for specific UI are fine, it's quite irrelevant, invalid requests return silently.
but ya, some base fundamentals, something that ALL Display UI's are going to expect to find.
Callbacks / Methods:
-OnClick: Passes the button that it got clicked with. This one will also produce the menu if programed correctly
-ShowTooltip: would pass the anchor frame
-OnToolTipUpdate: Called when the UI wants to refresh the tooltip
-HideTooltip: obvious, needed for clean up of tooltip
ShowTooltip - Change this to GetTooltip (or more specifically, GetAttribute("Addon Name", "Tooltip")) Model populates a frame (not necessarily a GameTooltip) and returns it. View anchors and shows the frame.
HideTooltip - Not needed, the View will hide the frame on it's own.
OnToolTipUpdate - Not needed, the Model updates the frame it returned earlier if it :IsVisible()
Quote from Elkano »
You'll also have to inform the display, that your data has changed in order to remove the necesarity to poll all addons for changes.
I thought that was the whole design we had already, or has Orion already complicated it? We need 3 basic things:
* Method to set an "attribute" for a Model. Essentially just writing a key/value into a table except...
* Callbacks to Views when a Model's attribute is changed. Simple event-driven behaviour here, the View knows it needs to query the new attribute and handle it accordingly. Note that an attribute isn't necessarily something to display, it could be a new OnClick method or such
* Method to get attributes, so that Views can retrieve the stuff they need.
Quote from Elkano »
WRT callbacks and methods:
- a callback to inform the display that our data changed (split that for icon and text?)
- a method to be informed about clicks on the display frame (shall that handle all clicks?)
- a method to be informed that a tooltip was requested
- a method to be ordered to terminate the tooltip
See above, these all become dumb attributes... Clicks are passed directly into the function stored in the Model's "OnClick" attribute. This should be exactly like Blizzy's script, so the Model can anchor a menu or whatnot. Also as above, there's no need for the Model to manage the tooltip/frame's visibility and positioning, only the contents displayed inside.
Quote from Elkano »
But in general I wouldn't define the whole thing too general wrt attributes and such since that will lead to 'special' features per addon that hardly anything supports. (Didn't CORBA suffer from that, too? ;) )
Which is why we should lay out as the base support being icon, text, tooltip, clicks. going to be View-addon dependent anyway. I intend on writing a view addon myself, and I won't be supporting anything beyond that because I don't see any need. Model addons should not expect complex features to be there, but can implement them optionally if they want (I.E. they should function properly if the View addon cannot do any more than show their text, because that's really the only thing that's required here).
Which is why we should lay out as the base support being icon, text, tooltip, clicks. going to be View-addon dependent anyway. I intend on writing a view addon myself, and I won't be supporting anything beyond that because I don't see any need. Model addons should not expect complex features to be there, but can implement them optionally if they want (I.E. they should function properly if the View addon cannot do any more than show their text, because that's really the only thing that's required here).
base support implies requirement or checking the function exists before usability. the registry doesn't do any of that.
im talking about fundamental expectations. IE, fubar expect a name, an icon, and a tool tip update func -- fundamentally -- and everything else is really optional.
what im asking for is what fundamentals should we set as an expectation on the source to provide.
--icon, text, tool tip, clicks--
and that seems to cover it all... tho i still think that show/hide/update should be there....
*re: tek, bout the only thing i have a problem is use CBH at all.. i got no clue how to implement it.. but there is something there that is jsut as good IMO... maybe more conveluded but it works... and the "Tell Display the attrib changed" idea is a bitch schetchie..
Theoreticaly the only thing needed is either icon or text. But in case the addon wants to react on clicks or have a tooltip display data it should follow to the definition.
But with the data addon providing the tooltip and then giving handling (besides data) to the display addon this will require some specific stuff. Hiding shouldn't be the problem since all frames support :Hide(). But think about a display that fades the tooltip. During fading another display addon requests the tooltip but the first continues to fade 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).
so the lib feels pritty solid, if yall's can decide on a name... LibWoWRegistry is what im naming it atm.. i'll throw it on the svn so every one can play with it...
so the plug in spec feels also intuitive..
i'd like to play both sides of the tooltip question w/r to the spec...
have the plug-in provide a On-Show/Hide/Update method, this allows the plug-in to provide the tooltip.
also allow a "GetTooltipData()" method with in the plug-in that is called if OnShow is not found. that method would return a indexed table of for the tooltip. that way the Display addon can make and setup the addon.. it solves both questions.
-that is unless we want to force the plug-in to manage it's own tool tip regardless. if so then we have to have a way to tell the module to show or hide it's tooltip, some sort of call back from the frame or something...
But in general I wouldn't define the whole thing too general wrt attributes and such since that will lead to 'special' features per addon that hardly anything supports. (Didn't CORBA suffer from that, too? ;) )
Most big standards do suffer from that, I think. :) They are a result of too many compromises between too many parties with different (often opposite) needs.
Anyway, it was just a thought I had because I could see some similarities. One thing I do consider of utmost importance is that the interface be based purely on use of functions. The view should be the one that asks for data when it needs them - never the other way around. Just consider the situation where there are no views requesting data. Then it would be pretty silly if the model constantly calculated data and "exported" it somewhere.
Well but maybe the data has to be calculated as some event happens. And how should the view know that the data changed if the addon doesn
t inform it nor notice it itself?
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Forum Moderator-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThen you get LibBar-T
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorIn the first case the name shouldn't include'bar' since eg minimap buttons aren't no bars nor does the lib itself provide any functionality like that.
In the second case we aren't talking about a lib anymore.
How about libErty for the lib providing the layer between addons and the displays? Since it provides the freedom to chose where to show your data as it was noted in one of the first amendments to the WoW constitution that our forefather had written down so many years ago...
oh wait, I'm messing sth up there...
but then it wouldnt work standalone
Heck if someone has sharedmedia installed, they can use it, but not having it surely should never break my or any addon, I provide fonts that I know are available. Same with fubar support, it's completely trivial to make an addon that works standalone and has fubar support if fubar is present.
In fact this is the spirit of true modularity. If someone happens to have a library installed that would be benefitial, an addon supports it for extra features, but works fine without.
My little SimpleRangeIndicator addon works without RangeCheck-1.0, but if it finds RangeCheck-1.0 present it uses it for better range check resolution from the library. It's standalone and supports optional libraries at the same time.
I'm pretty sure that's what Bam means and he's quite right that optional library support doesn't break the standalone state of an addon if done properly.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumhttp://shock-wow.googlecode.com/svn/trunk/LibWoWRegistry-1.0/LibWoWRegistry-1.0.lua
*a draft of this "registery" type thing-a-ma-jig
Isn't this in fact a generalized "object-broker"? Think CORBA, think COM. We have a set of data providers (objects that can provide data), and we have a set of hungry consumers that eat these data (sorry missing the terminology here lol). But they know nothing of each other. They need a mediator of some sort so the consumers can discover these providers.
I'm not saying it needs to be anything close to the complexity of CORBA/COM. But perhaps it's worth looking a bit into what's been done before anyway. :)
Edit: Idea for new name could be WORBA. :lol:
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumwhat should be attributes and what should be call backs? These wouldn't be enforced by the lib but something we can point at and say that it should be there and is expected to be there.
Attribs:
-Name : Hard name of the addon
-Icon : Properly escaped icon path
-"ShortDisplayText", like a title
-LongDisplayText, this would be like a ticker display... or if there is information to be there as a primary display
-Description,
Callbacks / Methods:
-OnClick: Passes the button that it got clicked with. This one will also produce the menu if programed correctly
-ShowTooltip: would pass the anchor frame
-OnToolTipUpdate: Called when the UI wants to refresh the tooltip
-HideTooltip: obvious, needed for clean up of tooltip
-GetDisplayTable: --an interesting idea, this would return a table or a string text used to display extended information that would not necessarily be found on the tooltip, borderline something that the data addon itself should provide. this would be an indexed table with each index being a new line. Recycled by the UI Addon.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorAlso instead of providing short and long texts why not have the addon provide the text either as a string or a relation between lables and text strings? This would allow any number of styles per addon... hmm... or should an addon be able to return more than one "data stream"?
WRT callbacks and methods:
- a callback to inform the display that our data changed (split that for icon and text?)
- a method to be informed about clicks on the display frame (shall that handle all clicks?)
- a method to be informed that a tooltip was requested
- a method to be ordered to terminate the tooltip
While the tooltip is handled by the data addon the decision to show it should be done by the display. Still I don't see a need for "OnTooltipUpdate".
/?dith has found some other things to think about:
- where should a new addon display by default? Everywhere?
- should the display be able to inject options into the addons config menu (like it is with FuBar eg left/center/right placement)?
But in general I wouldn't define the whole thing too general wrt attributes and such since that will lead to 'special' features per addon that hardly anything supports. (Didn't CORBA suffer from that, too? ;) )
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumno one steam per object. so in order for an addon to run 2 streams it would have to create a 2nd table object to embed onto.
the OnClick method handles all clicks, modified and such,
OnTooltipShow / Hide is called by the UI to tell the data addon to display it's tool tip. if the dataSource want's to make the UI create the tooltip for it and manage it that's where "GetDisplayTable" comes in. OnTooltipUpdate is something the UI calls internally in case it wants to update the tooltip for some reason, otherwise that's up to the control of the data addon to update it's own TT (prolly though the same function)
special features for specific UI are fine, it's quite irrelevant, invalid requests return silently.
but ya, some base fundamentals, something that ALL Display UI's are going to expect to find.
ShowTooltip - Change this to GetTooltip (or more specifically, GetAttribute("Addon Name", "Tooltip")) Model populates a frame (not necessarily a GameTooltip) and returns it. View anchors and shows the frame.
HideTooltip - Not needed, the View will hide the frame on it's own.
OnToolTipUpdate - Not needed, the Model updates the frame it returned earlier if it :IsVisible()
I thought that was the whole design we had already, or has Orion already complicated it? We need 3 basic things:
* Method to set an "attribute" for a Model. Essentially just writing a key/value into a table except...
* Callbacks to Views when a Model's attribute is changed. Simple event-driven behaviour here, the View knows it needs to query the new attribute and handle it accordingly. Note that an attribute isn't necessarily something to display, it could be a new OnClick method or such
* Method to get attributes, so that Views can retrieve the stuff they need.
See above, these all become dumb attributes... Clicks are passed directly into the function stored in the Model's "OnClick" attribute. This should be exactly like Blizzy's script, so the Model can anchor a menu or whatnot. Also as above, there's no need for the Model to manage the tooltip/frame's visibility and positioning, only the contents displayed inside.
Which is why we should lay out as the base support being icon, text, tooltip, clicks. going to be View-addon dependent anyway. I intend on writing a view addon myself, and I won't be supporting anything beyond that because I don't see any need. Model addons should not expect complex features to be there, but can implement them optionally if they want (I.E. they should function properly if the View addon cannot do any more than show their text, because that's really the only thing that's required here).
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumbase support implies requirement or checking the function exists before usability. the registry doesn't do any of that.
im talking about fundamental expectations. IE, fubar expect a name, an icon, and a tool tip update func -- fundamentally -- and everything else is really optional.
what im asking for is what fundamentals should we set as an expectation on the source to provide.
--icon, text, tool tip, clicks--
and that seems to cover it all... tho i still think that show/hide/update should be there....
*re: tek, bout the only thing i have a problem is use CBH at all.. i got no clue how to implement it.. but there is something there that is jsut as good IMO... maybe more conveluded but it works... and the "Tell Display the attrib changed" idea is a bitch schetchie..
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorBut with the data addon providing the tooltip and then giving handling (besides data) to the display addon this will require some specific stuff. Hiding shouldn't be the problem since all frames support :Hide(). But think about a display that fades the tooltip. During fading another display addon requests the tooltip but the first continues to fade it.
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).
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumso the plug in spec feels also intuitive..
i'd like to play both sides of the tooltip question w/r to the spec...
have the plug-in provide a On-Show/Hide/Update method, this allows the plug-in to provide the tooltip.
also allow a "GetTooltipData()" method with in the plug-in that is called if OnShow is not found. that method would return a indexed table of for the tooltip. that way the Display addon can make and setup the addon.. it solves both questions.
-that is unless we want to force the plug-in to manage it's own tool tip regardless. if so then we have to have a way to tell the module to show or hide it's tooltip, some sort of call back from the frame or something...
Most big standards do suffer from that, I think. :) They are a result of too many compromises between too many parties with different (often opposite) needs.
Anyway, it was just a thought I had because I could see some similarities. One thing I do consider of utmost importance is that the interface be based purely on use of functions. The view should be the one that asks for data when it needs them - never the other way around. Just consider the situation where there are no views requesting data. Then it would be pretty silly if the model constantly calculated data and "exported" it somewhere.
-
View User Profile
-
View Posts
-
Send Message
Forum Moderatort inform it nor notice it itself?