Re: 6d48a3b "Fix bug by which..." and "redrawing issue":

• Find where ticks are redrawn on zoom (like in "auto") and make redraw proportional (will probably fix below)
• Figure out why ticks not redrawn on double click/home

Issue was that replacing proportional values with actual values causes exponential tickval increase- each time actual values were to be calcuated, the proportional values used were equal to result of last calculation. This issue is a good argument for adding a whole new property other than tickvals (tickpropvals?)- but the relationship with array is nice for the end user experience.

Alright that's pretty good. One more commit for whatever lint the bot picks up. I'll write tests after I get a response from devs.

Questions for devs:

• Multicategories, should I even try to support it? It actually works kind of well for regular categories, it can help position the ticks.

Tomorrow, a youtube video with results.

Merry Christmas!
image

This strategy currently doesn't work if both major and minor ticks are proportional because plotly's array-mode conditions in calcTicks are broken. As of now, calcTicks cannot actually separate major and minor tick processing into separate loops (like it claims to do through comments and if (major)) instead processing major and minor ticks in the major loops, and then both again (duplicated) in the minor loops. There are other problems with that: Issue #6828, PR #6829

Alright, the testing is parameterized and randomized:

It tests xaxis.tickmode:'proportional' xaxis.minor.tickmode:'proportional' yaxis.tickmode:'proportional' and yaxis.minor.tickmode:'proportional' in every permutation. Understandably, it's failling as a result of #6828.

All tickval are randomized, both length and values.

It runs for category linear log date type graphs and checks proportions against DOM object properties to verify geometry.

File would obviously be renamed or put into other more relevant location.

I don't understand how this concept would extend to multicategory especially since multicategory is TODO in arrayTicks.

Also, not sure how range padding is calculated but it might be convenient if the user were to know what proportion is added by padding so, eg., w/ autorange, maybe [.05, .95] would have the intended effect of [0, 1].

Interesting PR.
I merged your #6826 pull request.
To simplify the diffs for the reviewers here, I suggest you fetch upstream/master then after git pull, merge master into this branch.
Thank you!

Two suggestions by Alex coming tonight:

1. Change Name
2. Additional mode to allow generation of ticks along domain w/o

Tomrrow:
3) Test for #2 tomorrow

So, I'm happy to write logic + tests for the tick-mode combination but I need it spelled out (and what do we do if they try a combo that doesn't work?- edit: I'll just take a look at how layout_attribute.js violations handles bad values and probably add the logic in the same place)

To confirm:

Major Tickmode: Auto, Linear
 allow:
 Auto # (within major ticks)
 Linear # (absolute values)
 Array # (absolute values)
Major Tickmode: Array
 allow:
 Linear # (absolute values)
 Array # (absolute values)
Major Tickmode: Sync
 allow:
 Sync # automatic
Major Tickmode: Full Domain
 allow:
 Full Domain # (within major ticks)
 Domain Array # (within major ticks)
Major Tickmode: Domain Array
 allow:
 Domain Array # (within major ticks)

• Use a private property ax._something instead of overriding ax.tickvals
• Remove use of Lib.nestedProperty
• Make some mocks
• Rework math on minor ticks to be relative to major ticks (what do we do if major ticks is [])
• Reinspect log math
• Fail if using domain array/full domain in *category mode (how?)
• Maybe take a look at sync while I'm here? (@archmoj if you don't mind)
• Nail down the logic tree for proper major/minor tick combinations

@ayjayt if you can change the name of the file containing the tests to not include your name, I'll get this one reviewed :-) thanks - @gvwilson

@ayjayt Would you please resolve the conflicts?
Thank you!