What's the rule?  You need to know 3 pieces of info (general case) about a given triangle to figure out the rest of the missing info?  So 3 inputs required for the component to run?

Would also be useful a component to the bisector or the inscribed circle.

@Taz, if you supply two angles (or one angle in the right triangle case) it can work out the missing angle, but obviously not the edge lengths. If you supply three edge lengths, it can work out the angles. If you supply two edges and the angle in between, it'll also work out how to proceed. It basically applies a bunch of rules for determining edges and angles based on known values, and every time it finds a new value it will keep on trying to grow the list of known values.

It is still somewhat problematic at the moment if too many values are user-specified. I perform some checking to see if the data represents a valid triangle, but there are still plenty of impossible combinations that aren't caught.

I would prefer that my students learn trigonometry! As you said, it's basic after all.

If the man is hungry, better teach him how to fish than serving him a meal...

Is it trivial to have an output for the equation(s) being used?

these 2 are not bad at all (the amount of people not knowing - even basic - trigonometry is 1000++ times bigger ... than the other thing).

@Dani, sure... I kept these components simple as the inputs are fairly obvious.

From top to bottom:

• Perpendicular Bisectors giving the circumcentre.
• Altitudes giving the orthocentre.
• Medians giving the centroid.
• Angle bisectors giving the incentre.

Cool, I can't wait for the GH2!

A general rule at the moment is if you can see it it is GH1.0. Look out for them in the next release I would guess.

I'm not really after the idea to create those components (learn trig), but I think that this problem 

It is still somewhat problematic at the moment if too many values are user-specified. I performsome checking to see if the data represents a valid triangle, but there are still plenty of impossible combinations that aren't caught.

Can be very nicely solved with ZUI.

@Mateusz. Are we talking about the same thing? I mean that all inputs are optional, and it's thus possible to 'provide' values that cannot possibly represent a valid triangle. For example two angles can be given as 88° and 95°. All three angles must sum up to 180, and we're already 3 degrees over balance. Or maybe the user specifies three edge-lengths: 21, 12 and 8. 21 is bigger than 12+8, so even if the triangle was stretched flat, the two short edges cannot reach the ends of the long edge. The above is easy to test for and I add errors to the component if an invalid triangle is provided. However there are also many angle+edge length combinations which result in invalid triangles.

I could of course test for these as well, but the problem is now tolerance. What if the user specifies a redundant angle of 54.7°, whereas the mathematics tell us that the actual angle is 54.7002°. Is that an error? If so, is the angle wrong or is perhaps one of the edges wrong? Or has the triangle simply been over-constrained? Is there a mathematically robust way of dealing with this? And if so, would that also be the most user-friendly way of dealing with it?