First at all, thank you so much to all of you for your feedback. I very much appreciate it for two reasons: 1) with it we can avoid the problem of advancing to much on an unwanted direction. 2) we can make a better product by mixing the ideas of others.

I would like to comment on your input. I will try to group ideas together so that we can effectively discuss similar ideas and press the blender button for each group...

Issue #1 (possibly new numbering)

The code (in the lastest commit to my branch in GitHub) does:

1. click center

2. click to define one axis with respect to center (let's assume Major axis)

3. click in a point the ellipse must go thru

4. calculates the a, b for such an ellipse

5. some check if b>a, the first click defined the minor, if not it defined the major..

6. calculate the other axis so that it is perpendicular and the ellipse so built has a CCW sense (the vector perpendicular to both axes is positive in the same direction the sketch thinks the Z direction is).

A) Let's assume the center is in (0,0,0) and that I define the Major axis, its endpoint to be (-20,-20,0), then the calculated minor axis is (10,-10). The phi parameter of such a constructed ellipse is (180+45=225 degrees, or -135 degrees, for now it is ok, Jim's idea not yet implemented).

B) Let's assume the center is in (0,0,0) and that I define the Major axis, its endpoint to be (20,20,0), then the calculated minor axis is (-10,10). The phi parameter of such a constructed ellipse is (45 degrees).

Should the ellipse creation be "smarter", and no matter if the user did A or B, produce the result of B? In other words, should a newly created ellipse have the lowest possible value of phi (at least in absolute value)? What is what a user expects from executing A, a phi value (if you would apply a phi constraint) of 45 or of (225 or -135) degrees?

Nobody commented on this one. Probably because you missed it in the bunch of requests in separate posts. I would really appreciate some input on this.

Issue #2

Auto-resize of Major/Minor when setting a Minor/Major constraint that would lead to MajorAxis<MinorAxis

I got Jim's answer. I probably think now it is a bad idea. Mainly because the undo does not work. So it is preferable to have an harmonised way of working. This change is in a separate commit and can be easily undo... and I will... consider this issue as closed.

Issue #3

phi constraint

If implemented as a separate constraint (see discussion below) and in agreement with Ulrich comments:

1. If only an Ellipse is selected then phi fixes an angle from the major axis with respect to X axis.

2. If a line and Ellipse are selected, then the angle therebetween is constrained.

