Yes, that is why I personally like a clean header file. Things that can't be documented in the .cc file goes into the header file.
Where do you spend most time in the code, the .h or .cc file? I'm just sharing my experience of many years debugging in various projects...
Well, you will agree there is no perfect solution to this. And looking at the .h it's clearly not a drama (right-click, Go to declaration). Do you all want to move documentation to the .cc? Do it. Do you want to move to the .h? Do it. I just don't care. But take one decision and be consequent with it.
And if you really want to move all the doxy to the .cc you should also consider where will you end describing the classes.
What I don't think it makes absolutely any sense is just exploring the code and at every step you don't like something, try to change it. We are just discussing one hundred small issues instead of doing what we should be doing, that's actually do something useful with the code. I can understand the discussion about the color, that's something useful, not this one imho. Why changing something that's already working.
Will you offer yourself to move all the doxygen already present in the .h to the .cc files? I'd be great to have all code follow some rule.
And I'm saying this from the respect, not being rude, I'm just pointing my oppinion.
I'd just rather prefer to do something of relevance, but opening old discussions that were more or less resolved one or two years ago. But seeing how are things working I'd not be surprised if in the future someone wants to move comments to the .h again, and two years later to the .cc again. What will this end in? No comment will be correct and in its place, ever.
As Ters menctioned documenting the .h is maybe more suitable for libraries, but it's useful in the whole code too, and hey, if someone wants to be able to read doxygen while debugging... Well, I'd like also to have a small (5 cm tall) elf living on my desk pointing me the bugs on screen with his finger but well, you can't have it all in life.