Grid2 universal / shared settings

[Azethoth]

This thread is to deal with what if any deviations from the standard profile system there should be in Grid2. It will also concern itself with alternative ways to deal with the issues without having to deviate from the standard profile system.

So what is the problem with the standard profile system? Basically it is good for the following scenarios:
1) I only have 1 character and so profiles are irrelevant to me. This will become less valid with 3.1 and the multi-spec system Blizzard is introducing. At the very least a Grid2 config for Druid/Tree can be quite different for Druid/Bear or Druid/Cat for example.
2) I have multiple characters each with their own individual config.

What it is no good at is sharing of config components across multiple characters. For instance it is likely that you would want to use the same scale, orientation, size, coloring, bar-inversion etc. settings across multiple characters. While you can set up one character with settings you like and then copy its config around and then modify it for other characters, changes you subsequently make are not shared.

So that is what this thread is about:
*How to make universal / shared settings that update across multiple characters/specs.
*How fine grained this should be. That is per individual attribute, or per a cluster of attributes?
*What sorts of things want to be shared?

Participants in this thread are those who want to share parts of their config across characters or feel they can contribute ideas about how to do it effectively.

Now to hopefully avoid unnecessary controversy up front, if you are well served by the existing profile system since you are in scenario 1) or 2), then please note that your usage case will not be broken or disabled by anything that comes out of this. This means posts about how you still want to be able to do scenario 1) or 2) are unnecessary. Also, we do not need posts about how you think config should only allow scenarios 1) and 2)

[Phanx]

If you want to do this, I think you should avoid using the Ace profile system at all, and write your own from scratch, to avoid confusion. Then, do the following:

• Have a default baseline configuration with settings suitable for all classes and specs. These settings are always applied first when a user logs in on any character.
• Have a default per-character configuration for different classes/specs as appropriate with only settings that are different from the baseline configuration. For instance, a resto druid needs to see more granular HoT information than a balance or feral druid; moonkins and kitties could use the same class defaults, while trees would have a different one. The first time a character was logged in, it would be assigned a configuration based on its current spec.
• Any changes a user makes are made to the per-character configuration.

For user control:

• All statuses should be available to all configurations. If a user adds a specific buff or debuff on one profile, he shouldn't have to add it again and again to get it on other profiles. Same goes for colors and all other status settings. Statuses don't need the "Enabled" setting; if they aren't assigned to any indicators, consider them not enabled.
• Allow users to save their current configuration as the baseline configuration to propigate changes to other characters, with options to include frame/layout settings, indicator/location settings, status-indicator assignments, or any combination of those.
• Allow users to switch between using character-specific, class-specific, or global non-baseline settings.
• Allow users to copy settings from one non-baseline profile to another.

As for dual-speccing... give users the option of switching between two specified profiles when switching specs, but leave this option disabled by default. It's never a good idea to let addons make changes to their configurations that have a noticable impact on the user's experience without the user's knowledge or consent.

Provide a brief, clearly worded explanation of the profile system and its usage in-game so that users don't have to flounder around trying to figure it out and/or search outside of the game for instructions.

[Azethoth]

The first things that are universally shared are locations. As currently implemented they are instantly and automatically shared (per account).

The only drawback is that you may want to have minor offset changes on a particular character for example. This would require creating new ones.

One solution is a character / universal toggle on the location so you can make changes to particular ones for a specific character.

Or since spec will become a consideration there could simply be a standard hierarchical selection from <custom>/spec/class/account. Account would be universal, class for all such classes, and spec likely being specific to this one character. <custom> would be created by the user or provided by default configs or via plugins.

Spec would probably be a choice among well know specs and something custom the user can type in somewhere.

So a usage example would be:

You have two characters named BB and CC, you are a first time Grid2 user or recently reset the Grid2 SV.

Grid2 defaults to a specific set of locations, all with their sharing attribute set to account. After logging in to BB you see this default set. You create new locations called side-bottom-left and side-bottom right. You anchor them to the bottom just like the side-bottom location, but offset them left and right of that location. They both default to account wide.