Here will come the discussion of absolute or relative angle (see Jim's proposal so 15 posts ago in this thread), internal or external angle, only definite positive. This would require a new Angle constraint to be defined for all the elements, so that it only has one solution and prevents flipping when changing dimensions.

With phi as a separate constraint, it also comes the issue below of reusing the same button or not.

About Jim's ellipse on ellipse. This seems to be just a line to line angle with the major axis of both ellipses selected. Ain't it?

Issue #4

Symmetry constraint on an ellipse's edge

if I want to make two points symmetric to the major axis, in this case it may be useful to select an ellipse as last input for a symmetry constraint.

I would expect the center point of the ellipse to be selectable. So the center point can be also used as input for the symmetry constraint. So it is possible to select either the center point (symmetric to point) or the whole ellipse (symmetric to major axis) as last input in the symmetry constraint. (Switching major and minor axis may then have unexpected results for the user. This point may need some more discussion.)

So, in line with Ulrich's comments, it might make sense if we equate ellipse with major axis of ellipse. Still the symmetry is a symmetry with respect to a line.

Issue #5

equality constraint

In line with Ulrich's and Jim's suggestions both radii, no phi.

Issue #6

equality constraint of an ellipse and other element

No. In line with Ulrich's observations.

Issue #7

Selectable parts on any new geometry

My ellipse has and will have one center and one edge. The reason is that introducing more elements requires a lot of code modifications, as the possible selections for a form are {edge, starting point, endpoint, middlepoint}. An ellipse arc would have all those. Including more would involve revisiting all the code for all other existing forms... This is something to undertake only with an extraordinarily good sound reason.

Issue #8

Specific constraints

Well a short word on this. Making new constraints is really quite a lot of work (everything from defining it in the solver to code the commands to fire them, to the representation in the Inventor view). I will prefer to really discuss this thoroughly making sure that what will be implemented is what we really want. Also because creating new constraints and removing then afterwards might lead to non-backwards compatible files, as constraints are also stored in the FreeCAD project files.

I was talking to an advanced professional CAD user the other day about ellipse in sketcher. His general comment was that he thought (as much as is possible or sensible) we should have general constraints rather than too many geometry specific constraints. So for this philosophy you would perhaps from a users perspective just have one angle constraint that worked as angle currently does now but also provided phi for the ellipse. Do you think we really need phi and angle constraints as two different constraint icons or would just a simple angle suffice?

I understand what you are saying and my answer is as follows:

1. Using a constraint in a way different from what is expected by the user is a UI usability problem. I.e. as a user I will not go to the angle constraint if I want to set the phi of an ellipse, unless I am told to do it.

2. From the implementation point of view, reusing an icon in the UI to lighten the toolbar for another task, does not change the fact that somewhere you will have to implement all the "new functionality specific" code. So internally, all the backwards compatibility problems remain.

Nevertheless, I think we might be able to save the new constraint (not implement it, remove it), by using the angle constraint for a line to line constraint, by using construction lines, which might be a nicer solution from both the GUI and implementation point of view. More below...

issue #9

Parallel constraints

I can think of another....Parallel constraint...it should align phi for an Ellipse with reference to a line or axis or phi of another Ellipse...although being parallel gives two solutions, being symmetrical it would, I imagine, not make any difference for ellipse.

This is for me similar to issues #3 and #4. The actual intended constraint is a construction element of the ellipse (the major axis).

Issue #10

Using construction lines or similar

might be more intuitive if ellipse showed its own local major and minor axis that function in the gui a bit like the current global axes but not of infinite length. Hence you would then select the Ellipse axes rather than the ellipse its self.

This was my first thought for implementing the phase constraint (phi). I wanted to include construction lines for phi and potentially also "construction points" (for the two focus of the ellipse), because I thought it might be relevant to the CAD user to use the coordinates of a focus, which might not be so simple to derive.

I disposed of this idea in favour of a specific constraint because I considered that adding construction elements to the ellipse might bloat the representation. However, now revisiting the idea in view of most of the previous issues, it might make sense to think further about this, because I never thought of the potential usefulness of using the lines of the axis for symmetries, parallel constraints and others.

Issue #11

New generic constraints

I understand that there may be no way to constrain an ellipse with the current set of constraints. But I wonder if it would not be best to add new sets of constraints that could be used for ellipse as well as for other types of geometry.

This is brilliant, but you profesional users have to step-in here. You have the technical mechanical/geometric knowledge. You know what other non-opensource professional packages do (yes freecad is a professional package by definition, because there are a ton of professionals here that use it).

In the commercial parametric CAD packages I know of, you typically constrain an ellipse using its quadrants. Circle and arc quadrants can also be constrained. You can align quadrants of an ellipse or a circle using a vertical or horizontal align constraint. Those types of constraints can work on any points.

This is a very good idea!!! Does it extend to other conics parabole and hyperbole? Or this does not make sense...

BTW, what happens with an arc of 20 degrees sweep not aligned with any horizontal or vertical lines? I mean... there is no quadrant there...

Does this mean that in a professional package, to rotate an ellipse (what is referred above as phi constraint), you somehow "align" a line to "quadrants" of an ellipse and apply an angle to the line? Could you explain me a little bit more how this would work...

And the angle constraint can be applied to three points or two lines.

This I thought about before and I was thinking of implementing. It is on my todo list.

Now I understand that implementing such constraints in the Sketcher may be a major undertaking. Maybe a current compromise would be to add major and minor axes to the ellipse like Jim suggests, but have them be construction lines that cross the center point and have a "point on object" constraint on the quadrants of the ellipse?

Though I do not know how much time I will have available in the future for FreeCAD coding, I think that it is not a good idea to implement construction lines for the axes if there is a better way, just because (allegedly) it would be easier. I am not looking for a fast track to the maximum number of commits to the FreeCAD GitHub repository. I am looking to contribute to have a better tool (within my limits). So if what it takes for FreeCAD Sketcher to jump to the next level is a tool like working with quadrants and the possibility of an "alignment" constraint. Then I think we should go this way. About this I am quite Joda oriented, do it or do not do it, but do not try. This I say without knowing what an alignment constraint it and how powerful working with quadrants is.

I would really appreciate if you could describe a little bit more how this "working with quadrants" and "alignment constraint" would work. Which are the possibilities? Why is it better than having two construction lines as axes or how is it different from it?

"point on object" cross center has infinite solutions with lengths between the major radius and the minor radius. As far as I see it, you would need to additionally constraint it with given phi (phi for major, and phi+pi/2 for minor)

My idea with all this construction lines was to introduce a new command "Expose internal geometry". So that an ellipse will be defined by a center and edge as created during creation. If modifications are needed. By pushing the button the internals would appear as construction elements (two lines for axes and two points for focuses for an ellipse). This command would be generic, allowing to expose the internals of virtually whatever you would wish to create (for example a thread profile, an hyperbole, parabole). All constraints would then be applied on those "internal" elements. If you want to do a phi constraint, then you will push the button, let the internals appear and apply constraints to those internals. The internals will always be there in the Element Widget (it could be filtered out by an option "do not show construction lines") upon creation of an Ellipse (the command would be create an Ellipse and the associated "internals", but hidden), just not shown in the inventor view.

I do not know... I think I need more input on this.

Would it actually be possible to constrain the end points to the quadrants of the ellipse?

As points of the geometry (like the center point) it would be a nightmare due to the actual coding {edge, starting point, end point, midpoint}. The system would not know how to handle those points... unless:

1. There are endpoints of a construction line that is otherwise constraint to the geometry (for example a construction line, point on object on both sides of the ellipse, center point on construction line and having a length equal to the major axis of the ellipse, or the same inclination as the phi parameter of the ellipse).

2. There are points (construction points if you wish) that are created together with the ellipse and are constrained with respect to the geometry of the ellipse (for example a point on object(ellipse) that is further constrained to have a distance from the center equal to the major radius). Here the problem is also the different solutions, which could be worked out by....dividing it in quadrants...

See that this idea is very similar to that proposed by Jim:

I was thinking about this another solution could be to leave it the way Abdullah has currently made it. If we want the blue construction lines in special cases

then we could add a line,

point on line with the ellipse centre

end points on line of the ellipse (when it is implemented)

The parallel constraint with ellipse (assuming parallel constraint applied to Ellipse would reference the major axis )

However, Jim's idea also relies on ellipse specific internal constraints (parallel to major axis)...quadrants was it?

As a comment to some posts. I would not color the lines differently.

Issue #12

Inverting Ellipse Axes

the way Abdullah has coded it, it is not possible to exchange the major and minor axes.

At initial ellipse construction time

first click give the centre

the second click defines the major axis/radius

He has written code to not allow a minor radius to be larger than the major.

The user must rotate the major axis of the ellipse by 90 degrees if they want to switch orientation of the ellipse.

I really can not think of a reason why to create a new ellipse when trying to make a major axis smaller than a minor axis (I have limited knowledge of cad, so maybe you can enlighten me). The ellipse is the same, you only have to add 90 degrees to phi. I thought of doing this automatically, however, the user might have other constraints defined and doing this automatically might lead to conflicting constraints plus a great surprise for the user. I think this is part of the design process. If you made an ellipse, applied a ton of constraints and then you realize that you have to rotate it 90º and for any reason you can not, then you did a poor design strategy. If you can, the just add some 90º to it and that's it. Am I missing the whole point?

Hi Johan!!

It's hard to keep up here, things are moving pretty fast and that's awesome

It is difficult for me, so I can totally understand you...

I just want to pitch in on the issue of the axes. IMHO the distinction of major and minor axis emphasizes something with no real value. Major and minor axis has no intrinsic properties other than describing the relation of the two to each other. Therefore I would propose that the internal representation of axes didn't distinguish which axis is the longest just have one saved axis (the first axis) and two lengths ( length of first axis and length of second axis). The reason for this is that if you change which is the major axis all constraints which depend on this major axis needs to be updated so they still describe the same relation. If I've understood things correctly abdullah has solved this issue by simply requiring the user to rotate the entire ellipse if you want to change the major axis. IMHO this just adds restrictions that are kind of artificial, you should just be able to set different lengths to the different axes.

OCC will launch an exception if you try to change what OCC thinks is the major axis to a value smaller than the minor axis. The major axis defines what the XDir is, and that is not arbitrary for OCC (though the equation would work ok, as it does while creating it). So it is not Abdullah trying to make the lifes of all of you more difficult than it should be (at least not this time

), it is just how OCC works.

I think visually exposing the axes would really make sense, then the symmetry constraint could be used on either of the axes. Also, there wouldn't be any need for specific angular (phi) constraint of the ellipse you could use either axis and constrain to any line in the sketch. Also, setting the length of a specific axis could be done by selecting the corresponding axis representation and pressing the radius button. This should also help keep the complexity of the constraints toolbar down.

I am between trying to go this way or the quadrants way of Normand. I will wait for some more info on this quadrants and alignment tool. If you (any of you) can reason why quadrants and alignment constraints should be preferred, or a short description of how it works, you will be welcome.

Only one note. the constraint would be the line length button, not the radius button, as we will be constaining a line. This might not be a visually appealing as the current radius representation...

With the above suggestions in mind, I think using different colors for the two axes is preferable. This makes which axis is the first axis and which is the second immediately apparent and you can also express this in the constraints list (same is true for the case with major and minor axes).

This I do not understand. Maybe it is because of what "first axis" is. During creation, the first defined axis does not need to be the major axis. Why is it relevant to know and be able to differentiate which axis is "the first one"...

Regarding the xpm icon for sketcher when in create ellipse mode...would you like this better? the ellipse major axis is angled about 45 degrees to the top right...looks more like an ellipse I think. Any opinions?

Sure Jim. Anything would be better than my icon, and your certainly is nice (in text). I will paste it for the same compiling...

open FreeCAD, go to PartDesign, new sketch on XY plane, click on Ellipse, click centre point, major radius, third point now you have an unconstrained ellipse. From here if you select the edge of the ellipse and drag it crashes FreeCAD. You can select and drag the ellipse via its centre point, that works well.... interestingly once you have dragged one ellipse via its centre attempting to drag any ellipse after that via its edge will no longer crash FreeCAD, it just wont drag via the edge.

Ok. Yesterday I was on a hurry changing some code to avoid dragging from the edge and it seems that I did something wrong. I will look into it.

I see that now on initial construction it is no longer necessary to select the major axis first, I see you can now select the minor axis first if you want to.

Well that feature is there for a while... a couple of commits!!

. But yes! it is possible.

Equal constraint only works on the major diameter and ignores the minor radius.

Yes, it is implemented as only major radius in the placeholder code. Not yet implemented.

If I select the edge of the ellipse only then I can set the major axis constraint (phi) ....however if I select the edge of the ellipse first and then any of the following y-axis, x-axis or a line ...and then click phi constraint ...it crashes FreeCAD.

Any combination of more than one single ellipse element and ellipse angle will crash FreeCAD because the code for Ellipse + line is available only as a placeholder. That function is not yet implemented.

Yes indeed! But unfortunately so to can two young girls talking about pink sparkly nail polish...

Please guys, give me some hints on Issue #1. Feel free to comment on any other issue. My current understanding is:

a) I want to hear from the quadrant and alignment procedure (give me your opinion, explain to me the advantages,...)

b) I will currently leave the implementation with the specific constraints (two radii and ellipse phi) until we think it through and decide what we want for freeCAD: i) quadrant/alignment, ii) construction lines (possibly with some accelerators like a button to make them appear automagically) iii) do we want an external angle as Jimmy proposed? If yes, it could really be the starting point for idea ii) as for phi I think we do need something with a single solution to avoid flipping...

c) I will continue implementing the other generic constraints that make sense in the meanwhile.

OMG! I wrote a book!