Yaknow... after playing WAR, there's one thing I'm missing in WoW: the ability to show everything and make it movable with one single button press.
I'm thinking that we would need to standardize on something very simple where addons can get notifications of "config mode on/off" events. No, this won't be AceEvent, I don't want any bars for non-ace addons.
i.e. one global table that addons can create if necessary, and then stick an entry in.
Then their registered function pointers would get called with ("ON") or ("OFF") as parameters - nice and extensible if more things are needed.
Example code needed in an addon would be something like:
CONFIGMODE_CALLBACKS = CONFIGMODE_CALLBACKS or {}
CONFIGMODE_CALLBACKS["MyAddon"] = function(mode)
if mode=="ON" then
MyAddon.EnableConfigShizzle(true)
elseif mode=="OFF" then
MyAddon.EnableConfigShizzle(false)
end
end
Nice and clean.
As for what would actually CALL these? Well, that'd then be entirely open. Someone could write a standalone addon to do it, or integrate it into some other system, or whatever.
Input?
Edit: What I mean by "config mode" is not popping up config dialogs. I mean displaying drag handles.. making things movable.. popping out test bars / dummy message .... making things sizable.. stuff like that. So that you SEE if you're moving something on top of something else without having to hop into the config of every single on-screen addon you have first.
It kinda does this already, but only for addons it knows about (it hardcodes calls into them). nShakedown would be one very obvious place to do these callouts from.
It kinda does this already, but only for addons it knows about (it hardcodes calls into them). nShakedown would be one very obvious place to do these callouts from.
I've abandoned wow for war... I haven't even installed wow 3.0...
If you want to take over NShakedown / hack it up / use the OO parts as a skeleton for this, you're most welcome to it.
NShakedown turned into a maintenance nightmare - only about 30% of the addons were done by the respective authors, the rest were done by me, and often broke during updates.
If this enablement code is built into the addons, NShakedown would be much simpler and easier - just build a list of addons that support these methods and call them.
I like the idea in principle, but I think in reality most people want: Make some (not all mods) go into config mode. And what people expect in that some-set varies.
A very different but related idea has to do with rapid config of many addons by allowing profile copy/setting for all addons that support acedb profiling. That is something that can be done, will work gracefully for most needs. But I understand that it's a different purpose. The idea here is for intial setup of the UI, this is for rapid propagation of setups (between alts, accounts etc).
CONFIGMODE_CALLBACKS = CONFIGMODE_CALLBACKS or {}
local OneButtonConfig = LibStub('LibDataBroker'):New('OneButtonConfig', {
type = 'launcher',
state = false,
OnClick = function(self)
self.state = not self.state
for name,callback in pairs(CONFIGMODE_CALLBACKS ) do
local ok, msg = pcall(callback, state)
if not ok then geterrorhandler()(msg) end
end
end
})
LibStub("LibDBIcon-1.0"):Register("OneButtonConfig", OneButtonConfig, OneButtonConfigDB)
SLASH_ONEBUTTONCONFIG1 = "/onebuttonconfig"
SLASH_ONEBUTTONCONFIG2 = "/obc"
SlashCmdList["ONEBUTTONCONFIG"] = function() OneButtonConfig:OnClick() end
While this is a great idea on principle, I fear that the implementation can have "undesired" implications. Since this is supposed to be open, "config mode" can be interpreted and implemented in many different ways from authors, which can lead to stuff popping up that the user potentially doesn't want (or need) to be configured at that point. For instance let's say that a user enables this and he has his unitframe addon, bar addon, various frame addons going into config mode, at which point those addons may decide to show up frames that the user has elected to hide, which can lead to stuff overlapping, while in reality this won't happen etc. Depending on what it is used, it can actually be more confusing and cumbersome than helpful. I'm not saying it can't be done, merely saying that unless you apply some basic rules and principles, it can just as easily backfire. "Standardize" is indeed a very scary word, mainly because you have to convince people to see your point of view :p
I'm with Elsia on this one, I believe that most people would be more interested in a way to auto-copy/populate all configuration options from one character to another, at least that is my viewpoint on this.
While this is a great idea on principle, I fear that the implementation can have "undesired" implications. Since this is supposed to be open, "config mode" can be interpreted and implemented in many different ways from authors, which can lead to stuff popping up that the user potentially doesn't want (or need) to be configured at that point. For instance let's say that a user enables this and he has his unitframe addon, bar addon, various frame addons going into config mode, at which point those addons may decide to show up frames that the user has elected to hide, which can lead to stuff overlapping, while in reality this won't happen etc. Depending on what it is used, it can actually be more confusing and cumbersome than helpful. I'm not saying it can't be done, merely saying that unless you apply some basic rules and principles, it can just as easily backfire. "Standardize" is indeed a very scary word, mainly because you have to convince people to see your point of view :p
I'm with Elsia on this one, I believe that most people would be more interested in a way to auto-copy/populate all configuration options from one character to another, at least that is my viewpoint on this.
NShakedown was controllable and predictable. I see your point - things could get out of hand with all sorts of unnecessary things being done on show.
While this is a great idea on principle, I fear that the implementation can have "undesired" implications. Since this is supposed to be open, "config mode" can be interpreted and implemented in many different ways from authors, which can lead to stuff popping up that the user potentially doesn't want (or need) to be configured at that point. For instance let's say that a user enables this and he has his unitframe addon, bar addon, various frame addons going into config mode, at which point those addons may decide to show up frames that the user has elected to hide, which can lead to stuff overlapping, while in reality this won't happen etc. Depending on what it is used, it can actually be more confusing and cumbersome than helpful. I'm not saying it can't be done, merely saying that unless you apply some basic rules and principles, it can just as easily backfire. "Standardize" is indeed a very scary word, mainly because you have to convince people to see your point of view :p
As you said, this just requires to be clearly stated that the configuration mode is "showing all frames and texts (using fake texts, values and units if need be) that might be visible during normal operation so the user could move them around."
I'm with Elsia on this one, I believe that most people would be more interested in a way to auto-copy/populate all configuration options from one character to another, at least that is my viewpoint on this.
Mikk, I think that if you could get authors of major well-known addons to include your "config mode stub" into their addons, you would have a good base to spread this.
I guess what we are trying to say is that this doesn't only need a standard but also guidelines/best practices in that authors should know how typically to react to such an event.
Should all pop their config windows open, or just some (or none?), should they reveal all hidden anchors, or should they make windows movable?
In fact ideally the responsibility of this should be with the lib/addon that does this so that all addon authors don't get flooded by users requesting a different specific behavior for the config all feature.
For recount some may want the config window to pop up, some don't. Some may want to make all visible windows movable, some may want all, also the hidden windows made visible and movable.
Should a bar addon unlock everything (bar movement and buttons) or just movement, etc.
That's what we mean by this being tricky in the detail. In fact it smells to me that you really want more events, that are more specific, or at least arguments that are specific (i.e. one to unlock visible windows, one to pop up config windows, one to show and unlock hidden windows, one to unlock within addon configs, such as button locking etc. Btw I'm not saying that these are the right task groups. I think there is a devil in the detail, a lot here).
To be clear: I NEVER intended for config option windows to pop up. Having 50 addons pop out their config windows is utterly useless.
I mean making windows movable (showing draghandles for those that use that). Put in fake texts/bars. Show all units in the party for UFs.
This would then allow you to move stuff around and make sure things don't overlap (unless you intentionally make it so).
An EXTENDED "One button config mode" addon could of course easily make sets of addons to toggle on and off. Note how I sneakily put the name of the application as the key in the table so that they can be identified!
If such a thing were to run on my current setup, Pitbull would have to switch into one of it's config modes (and which mode would it choose?). At the same time, Dominos would switch into move mode, AutoBar would switch into move mode (but which move mode? buttons or bars?), etc. This would cause a whole mess of crap to suddenly become movable and it would all be overlapping and impossible to work with.
No, for me at least, with the add-ons I'm using, enabling this mode all at one time would be completely unworkable. I find the current LDB/Broker2Fubar implementation to be best, where I can selectively turn config mode on for the add-on I want. But then again, I generally know how all my add-ons work and can enable their config modes very quickly when I need to.
I really like the dominos/bongos move/position library.. it makes it possible to attach frames together and stick it to other frames points and uiparent edges.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I'm thinking that we would need to standardize on something very simple where addons can get notifications of "config mode on/off" events. No, this won't be AceEvent, I don't want any bars for non-ace addons.
Maybe something like this:
CONFIGMODE_CALLBACKS = {
["MyAddon"] = MyAddon_OnConfigMode
["OtherAddon"] = OtherAddon_CnfModeHandler
}
i.e. one global table that addons can create if necessary, and then stick an entry in.
Then their registered function pointers would get called with ("ON") or ("OFF") as parameters - nice and extensible if more things are needed.
Example code needed in an addon would be something like:
Nice and clean.
As for what would actually CALL these? Well, that'd then be entirely open. Someone could write a standalone addon to do it, or integrate it into some other system, or whatever.
Input?
Edit: What I mean by "config mode" is not popping up config dialogs. I mean displaying drag handles.. making things movable.. popping out test bars / dummy message .... making things sizable.. stuff like that. So that you SEE if you're moving something on top of something else without having to hop into the config of every single on-screen addon you have first.
If you code it, they will come. Unless it's a library that shouldn't be a library because it'll only veer be used by a single addon.
Anywho: Nice concept.
It kinda does this already, but only for addons it knows about (it hardcodes calls into them). nShakedown would be one very obvious place to do these callouts from.
I've abandoned wow for war... I haven't even installed wow 3.0...
If you want to take over NShakedown / hack it up / use the OO parts as a skeleton for this, you're most welcome to it.
NShakedown turned into a maintenance nightmare - only about 30% of the addons were done by the respective authors, the rest were done by me, and often broke during updates.
If this enablement code is built into the addons, NShakedown would be much simpler and easier - just build a list of addons that support these methods and call them.
A very different but related idea has to do with rapid config of many addons by allowing profile copy/setting for all addons that support acedb profiling. That is something that can be done, will work gracefully for most needs. But I understand that it's a different purpose. The idea here is for intial setup of the UI, this is for rapid propagation of setups (between alts, accounts etc).
Throw in LibDataBroker and LibDBIcon and do :
I'm with Elsia on this one, I believe that most people would be more interested in a way to auto-copy/populate all configuration options from one character to another, at least that is my viewpoint on this.
NShakedown was controllable and predictable. I see your point - things could get out of hand with all sorts of unnecessary things being done on show.
If you want copying of configs, you might be able to use this:
http://www.wowwiki.com/Migrate_WTF_script
As you said, this just requires to be clearly stated that the configuration mode is "showing all frames and texts (using fake texts, values and units if need be) that might be visible during normal operation so the user could move them around."
That's a totally different concept.
Should all pop their config windows open, or just some (or none?), should they reveal all hidden anchors, or should they make windows movable?
In fact ideally the responsibility of this should be with the lib/addon that does this so that all addon authors don't get flooded by users requesting a different specific behavior for the config all feature.
For recount some may want the config window to pop up, some don't. Some may want to make all visible windows movable, some may want all, also the hidden windows made visible and movable.
Should a bar addon unlock everything (bar movement and buttons) or just movement, etc.
That's what we mean by this being tricky in the detail. In fact it smells to me that you really want more events, that are more specific, or at least arguments that are specific (i.e. one to unlock visible windows, one to pop up config windows, one to show and unlock hidden windows, one to unlock within addon configs, such as button locking etc. Btw I'm not saying that these are the right task groups. I think there is a devil in the detail, a lot here).
"full"
"movers"
"ALL"
"Overload-User-With-Alot-Of-Shit"
I mean making windows movable (showing draghandles for those that use that). Put in fake texts/bars. Show all units in the party for UFs.
This would then allow you to move stuff around and make sure things don't overlap (unless you intentionally make it so).
An EXTENDED "One button config mode" addon could of course easily make sets of addons to toggle on and off. Note how I sneakily put the name of the application as the key in the table so that they can be identified!
No, for me at least, with the add-ons I'm using, enabling this mode all at one time would be completely unworkable. I find the current LDB/Broker2Fubar implementation to be best, where I can selectively turn config mode on for the add-on I want. But then again, I generally know how all my add-ons work and can enable their config modes very quickly when I need to.
Make a library and I'll put it in VisualHeal. Makes a lot of sense to me - i hate the divergence between configuration of different addons.