3) Nice catch. Yes, a TOC directive that the controller addon can scan for seems like the sanest option. Maybe just "X-ConfigMode: true" then?
What about a general "X-ConfigMode" and an optional "X-ConfigMode-Modes". This way there is no need to load the addon until we need to activate the config mode.
One could argue that we could use the same TOC entry : "X-ConfigMode: true" and "X-ConfigMode: mode1, mode2, mode3". I find it less clear but yet acceptable.
What about a general "X-ConfigMode" and an optional "X-ConfigMode-Modes". This way there is no need to load the addon until we need to activate the config mode.
One could argue that we could use the same TOC entry : "X-ConfigMode: true" and "X-ConfigMode: mode1, mode2, mode3". I find it less clear but yet acceptable.
Seems a bit overkill for me. How often are you expecting to do this that (maybe) avoiding loading a few addons are going to make an actual impact on your gameplay? :P
Seems a bit overkill for me. How often are you expecting to do this that (maybe) avoiding loading a few addons are going to make an actual impact on your gameplay? :P
So why making LoadOnDemand addons at all ?
We can still just keep the "simple" TOC entry but it means we cannot have any multimodal load-on-demand addon as using "GETMODES" involves loading it.
Hm, misunderstanding. I meant "how often are you going to want to make all of your addons configurable" .. "and be negatively influenced by having the missing few load so you can actually see them?". Chances are, you wanted to see those to begin with so you can do match your other UI elements up against those, also.
Also I don't quite follow your discussion about selecting which ones load via their config mode selection. I mean, whether you want to see the party mode or raid mode of an UF addon doesn't mean you don't want to load it?
Your configmode controlling addon could certainly have SETS of addons to config-enable (and thus load). And with different parameters. But this again does not match any values returned from "GETMODES".
I'd like it as a library, so i can include this in my addon, without having to tell users to "go get OneButtonConfig". I want it to be a natural part of my addon, just like LibKeyBound-1.0.
This is effectively a library, you're just forcing it to be disembedded (it is standalone, and no libstub wrapping), and only providing a primitive interface to the addons (modifying global variables).
I know that no more is "needed", but that could be said of any library. I could implement LibHealComm-3.0 as a standalone addon, and just let users access some global variables in it.
The thing that makes a difference is that it is going to be used by multiple addons. That is what sets a library apart from an addon.
Edit: on second thoughts, I deleted my previous post . I think I misunderstood xbeeps.
So xbeeps, why would you have OneButtonConfig as a library. The core function looks like this:
if enable then
-- Enable all config modes
for name, callback in pairs(CONFIGMODE_CALLBACKS) do
local mode = callback("GETMODES")
if mode ~= nil then
-- Multimode, try to get the user-selected mode
-- or use the first mode as the default one
mode = GetSavedMode(name) or mode
end
callback("ON", mode)
end
else
-- Disable all config modes
for name, callback in pairs(CONFIGMODE_CALLBACKS) do
callback("OFF")
end
end
Where GetSavedMode(name) retrieves the config mode selected by the user (using the controller GUI). This probably has to be saved in a SV and libraries can't do that.
Edit: on second thoughts, I deleted my previous post . I think I misunderstood xbeeps.
So xbeeps, why would you have OneButtonConfig as a library.
It was more like i was expecting it to be a library based on the previous discussion. I did not expect that a) it was supposed to save previous modes in a saved variable and b) that you intended multiple different implementations of controller addons. Considering those two points, it is sane to just stick with a simple specification of the contents of a global variable, that anyone create if it isn't there. It's brilliant :)
So how does one add the mods to be able to use this function? Do we, end users, have to wait for the authors to add it to the mods or we can modified the mod ourself? If we can modify ourself where do we add the codes?
Great idea, love to be able to lay out my UI in one click.
So how does one add the mods to be able to use this function? Do we, end users, have to wait for the authors to add it to the mods or we can modified the mod ourself? If we can modify ourself where do we add the codes?
Great idea, love to be able to lay out my UI in one click.
If you want support for an addon you use, you should mention the configmode spec to your addon developer: http://www.wowwiki.com/ConfigMode
It's not something you'll add easily yourself since you will need to know a fair amount of Lua, and also understand the inner workings of the addon in question.
Ok, I like this. It is clean and simple and AutoBar now supports the basic mode.
However there are issues: entering move bar mode activates LibStickyFrames-2.0 move mode.
Canceling it using AutoBar methods leaves configmode partly enabled. This can be fixed via a callback to the controller. This can either be passed as a parameter, or it can add a "well known" func to each mod it activates.
I am unclear how the extended modes should work. For AutoBar, there is move the buttons around as well as activate LibKeyBound-1.0
Should there be a reserved token for button wrangling so it syncs up across mods?
As for key binding, it is much better handled by LibKeyBound-1.0
Final note, I do still want some kind of docking / relative positioning functionality when dragging some stuff around. For instance, I stick some AutoBar bars to the Grid frame so I can see spell cooldowns etc. right there.
Do not bother with LibKeyBound-1.0, it is quite out of the scope IMO of the configmode.
Having the possibility to lock AutoBar (or any other frame for that matter) without disabling the configmode isn't an issue either. It is a feature. One could want to unlock all frames then lock them one by one. You could see ConfigMode as an helper to switch the lock trigger of every addons "ON" or "OFF" at the same time.
-
View User Profile
-
View Posts
-
Send Message
Forum Moderator1) "Config Mode" was what I had in mind personally
2) Yes, very soon. I can certainly do this.
3) Nice catch. Yes, a TOC directive that the controller addon can scan for seems like the sanest option. Maybe just "X-ConfigMode: true" then?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWhat about a general "X-ConfigMode" and an optional "X-ConfigMode-Modes". This way there is no need to load the addon until we need to activate the config mode.
One could argue that we could use the same TOC entry : "X-ConfigMode: true" and "X-ConfigMode: mode1, mode2, mode3". I find it less clear but yet acceptable.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorSeems a bit overkill for me. How often are you expecting to do this that (maybe) avoiding loading a few addons are going to make an actual impact on your gameplay? :P
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSo why making LoadOnDemand addons at all ?
We can still just keep the "simple" TOC entry but it means we cannot have any multimodal load-on-demand addon as using "GETMODES" involves loading it.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorAlso I don't quite follow your discussion about selecting which ones load via their config mode selection. I mean, whether you want to see the party mode or raid mode of an UF addon doesn't mean you don't want to load it?
Your configmode controlling addon could certainly have SETS of addons to config-enable (and thus load). And with different parameters. But this again does not match any values returned from "GETMODES".
This is effectively a library, you're just forcing it to be disembedded (it is standalone, and no libstub wrapping), and only providing a primitive interface to the addons (modifying global variables).
I know that no more is "needed", but that could be said of any library. I could implement LibHealComm-3.0 as a standalone addon, and just let users access some global variables in it.
The thing that makes a difference is that it is going to be used by multiple addons. That is what sets a library apart from an addon.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSo xbeeps, why would you have OneButtonConfig as a library. The core function looks like this:
if enable then -- Enable all config modes for name, callback in pairs(CONFIGMODE_CALLBACKS) do local mode = callback("GETMODES") if mode ~= nil then -- Multimode, try to get the user-selected mode -- or use the first mode as the default one mode = GetSavedMode(name) or mode end callback("ON", mode) end else -- Disable all config modes for name, callback in pairs(CONFIGMODE_CALLBACKS) do callback("OFF") end endWhere GetSavedMode(name) retrieves the config mode selected by the user (using the controller GUI). This probably has to be saved in a SV and libraries can't do that.
-
View User Profile
-
View Posts
-
Send Message
Forum Moderatorhttp://www.wowwiki.com/ConfigMode
It was more like i was expecting it to be a library based on the previous discussion. I did not expect that a) it was supposed to save previous modes in a saved variable and b) that you intended multiple different implementations of controller addons. Considering those two points, it is sane to just stick with a simple specification of the contents of a global variable, that anyone create if it isn't there. It's brilliant :)
Great idea, love to be able to lay out my UI in one click.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorIf you want support for an addon you use, you should mention the configmode spec to your addon developer: http://www.wowwiki.com/ConfigMode
It's not something you'll add easily yourself since you will need to know a fair amount of Lua, and also understand the inner workings of the addon in question.
However there are issues: entering move bar mode activates LibStickyFrames-2.0 move mode.
Canceling it using AutoBar methods leaves configmode partly enabled. This can be fixed via a callback to the controller. This can either be passed as a parameter, or it can add a "well known" func to each mod it activates.
I am unclear how the extended modes should work. For AutoBar, there is move the buttons around as well as activate LibKeyBound-1.0
Should there be a reserved token for button wrangling so it syncs up across mods?
As for key binding, it is much better handled by LibKeyBound-1.0
Final note, I do still want some kind of docking / relative positioning functionality when dragging some stuff around. For instance, I stick some AutoBar bars to the Grid frame so I can see spell cooldowns etc. right there.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHaving the possibility to lock AutoBar (or any other frame for that matter) without disabling the configmode isn't an issue either. It is a feature. One could want to unlock all frames then lock them one by one. You could see ConfigMode as an helper to switch the lock trigger of every addons "ON" or "OFF" at the same time.
-
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
Forum ModeratorUnless you want people to ignore it further into oblivion.
-
View User Profile
-
View Posts
-
Send Message
Forum Moderator