I am going to release the first version of this soon. It is not fully implemented yet, however the mod is mostly back to where it was before the conversion. A beta will be tagged before this so it is easy to revert to a working version while the alpha stabilizes.
Design goals:
*Completely separate the runtime code and the Grid2DB saved variable it uses from what happens during options editing.
*Layer the settings so it is faster to change settings for all your characters as well as make specific changes to particular classes / specs.
*Hide all the complexity on the editing side and export simple flat table settings for Grid2 itself to use.
Features:
*Editing information is kept in Grid2OptionsDB and edited using Grid2Options (load on demand)
*All plugins follow the same pattern, with their own separate editing mod.
*Versioning info resides in Grid2DB. Old or nonexistent versions cause options to load and apply their defaults. This happens on first loads of the mod and or plugins, and subsequent loads when new defaults have been added.
*On the options side, settings are layered. So for instance account / class / spec settings.
*Layered settings are flattened into exactly what is needed for each character / spec by Grid2.
*Grid2 uses exactly these tables as is. No defaulting as in AceDB. Defaults are now a function of the editing side.
Completed:
-Almost everything uses the new scheme. This fixes the many issues with settings not saving.
-All classes now generate class specific settings on first login and use those. This allows Grid2 to be used on multiple class types.
-Indicators / Statuses / Locations now have a suffix showing their layer.
Unfinished:
-UI for changing the layer of specific objects. For now they are hard coded.
-Code to switch between specs. Settings will be present in Grid2 for multiple specs. There needs to be code to do the switch which may involve disabling / deleting / enabling / etc. various indicators and statuses. All objects in the core now have a Create function where this magic can happen.
-Move the remaining old style settings over. (Frame, layouts, blink, etc.)
-UI for tri-state objects other than checkboxes (which already have that). For example a checkbox can have the values: "checked", "unchecked", "use parent layer value". So for a setting like "Include Player Heals" if the druid setting is checked or unchecked then player heals are included / not included. If however it is "use parent layer value", then whatever is set at the account level is used.
-UI for morphing the creatable indicators. So for instance being able to change an indicator to be text / icon / square directly. This allows it to keep its statuses that work with the new type. Currently it requires a tedious deleting of the old one, creation of the new one and re-adding its statuses.
-The layered code resides in LibDBLayers. This needs additional work / streamlining / refactoring to make it cleaner to use.
r343 is a working version.
*It requires all plugins to be updated as well.
*It works for druids for sure. I have been raiding with it. For most classes it is untested.
*Before resetting SV or clicking Debugging/Reset you should be able to go back to the beta with its settings still intact.
What is different is that most statuses and indicators you create now also have a layer setting. It is a choice between account / class / spec (for healers only atm).
*Changes you make to account layers apply to all characters.
*Changes you make to class layers override settings in account.
*Spec settings are basically custom to that class & spec.
As an example, if you create a square indicator at the account layer and choose a location of side-left for it you will see a (temporary) white square on the left side.
Hook up a status to it. For example PvP or AFK. Toggle pvp or /afk to see the color change.
Now change the layer to your class layer. Change the size of the indicator you created. Switching between the layers will change between the two sizes of the different layers.
Logging into another character will give you their default settings as well as the account settings for your new indicator.
Interesting. I understand the problem you're trying to solve. I know that with many other mods aceDB doesn't cut it, you end up making one set of settings, copying it to all your profiles then adjusting each one repeatedly.
Now I'll confess at this stage that when I first heard of your layer idea was was very sceptical. The key concern being that layers are potentially fiendishly complex - how on earth can the configuration be managed sanely? However on refleting on what you've put in now I see that it can be made workable. And, crucially, it's no worse than the current AceDB profile nonsense [account->realm->class, I mean seriously who uses per-realm settings? and why no per-spec settings?!]
Still, there is one really good point about AceDB Profiles - That is: If you've no idea what Profiles are - it doesn't matter! I'll bet that most users of most mods never touch the profile settings. They just adjust settings and the changes get saved. End of story.
So - could I suggest that rather than automagically creating layers for every possible class / spec, you keep the default layers to a minimum for basic users, whilst allowing advanced users the ability to make layers however they want? Case in point, the layers currently are account->class->spec, but I'd want account->heal->Paladin and I'm sure others would want different things.
The simplest default would just be one layer: account. The downside of this is it limits the out-of-the-box functionality since you'd have to settle on lowest common denominator settings. Still it could be done, maybe there could be a set of prefab settings that the user could choose from? Do people use out-of-the-box Grid anyhow?
Well, it took forever to implement because it is easy to let the complexity get out of hand. This is about the 5th rewrite. I am happy with it though, it requires minimal change to the core. In fact, it only requires what is needed to be able to change specs. This actual spec changing & creation still needs to be implemented though.
The big thing I am after is specs, and later on perhaps boss specific settings. This can be solved by endless cutting and pasting of profiles as you point out. I have enough characters that that is extremely unsatisfying and in fact not practical though. Layers provide a simpler alternative.
"account->heal->Paladin". I thought about doing a healer layer. The settings for healers that are neither in account nor class is tiny though. So the compromise is to keep account and class layers set in stone with a bit of duplication across them. There likely needs to be a "dps" layer as well though so this may get revisited.
Monkeying around with enabling or disabling layers buys nothing except the conditional removal of the layer dropdown. There really is no difference between a basic user and an advanced user except that advanced users change a lot of settings. Well the good news here is that unlike the old Grid, Grid2 comes with strong defaults that provide a fully working raid frame out of the box for basic users. This lets you see something that already works and then adjust it to taste if necessary.
"The simplest default would just be one layer: account. The downside of this is it limits the out-of-the-box functionality since you'd have to settle on lowest common denominator settings."
I think having layered settings and not being shy about it by trying to hide it is better. It is a learning curve as you point out, but I think it is a smaller learning curve than regular Grid config. Layers are also ignorable to a large extent. You only need to know how they work if you want to make class or spec specific changes. You buy an exact setup for your class / spec at the cost of a layer setting in the config.
"prefab settings" these can be provided by options only plugins either way.
Gaff3: By the way I upgraded your Dungeon Role status. I will probably move the opacity code to the core and spread it around to some other statuses.
One question about it though: perhaps it should be modified to change the alpha on the colors themselves (color1 ... color n). That way it acts as a bulk alpha changer instead of replacing the alpha settings?
I'm not quite with you. For me the difference between account->heal and account->dps is that the former takes up 30% of my screen and shows lots of info, while the latter is small and shows only range and raidebuff. That's quite a fundamental difference! I don't know if you've extended layers to cover frame / layout settings but I assume that's on your wish-list?
The point of layers surely is that everyone will have their own view of how to arrange them. If you mandate account->class->spec, well that's the mistake wowdb profiles made.
I kinda imagine it this way: Grid2 would have a layer settings panel where you can add layers to the layer heirarchy however you choose. On this panel you also configure what layer your current character / spec is set to. I think this will satisfy everyone. The other nice thing about this is that if I want to change my current layer I can do that without changing spec.
Does this make sense to you?
Re: Opacity
Thanks for fixing dungeonrole. Feel free to propogate / modify opacity. Personally what you suggest seems like an implementation detail to me. The only win is if you wanted, say, different opacities on different raid icons (skull 0.8, cross 0.6 etc) or similar then my opacity implementation doesn't allow this - but honestly can you think of any time you'd want something like this? Still it's fine by me if you want to do the work :P
...the difference between account->heal and account->dps is that the former takes up 30% of my screen and shows lots of info, while the latter is small and shows only range and raidebuff...
Sizing is still using the old stuff and needs to be converted. I am thinking it would have an account setting (basic defaults) and then a set of choices at the next layer maybe. Several things need to work though. larger heal vs compact dps layouts, the classic inverted health scheme etc. So layer wise it would be account / <some set of choices>.
Some kind of raid leader package needs to be implemented. This part is interesting in that it potentially means multiple inheritance. It could also just be a plugin that depends on a particular set of Grid2 plugins and sets them up consistently with a few button clicks and choices. This avoids the complexity. So for instance it may require Grid2StatusTargetIcon and set them up a particular way.
This part is interesting in that it potentially means multiple inheritance.
Eeek! You say that like it's a good thing :o
I understand your point, you're saying you may wish to configure the frame settings independantly to the indicator settings. But equally I'm sure you acknowledge things could get very confusing very quickly. Layered settings are very new, and I think it's important to get the basics right first, before looking at this stuff. I actually have a much neater solution to this problem, but let's save that for another thread rather than derail this one.
The obvious thing (in my mind) is that frame and layout also have a layer associated with them (just like indicators). Then I can configure my layers: account->heal->paladin, or account->raid leader->warlock and the frame sizes will do what I expect.
Rather than trying to work our what the perfect layer configuration might be. What do you think of my idea of having a panel for configuring whatever layers the user wants, and what layer the current class / spec should be set to? I think this is a much stronger solution.
Haha no, while i like multiple inheritance in code, there is no way I want it here. The alternative, where a plugin has options to apply a set of defaults via code is more to my taste.
The actual layer lib supports two types at the moment: layers and mappings between two layers. Likely a third type would be supported that simply provides a choice without layers. That is, something identical to AceDB.
To provide defaults in that scenario there would be a defaults system layered on top of everything. So basically each individual object type would register a default which would be the first layer that gets flattened (ie it resides above account etc.) This is already on the ToDo list since currently such defaults were moved into the objects themselves in order to get something working.
... a panel for configuring whatever layers the user wants, and what layer the current class / spec should be set to? I think this is a much stronger solution.
The actual lib already supports this. However I just do not know if it is something we want users to do. It is maybe ok for a math phd, but we need this to work for regular users as well.
The bottom line is this: are there enough and appropriate layers to solve 95% of the issues. If your heal / dps layer is added between account and class I think the answer is yes.
The actual lib already supports this. However I just do not know if it is something we want users to do. It is maybe ok for a math phd, but we need this to work for regular users as well.
The bottom line is this: are there enough and appropriate layers to solve 95% of the issues. If your heal / dps layer is added between account and class I think the answer is yes.
Cool.
Remember at heart I'm a proponent of using 1 layer all the time, with an option - for every advanced users only - to add additional layers. I think that shipping with account->heal->paladin is a really poor idea, and account->paladin->holy is just as bad. I think it needs to be as simple as it possibly can.
If one layer is too trivial, could we at least limit it to account-><class> out of the box?
...If one layer is too trivial, could we at least limit it to account-><class> out of the box?
I think you need to think this through from the following design goals:
1) The runtime is completely separate from the load on demand options. it includes only the necessary code and data for Grid2 to work (after initial setup) without loading any options. The goal is performance.
2) Grid2 has strong working defaults. Grid2 and its enabled plugins automatically configure themselves into a working configuration with no setup required other than maybe sizing and placing frames to your choice. The goal is a working setup using your chosen plugins, customized for your class / spec.
3) Since Options are separate and load on demand we are not concerned with code size / complexity etc. except as it impacts maintainability. The goal is to save setup time.
Everything else is optional. You can completely rearrange all indicators and statuses to taste.
Now how will this eventually work out. I think for dps classes you will get account / dps / class settings. Class will likely be limited to the raid buffs your class can provide, and show on units that lack your raid buff or its equivalent. With other words account / dps will be the setup with possibly some class specific stuff. Note that currently dps classes show all kinds of stuff that will go away.
For heal classes the current setups acquire a heal layer. So account / heal / class / spec. Multiple specs can be set up / chosen from by default. Perhaps the options even sniff your actual spec to figure out what to choose for initial setup.
Now imagine that instead you only have one layer like account. Well now what. Nothing works unless you only have one character. Or you are back to having to set it up from scratch like in Grid. This is unacceptable imo. Even a two layer scheme is bogus. account / heal and account / dps may allow dps classes a mostly complete setup but it totally shafts healers.
Your proposal breaks everything that is good about Grid2Options (point 2 above). Worse, if somehow you set up into some limited layer scheme, what happens when someone chooses all 4 layers? They are now looking at a setup mangled into 1 or 2 layers and somehow the code has to back that out and set it up for 4 layers and still respect the choices they already made. Ugh, no thank you, this is not an AI project.
Worse, with only 1 or 2 layers that means all settings for multiple characters bleed into each other. Or the settings are account / custom or just plain custom for each character. Well at that point you have just implemented AceDB right?
Lets look at it from a different perspective as well. Install SOCD (Sick of Clicking Dailies). This is an absolutely wonderful mod and saves me from doing stupid useless clicking in the blizzard interface. By default it sets up an AceDB with (unfortunately) individual settings per character. This is easily changed to using the same profile though at which point the power of AceDB shines through because it excels at a single setup across all characters.
Now contrast that with Grid & Grid2. It is totally unworkable because you have individual settings, especially for the heal classes. You can go with an AceDB approach like Grid with individual settings per class and spec. That sadly makes users manually spread global changes around though.
While I can see the merit in both ideas, if Grid2 were shipped with a global account layer, by default, what specific information would conflict between one person using a healer and one person using a dps class? If the current setup is any indication, a lot of things are only shown if they are your own buff.
...if Grid2 were shipped with a global account layer, by default, what specific information would conflict between one person using a healer and one person using a dps class?...
Let us imagine a warrior, druid, shaman, paladin and priest sharing an account and thus having their options lumped together.
The buffs which default to side bottom would work for the particular class. So for druids the brown square goes away if thorns is present and the yellow one goes away if mark is present. The buffs from all the other classes will also go away IF such a class is in the group / raid and they do the buff. Otherwise there will be a large layer of stuff there that will never go away. Worse, there is no account specific settings, so one of these "dead" statuses would be the top layer and obscure the other ones.
Now move on to the other stuff. All the druid stuff gets added. Now as you point out this is not fatal, it only shows if you cast the spell for most of them. Swiftmend would always be there if there is a rejuv or regrowth on a unit. Similarly the various paladin and priest shields will always show. The dispellable curse / poison / magic / disease will be some combination based on the classes you have logged in with and have nothing to do with your class.
Meanwhile the poor warrior just wants to see aggro so she can intervene / taunt or whatnot + Battle Shout or Commanding Shout not being up for someone so it can get reapplied. Instead she is seeing some random set of stuff of interest only to specific healers. In addition, the grid is gigantic to accommodate healer settings instead of tiny and warrior specific.
Lets imagine that we rewrite all these so that they magically do different things based on which class is using them. You can get close to a reasonable setup but each status now has custom settings for each class. Oh wait, the layer thing already gives us that.
The bottom line is this. You can go the old Grid route with separate settings for each class / spec. There is no sharing of common settings. There is no making minor tweaks of a basic setup to get to a custom class setup. There is just a game of making some setup, copying it around and tweaking it. If you want to make major changes you repeat that or individually log each class and repeat the same changes a number of times.
Or you can have a layered scheme that lets global settings be global; class settings be class specific; custom settings be custom. All of which coexist happily. If you are having a setup issue with some character you look at settings for that character and fix it. You do not have to debug some ridiculously complex setup which could potentially be 18 specs per server.
Ahah, apologies - I was thinking a lot of the class specific buffs would be hidden by using 'buff-mine', forgetting that would then cause problems if, say, another druid in the raid buffed GOTW, which would then show you as not having applied it. (not to mention class specific debuff detection for removal)
2) Grid2 has strong working defaults. Grid2 and its enabled plugins automatically configure themselves into a working configuration with no setup required other than maybe sizing and placing frames to your choice. The goal is a working setup using your chosen plugins, customized for your class / spec.
I completely accept your point. If we ship with one layer we break the current Grid2 out-of-the-box settings. I'm just saying that in an ideal world we'd avoid the complexity of layers for novice users. Sadly I don't have a perfect solution.
However it is definitely possible to ship with one layer common to all (say just health bar, debuff icon, and agro indicator). The win is that new users don't have to worry about layers, the loss is that out of the box grid2 isn't so useful.
So is the tradeoff worth it? Well that's always going to be subjective. At what piont do you say this is adding too much complexity out-of-the-box without helping enough?
Design goals:
*Completely separate the runtime code and the Grid2DB saved variable it uses from what happens during options editing.
*Layer the settings so it is faster to change settings for all your characters as well as make specific changes to particular classes / specs.
*Hide all the complexity on the editing side and export simple flat table settings for Grid2 itself to use.
Features:
*Editing information is kept in Grid2OptionsDB and edited using Grid2Options (load on demand)
*All plugins follow the same pattern, with their own separate editing mod.
*Versioning info resides in Grid2DB. Old or nonexistent versions cause options to load and apply their defaults. This happens on first loads of the mod and or plugins, and subsequent loads when new defaults have been added.
*On the options side, settings are layered. So for instance account / class / spec settings.
*Layered settings are flattened into exactly what is needed for each character / spec by Grid2.
*Grid2 uses exactly these tables as is. No defaulting as in AceDB. Defaults are now a function of the editing side.
Completed:
-Almost everything uses the new scheme. This fixes the many issues with settings not saving.
-All classes now generate class specific settings on first login and use those. This allows Grid2 to be used on multiple class types.
-Indicators / Statuses / Locations now have a suffix showing their layer.
Unfinished:
-UI for changing the layer of specific objects. For now they are hard coded.
-Code to switch between specs. Settings will be present in Grid2 for multiple specs. There needs to be code to do the switch which may involve disabling / deleting / enabling / etc. various indicators and statuses. All objects in the core now have a Create function where this magic can happen.
-Move the remaining old style settings over. (Frame, layouts, blink, etc.)
-UI for tri-state objects other than checkboxes (which already have that). For example a checkbox can have the values: "checked", "unchecked", "use parent layer value". So for a setting like "Include Player Heals" if the druid setting is checked or unchecked then player heals are included / not included. If however it is "use parent layer value", then whatever is set at the account level is used.
-UI for morphing the creatable indicators. So for instance being able to change an indicator to be text / icon / square directly. This allows it to keep its statuses that work with the new type. Currently it requires a tedious deleting of the old one, creation of the new one and re-adding its statuses.
-The layered code resides in LibDBLayers. This needs additional work / streamlining / refactoring to make it cleaner to use.
*It requires all plugins to be updated as well.
*It works for druids for sure. I have been raiding with it. For most classes it is untested.
*Before resetting SV or clicking Debugging/Reset you should be able to go back to the beta with its settings still intact.
What is different is that most statuses and indicators you create now also have a layer setting. It is a choice between account / class / spec (for healers only atm).
*Changes you make to account layers apply to all characters.
*Changes you make to class layers override settings in account.
*Spec settings are basically custom to that class & spec.
As an example, if you create a square indicator at the account layer and choose a location of side-left for it you will see a (temporary) white square on the left side.
Hook up a status to it. For example PvP or AFK. Toggle pvp or /afk to see the color change.
Now change the layer to your class layer. Change the size of the indicator you created. Switching between the layers will change between the two sizes of the different layers.
Logging into another character will give you their default settings as well as the account settings for your new indicator.
Now I'll confess at this stage that when I first heard of your layer idea was was very sceptical. The key concern being that layers are potentially fiendishly complex - how on earth can the configuration be managed sanely? However on refleting on what you've put in now I see that it can be made workable. And, crucially, it's no worse than the current AceDB profile nonsense [account->realm->class, I mean seriously who uses per-realm settings? and why no per-spec settings?!]
Still, there is one really good point about AceDB Profiles - That is: If you've no idea what Profiles are - it doesn't matter! I'll bet that most users of most mods never touch the profile settings. They just adjust settings and the changes get saved. End of story.
So - could I suggest that rather than automagically creating layers for every possible class / spec, you keep the default layers to a minimum for basic users, whilst allowing advanced users the ability to make layers however they want? Case in point, the layers currently are account->class->spec, but I'd want account->heal->Paladin and I'm sure others would want different things.
The simplest default would just be one layer: account. The downside of this is it limits the out-of-the-box functionality since you'd have to settle on lowest common denominator settings. Still it could be done, maybe there could be a set of prefab settings that the user could choose from? Do people use out-of-the-box Grid anyhow?
Any thoughts?
The big thing I am after is specs, and later on perhaps boss specific settings. This can be solved by endless cutting and pasting of profiles as you point out. I have enough characters that that is extremely unsatisfying and in fact not practical though. Layers provide a simpler alternative.
"account->heal->Paladin". I thought about doing a healer layer. The settings for healers that are neither in account nor class is tiny though. So the compromise is to keep account and class layers set in stone with a bit of duplication across them. There likely needs to be a "dps" layer as well though so this may get revisited.
Monkeying around with enabling or disabling layers buys nothing except the conditional removal of the layer dropdown. There really is no difference between a basic user and an advanced user except that advanced users change a lot of settings. Well the good news here is that unlike the old Grid, Grid2 comes with strong defaults that provide a fully working raid frame out of the box for basic users. This lets you see something that already works and then adjust it to taste if necessary.
"The simplest default would just be one layer: account. The downside of this is it limits the out-of-the-box functionality since you'd have to settle on lowest common denominator settings."
I think having layered settings and not being shy about it by trying to hide it is better. It is a learning curve as you point out, but I think it is a smaller learning curve than regular Grid config. Layers are also ignorable to a large extent. You only need to know how they work if you want to make class or spec specific changes. You buy an exact setup for your class / spec at the cost of a layer setting in the config.
"prefab settings" these can be provided by options only plugins either way.
One question about it though: perhaps it should be modified to change the alpha on the colors themselves (color1 ... color n). That way it acts as a bulk alpha changer instead of replacing the alpha settings?
I'm not quite with you. For me the difference between account->heal and account->dps is that the former takes up 30% of my screen and shows lots of info, while the latter is small and shows only range and raidebuff. That's quite a fundamental difference! I don't know if you've extended layers to cover frame / layout settings but I assume that's on your wish-list?
The point of layers surely is that everyone will have their own view of how to arrange them. If you mandate account->class->spec, well that's the mistake wowdb profiles made.
I kinda imagine it this way: Grid2 would have a layer settings panel where you can add layers to the layer heirarchy however you choose. On this panel you also configure what layer your current character / spec is set to. I think this will satisfy everyone. The other nice thing about this is that if I want to change my current layer I can do that without changing spec.
Does this make sense to you?
Re: Opacity
Thanks for fixing dungeonrole. Feel free to propogate / modify opacity. Personally what you suggest seems like an implementation detail to me. The only win is if you wanted, say, different opacities on different raid icons (skull 0.8, cross 0.6 etc) or similar then my opacity implementation doesn't allow this - but honestly can you think of any time you'd want something like this? Still it's fine by me if you want to do the work :P
Sizing is still using the old stuff and needs to be converted. I am thinking it would have an account setting (basic defaults) and then a set of choices at the next layer maybe. Several things need to work though. larger heal vs compact dps layouts, the classic inverted health scheme etc. So layer wise it would be account / <some set of choices>.
Some kind of raid leader package needs to be implemented. This part is interesting in that it potentially means multiple inheritance. It could also just be a plugin that depends on a particular set of Grid2 plugins and sets them up consistently with a few button clicks and choices. This avoids the complexity. So for instance it may require Grid2StatusTargetIcon and set them up a particular way.
Eeek! You say that like it's a good thing :o
I understand your point, you're saying you may wish to configure the frame settings independantly to the indicator settings. But equally I'm sure you acknowledge things could get very confusing very quickly. Layered settings are very new, and I think it's important to get the basics right first, before looking at this stuff. I actually have a much neater solution to this problem, but let's save that for another thread rather than derail this one.
The obvious thing (in my mind) is that frame and layout also have a layer associated with them (just like indicators). Then I can configure my layers: account->heal->paladin, or account->raid leader->warlock and the frame sizes will do what I expect.
Rather than trying to work our what the perfect layer configuration might be. What do you think of my idea of having a panel for configuring whatever layers the user wants, and what layer the current class / spec should be set to? I think this is a much stronger solution.
The actual layer lib supports two types at the moment: layers and mappings between two layers. Likely a third type would be supported that simply provides a choice without layers. That is, something identical to AceDB.
To provide defaults in that scenario there would be a defaults system layered on top of everything. So basically each individual object type would register a default which would be the first layer that gets flattened (ie it resides above account etc.) This is already on the ToDo list since currently such defaults were moved into the objects themselves in order to get something working.
The actual lib already supports this. However I just do not know if it is something we want users to do. It is maybe ok for a math phd, but we need this to work for regular users as well.
The bottom line is this: are there enough and appropriate layers to solve 95% of the issues. If your heal / dps layer is added between account and class I think the answer is yes.
Cool.
Remember at heart I'm a proponent of using 1 layer all the time, with an option - for every advanced users only - to add additional layers. I think that shipping with account->heal->paladin is a really poor idea, and account->paladin->holy is just as bad. I think it needs to be as simple as it possibly can.
If one layer is too trivial, could we at least limit it to account-><class> out of the box?
I think you need to think this through from the following design goals:
1) The runtime is completely separate from the load on demand options. it includes only the necessary code and data for Grid2 to work (after initial setup) without loading any options. The goal is performance.
2) Grid2 has strong working defaults. Grid2 and its enabled plugins automatically configure themselves into a working configuration with no setup required other than maybe sizing and placing frames to your choice. The goal is a working setup using your chosen plugins, customized for your class / spec.
3) Since Options are separate and load on demand we are not concerned with code size / complexity etc. except as it impacts maintainability. The goal is to save setup time.
Everything else is optional. You can completely rearrange all indicators and statuses to taste.
Now how will this eventually work out. I think for dps classes you will get account / dps / class settings. Class will likely be limited to the raid buffs your class can provide, and show on units that lack your raid buff or its equivalent. With other words account / dps will be the setup with possibly some class specific stuff. Note that currently dps classes show all kinds of stuff that will go away.
For heal classes the current setups acquire a heal layer. So account / heal / class / spec. Multiple specs can be set up / chosen from by default. Perhaps the options even sniff your actual spec to figure out what to choose for initial setup.
Now imagine that instead you only have one layer like account. Well now what. Nothing works unless you only have one character. Or you are back to having to set it up from scratch like in Grid. This is unacceptable imo. Even a two layer scheme is bogus. account / heal and account / dps may allow dps classes a mostly complete setup but it totally shafts healers.
Your proposal breaks everything that is good about Grid2Options (point 2 above). Worse, if somehow you set up into some limited layer scheme, what happens when someone chooses all 4 layers? They are now looking at a setup mangled into 1 or 2 layers and somehow the code has to back that out and set it up for 4 layers and still respect the choices they already made. Ugh, no thank you, this is not an AI project.
Worse, with only 1 or 2 layers that means all settings for multiple characters bleed into each other. Or the settings are account / custom or just plain custom for each character. Well at that point you have just implemented AceDB right?
Lets look at it from a different perspective as well. Install SOCD (Sick of Clicking Dailies). This is an absolutely wonderful mod and saves me from doing stupid useless clicking in the blizzard interface. By default it sets up an AceDB with (unfortunately) individual settings per character. This is easily changed to using the same profile though at which point the power of AceDB shines through because it excels at a single setup across all characters.
Now contrast that with Grid & Grid2. It is totally unworkable because you have individual settings, especially for the heal classes. You can go with an AceDB approach like Grid with individual settings per class and spec. That sadly makes users manually spread global changes around though.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumLet us imagine a warrior, druid, shaman, paladin and priest sharing an account and thus having their options lumped together.
The buffs which default to side bottom would work for the particular class. So for druids the brown square goes away if thorns is present and the yellow one goes away if mark is present. The buffs from all the other classes will also go away IF such a class is in the group / raid and they do the buff. Otherwise there will be a large layer of stuff there that will never go away. Worse, there is no account specific settings, so one of these "dead" statuses would be the top layer and obscure the other ones.
Now move on to the other stuff. All the druid stuff gets added. Now as you point out this is not fatal, it only shows if you cast the spell for most of them. Swiftmend would always be there if there is a rejuv or regrowth on a unit. Similarly the various paladin and priest shields will always show. The dispellable curse / poison / magic / disease will be some combination based on the classes you have logged in with and have nothing to do with your class.
Meanwhile the poor warrior just wants to see aggro so she can intervene / taunt or whatnot + Battle Shout or Commanding Shout not being up for someone so it can get reapplied. Instead she is seeing some random set of stuff of interest only to specific healers. In addition, the grid is gigantic to accommodate healer settings instead of tiny and warrior specific.
Lets imagine that we rewrite all these so that they magically do different things based on which class is using them. You can get close to a reasonable setup but each status now has custom settings for each class. Oh wait, the layer thing already gives us that.
The bottom line is this. You can go the old Grid route with separate settings for each class / spec. There is no sharing of common settings. There is no making minor tweaks of a basic setup to get to a custom class setup. There is just a game of making some setup, copying it around and tweaking it. If you want to make major changes you repeat that or individually log each class and repeat the same changes a number of times.
Or you can have a layered scheme that lets global settings be global; class settings be class specific; custom settings be custom. All of which coexist happily. If you are having a setup issue with some character you look at settings for that character and fix it. You do not have to debug some ridiculously complex setup which could potentially be 18 specs per server.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI completely accept your point. If we ship with one layer we break the current Grid2 out-of-the-box settings. I'm just saying that in an ideal world we'd avoid the complexity of layers for novice users. Sadly I don't have a perfect solution.
However it is definitely possible to ship with one layer common to all (say just health bar, debuff icon, and agro indicator). The win is that new users don't have to worry about layers, the loss is that out of the box grid2 isn't so useful.
So is the tradeoff worth it? Well that's always going to be subjective. At what piont do you say this is adding too much complexity out-of-the-box without helping enough?