Thanks for the pointers. I don't have the build platform set up, hell I don't even know what you guys recommend, gcc or something I'm assuming. Anyway, just looking at TaskDimension.cpp, the cone size of the arrow, which is the problem, not the arrow itself, is set with these lines:
(similar for the cones at line 1060)
I don't know the correct method for calling the function, but couldn't you could calculate the scale factor off the vector at around line 432:
textVecCalc->dot(A,B) // should return length of the 3D arrow
And again, at around line 1137.
Then you know based on the size of the vectors that make the arrow length, say are fine at 20mm (just guessing), you could then scale the cone size based on that dot product in relation to 20mm.
Of course, maybe I'm missing something here? I am not familiar with the code, or with Coin3D, just a brief look at both, but it looks like an easy fix to me.
The reason this is OK is that if you are looking at a small area, the cones NEED to be small. Even if you were zooming out and looking at the part in a wider view, it doesn't help to have the cones be big and overlapping. Basically, I'm saying scale the cone based on the arrow length, NOT the camera view.
The other option is how about just not displaying the arrow cones at all? It could be a checkbox in the preferences. I don't see why they're really necessary anyway. With that, you just make it a conditional based on the global preference around lines:
Anyone who has the build environment already set up care to test or implement either of these suggested changes?
I realize that this may not be as important as implementing a much cooler feature, but as a novice user (at this point I might call myself novice->intermediate as there are many features I stil am not familiar with), the arrow cone issue is one of the first things that I ran into that has bugged me from probably the first or second part I made, and continues to bug me pretty much anytime I am working on something with tight tolerances. If it's that easy and annoying of a "bug" for someone to find, and at least just having the option to turn them off is available, that might keep someone from getting really frustrated and saying "f-this, I'll just go back to whatever-cad"
I think FreeCAD is awesome, by the way. Thank you guys so much for creating / working on it. I will be happy to make the change myself, but getting the build environment all set up is going to take some time that I don't have at the moment. I don't know if this really matters to anyone who is doing the regular builds / code merges or what have you.