at the beginning of the function Line::intersects (around line 319 in juce_Line.h), distances are calculated this way between the endpoints:
const Point<ValueType> d1 (p2 - p1);
const Point<ValueType> d2 (p4 - p2);
while it’s p3 the actual point to be subtracted from p4 (I’ve done this change locally and it works as intended. It didn’t before this change).
const Point<ValueType> d1 (p2 - p1);
const Point<ValueType> d2 (p4 - p3);Doh!! Many thanks for spotting that, I’ll get it sorted pronto.
off topic question a little bit… what about branching the git repository with a branch for active development of new features, and a stable branch where only bugfixes are committed? When the active development one becomes stable enough, you could merge those changes into the stable one and go on with the development…
edit: in addition, tagging those commits that represent released versions could be a good idea for people to start off from a known stable base
Well, I’m not crazy about branching, but tagging some releases as stable might be an idea. I’ll have a think about that.
Yes, tagging stable versions could be as much useful. In my opinion they could be more “fine grained” than actual releases, intented to mark snapshots of the library that are stable in both the meaning of “not in the middle of a refactoring/developing process” and relatively “bug free”
