...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.
...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.
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.
...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.
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?
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.
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.
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.
*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.
*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.
-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.
-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.