Hello,

I have just tested this with the newest version (0.13.7) from PyPI, everything works great, thank you very much for this.

Hi @2xB, thank you for adding internal logic for the sub ticks. The code should absolutely have that!

There's probably a follow-up discussion to be had what a reasonable API might look like, since currently AxisItem doesn't really seem to expect the user to interact with its settings very much. For the moment communicating through the style property looks surprisingly reasonable.

#2827 tried to touch the overall logic as little as possible. It tried to adjust the math to produce a helpful number of ticks (e.g. more than one, I think) in a wider range of cases. The same adjustments also allowed the existing minor tick logic to actually produce visible ticks more regularly, I believe that produced the change that #3250 points out.

There's no deeper meaning to the appearance of extra ticks.

Thank you very much for the responses! Interacting with the style dictionary directly instead of through a proper function is my fault, there already exists a proper interface:

plot.getAxis('bottom').setStyle(maxTickLevel=0)
plot.getAxis('left').setStyle(maxTickLevel=0)

I've also adapted the code in the above message.

@2xB this looks good to me and is a nice, efficiently minimal change.

Could you maybe add a short description of the maxTickLevel parameter to the documentation of setStyle()?

@NilsNemitz Sure, I added a short documentation to setStyle!

Thank you!

Given the name of the maxTickLevel parameter, I think it might be better if the documentation discusses major ticks and minor ticks here, rather than the grid. Although considering that the grid motivated the PR, maybe

 - 0: Show only major ticks
 - 1: Show major ticks and one level of minor ticks
 - 2: Show two levels of minor ticks (higher CPU usage) 

This setting also affects the displayed grid.

might be a reasonable inclusion?

Sure! I minorly rephrased it so the grid is mentioned in a concise description at the beginning of the text.

Hi @2xB , we've been having some trouble with the tests, which might be better now.

If you make another change, the tests should rerun automatically, and we'll see. On that note, maybe you could go to line 234 and change

``float``,``int`` or ``None``               to
``float``, ``int`` or ``None``    

?
It's not related to your PR, but it is right next to your maxTickLevel documentation. I hope that will fix the rendering of [int] in the documentation.

After #3333 patched up the tests for now, everything comes back green.
I do not see any negative interaction with other parts of the code, and the PR adds in functionality that was clearly missing.

@2xB , thank you very much!