You log into CC. Both BB and CC are available as locations. Since your frames are rectangular on CC you decide that you want to space them out some more. You select the spec or class shared setting for them. You adjust their offsets.

Logging back into BB, the offsets for side-bottom-left and side-bottom right are unchanged since they are still set to account. You decide that you want to indulge your inner Renaissance Person and switch to a Golden Ratio aspect for its frames.

Luckily this is easy since someone has thoughtfully set up a Golden Ratio layout config already. You select Golden Ratio for your layout. This changes a particular set of properties. Perhaps you even get "gold" textures in various places and a golden backdrop for Grid. Certainly your unit frames now have a Golden Ratio aspect.

The two new locations you created do not have settings under Golden Ratio and so remain universal. You select Golden Ratio for each of them and adjust them to taste.

You like the looks of this and decide to upgrade CC to a Golden Ratio layout as well. You log into CC and select Golden Ratio for layout. The original set of properties for Golden Ratio are applied, as well as the two new locations which you provided values for under Golden Ratio.

[Azethoth]

I think our proposals are quite similar with the exception that mine requires no explicit copying. The issue I have with copying is that you can end up destroying information with an ill-conceived copy. This is also true for the sharing scheme but you are making finer grained changes so it is not as catastrophic. Either issue can be ameliorated by an undo scheme but I am not sure I want to go there at this point.

Originally Posted by Phanx

If you want to do this, I think you should avoid using the Ace profile system at all, and write your own from scratch, to avoid confusion...

I agree. Under the covers it would use its mechanisms, however it will not expose its normal profile settings.

Originally Posted by Phanx

...Have a default per-character configuration for different classes/specs as appropriate with only settings that are different from the baseline configuration. For instance, a resto druid needs to see more granular HoT information than a balance or feral druid; moonkins and kitties could use the same class defaults, while trees would have a different one. The first time a character was logged in, it would be assigned a configuration based on its current spec...

I think what you are saying is that there are layers to the defaults. Some things are by default global, and others are more specific to a class or spec. See the example posted below for how I propose to implement that.

Originally Posted by Phanx

...Any changes a user makes are made to the per-character configuration...

I think we can do better than that by allowing them to make changes at any layer.

Originally Posted by Phanx

...All statuses should be available to all configurations. If a user adds a specific buff or debuff on one profile, he shouldn't have to add it again and again to get it on other profiles. Same goes for colors and all other status settings. Statuses don't need the "Enabled" setting; if they aren't assigned to any indicators, consider them not enabled...

Absolutely. The infrastructure for this is already in place. Also "enabled" already works as you describe. You will not see an enabled setting in Grid2, it is done automatic for the people.

My proposal for sharing would let each indicator or status etc. have a choice as in the post below. The default is account wide which means they are automatically shared themselves and their settings are by default account wide but can be switched individually for minor changes without affecting everyone else.

As an example, this would allow lowmana to default to say 30%, but for a raid leader layout specifically it could be 50%.

Originally Posted by Phanx

...Provide a brief, clearly worded explanation of the profile system and its usage in-game so that users don't have to flounder around trying to figure it out and/or search outside of the game for instructions.

Good idea and I intend to do even better. I want all user documentation in the config and thus localized and available. Looking up outdated docs on a website is for the murlocs.

Iterating on the config would thus either generate updates to the UI with matching updates to the docs, or upgrades to the docs to clear up points of confusion.

UI elements with too much documentation are candidates for rewrite / simplification. The docs will not be a substitute for good design.

The Grid2 config being load on demand makes this practical, whereas it was not for Grid.

Originally Posted by Phanx

...Same goes for colors...

That reminds me, one of my pet peeves is the random color control with ace config settings. It displays no actual values so there is little chance of picking the same color twice even if you intend to. It is in fact impossible to pick identical colors in some areas of 24 bit color space, and trying to do so with the tiny patches provided split up in both time and space under variable ambient lighting conditions just increases these areas. Likely the entire space is screwed as a consequence.

