Strange spacing for class members

[glfmn]

I noticed a strange quirk with the rendering of the doxygenclass rule: The Top level class renders properly with the namespace and class-name separated by ::s.

But there appears to be improper spacing for any of the members:

As far as I can tell, in regular python projects these should be separated by a . character, and thus I feel like in breathe's generated documentation they should be separated by a ::. That is, we should have:

typedef model::Model::State

virtual void model::Model::init(const Model::State &state, const Model::Control &control) = 0

I looked through the functions that appear to render the signature but I can't quite make head or tails of it and understand where the different parts of the signature come from.

[hchapman]

I'm getting this too; Python 3, Sphinx 1.7.2, Breathe 4.7.3.

[svenevs]

If you roll back to Sphinx 1.6.7 the original behavior is in tact (e.g. for RTD until this is fixed you can pin sphinx==1.6.7 in your requirements.txt). Personally, I would rather not have the fully qualified name under a .. doxygenclass::, it's quite unwieldy. Consider

namespace arbitrary {
    struct arbitrary_struct {
        int function() { return 1; }
    };
}

Then I'll end up with

• class arbitrary::arbitrary_struct
  • int arbitrary::arbitrary_struct::function()

Since I'm already indented underneath a class, that seems unnecessary.

https://github.com/michaeljones/breathe/blob/08577a4b7f9a9173517d7ddf91bd1fa50eac1252/breathe/renderer/sphinxrenderer.py#L212

I haven't been able to track this down completely, but I think the issue is because the fully qualified name is being used. I don't understand this part of Breathe very well, but I feel like there is a way to "know" if you are a function coming from .. doxygenclass::. In which case the final signature it should be possible to split("::")[-1] (I think).

This would result in how things used to work in Sphinx 1.6.7:

• class arbitrary::arbitrary_struct
  • int function()

[jakobandersen]

This problem looks a lot like #374, which should be fixed when using the newly release Sphinx 1.7.5.

[vermeeren]

Thanks for the message, I will try to confirm whether it's fixed or not with 1.7.5/4.9.0+ soon.

[svenevs]

I can confirm that this specific issue is fixed in 1.7.5. However, 1.7.5 and breathe are now even further diverged, a project that had 29 build warnings now has 81 :/