This makes me contemplate a color patch system like you can find in Photoshop. Or maybe making a custom color control that shows the values at least and possibly allows selection of the standard web colors. Or maybe a drag and drop scheme so you can drag and drop between different patches in the config ... mmm, that almost has merit.

This is outside the scope of Grid2 config though. Maybe if I am bored someday or someone else is enterprising enough.

[MoonWitch]

Could we as base have a not so large Grid with a smaller amount of text (but larger in size)? Like it was a few revisions back?

[Phanx]

Originally Posted by Azethoth

I think we can do better than that by allowing them to make changes at any layer.

This is fine, but should default to the "highest" layer (character-specific etc), and if there are going to be more than two layers (baseline and changes) there should be an option to merge layers (i.e. if someone has made changes to the character-specific layer, they can move those changes to the class-specific layer). Personally I think there should only be two layers, only one of which is directly editable, since having multiple editable layers of configuration is just asking for confusion. At least include some clear indication of which layer is currently being edited, which is visible any time the user could be changing something.

Originally Posted by Azethoth

That reminds me, one of my pet peeves is the random color control with ace config settings. It displays no actual values so there is little chance of picking the same color twice even if you intend to. It is in fact impossible to pick identical colors in some areas of 24 bit color space, and trying to do so with the tiny patches provided split up in both time and space under variable ambient lighting conditions just increases these areas. Likely the entire space is screwed as a consequence.

EnhancedColourPicker already provides numeric input as well as copy/paste functions. It does use the aging Ace2 framework, though, and has some annoying bugs (such as considering the alpha input as a transparency level instead of a opacity level, so entering 1 makes your color 0% opaque and 0 makes your color 100% opaque). It also creates a lot of unnecessary globals. I've been meaning to rewrite it. Maybe I'll do that...

[Azethoth]

So what I am thinking of is to have the following under the covers:

--3 hierarchical layers:

• account
• group - for instance class specific settings
• custom - for instance spec specific settings

--A table that for a particular user and a particular data type has entries for which particular group and custom level to use, if any. This is similar to the "profileKeys" from AceDB but more specific.


Notes:

• Each of those has a default section and an SV section. So account & account-default for example.
• account-default is created by code at startup and is not saved.
• account itself is part of the saved variable and thus saved.
• A particular data structure, lets say for "target" could then be present or absent at any particular layer. This would let target then be able to have a different color globally (account), or per class, or per particular spec.
• Different parts of a particular data structure, can come from different layers. For instance something with 3 colors could have color1 be account wide, color2 class specific, and color3 spec specific.
• attributes lower in the hierarchy overide those higher up. So spec.target.color1 will be used instead of class.target.color1
• There is a function that for a particular data type like "target", collapses the whole or part of the hierarchy into a single table. This table is the one that is accessed by the actual Target class. This is similar to the AceDB defaults using a metatable, but without having to chain through multiple tables as would be required for this.
• Saved attributes are probably also cleaned at this time to remove attributes that are identical to the defaults.
• During editing time (via the Grid2 Options mods), changes are made to the saved table at some particular level, and then collapsed and cleaned for actual use again. There are specific API calls for this editing that use

In actual usage it would be accessed as a simple table access:

function Target:GetColor(unitid)
	local color = self.settings.color1
	return color.r, color.g, color.b, color.a
end

Resetting to defaults is then a simple process of deleting or wiping the saved parts for some set of keys at various levels.

The API would be written to deal with an arbitrary number of levels so it can be reused in other mods. It would also be a library for that purpose.

The User Perspective:
A first cut at this would be to create only a set of specs for each class with a UI to choose a particular spec from a popup menu. This would solve the current problem where Grid2 is single class only. Particular things like indicators would start off being a mix of account, class and spec based with no UI to edit them.

More elaborate would be to allow creation of custom specs and groups.

Spec switching is done out of combat, so there should also be a way to associate a spec with each of the two Blizzard specs so they can get switched to when switching specs.