Your code allows for selecting multiple expressions, but it immediately combines them and jumbles the equation. I've been considering something more standard:
- Clicking selects the minimal expression containing that point (as in the original).
- Dragging from a point with no expression selects all variables and numbers partially within the rectangle, and all other expressions fully within the rectangle, without changing anything.
- Shift-clicking selects the minimal expression containing all selected items.
- Control-clicking selects or deselects individual expressions without considering the rest of the selection.
The "combine" button can then be used to get the selected expressions into a single factor and term. Dragging the selection anywhere implicitly combines it first, and drags only if successful. We must be careful not to disturb the selection at the beginning of the drag, though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There seems to be a large number of methods in the original code devoted to dragging operations. I would like to consolidate them or delegate them to the Operator classes, if possible. This could take quite a bit of design work.
Here's a list of the drags that I'm seeing so far. Tell me if I'm missing anything:
- Dragging a term (or part of one) to the other side of an equation subtracts it from both, inserting it as near as possible to the drop point.
- Dragging a factor (or part of one) below the other side of an equation divides it from both.
- Dragging a term within a sum changes order (but dragging part of a term only considers that term).
- Dragging a factor within a product changes order.
- Dragging a factor onto a sum distributes it.
- Dragging a factor out of a sum sometimes distributes it out, but sometimes drags the whole sum, other times just that term.
- Dragging a something out of a ratio will factor it to that side.
- Dragging a factor onto a ratio puts it on top, if you're lucky.
- Dragging an exponent onto its base tries to expand the base.
Others we might want to consider:
- Dragging a sign around.
- Dragging simple expressions in or out of derivatives, integrals, sigma sums, or pi products.
Now, considering all these cases, do we need more than the following methods:
- extractTerm
- insertTerm
- extractFactor
- insertFactor
- dragWithin
Furthermore, what if multiple things are selected? Or should we disallow that case entirely?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The functions you are suggesting should be a good start. Don't forget, though, that the users are monkeys dragging the mouse everywhere, and you have to read their mind. I would be surprised if it stayed as simple as these functions suggest.
This was one of the most complicated parts of the entire code, which is why there are so many different kinds of drags. I wouldn't worry about classifying them so much, though. If we do, we want to classify them first in terms of the kind of objects they can occur under/inside of.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Basically, I want complicated mind-reading to occur from simple code. These five equations should do it, under one condition: that an outside expression can only be inserted by multiplication or addition. Is this ever violated?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I can answer definitively no. I think exactly one more is required to make it complete:
>
> dragOut
>
> Not every event will occur within any of the expressions on-screen, and sometimes even when an event occurs within the expressions on-screen, it is better to view is as really dragging something out of a sub-expression. (For example, if we had the term a+(b*c)/d and wanted to drag the 'b' out of the product on top so that we would have the expression a+b*(c/d), we would say that the 'b' was dragged out of the ratio. The term (b*c)/d
would be responsible for changing itself.)
In this particular case, the sum should try to handle the operation, but I agree that dragOut is a good idea.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm just thinking that in some circumstances, it will be appropriate for the Sum to pass the responsibility for the drag to dragOut, esp. if its other attempts to change the expression have had no effect. In the case I listed above, the change in the ratio (b*c)/d to b*(c/d) is what we would expect from dragOut if the term was standalone. If the sum determines that the drag did not move the entire term or change it in any way, (it probably called extractTerm on in), why not try to interpret the ratio as being standalone and calling dragOut on it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On careful consideration, certain things might want to have small portions of their boundaries selectable. For example, highlighting just the equals sign in a relation, or a sign to be dragged around. Even one of the signs in a multipart sum, so it can be changed.
That raises some curious implementation issues, but I think it might be possible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure I like the idea of implicity combining objects when the selection is dragged. It would probably tend to leave the user more in the dark than they were to begin with because it is skipping steps. It would probably be better to simply make the user hit "combine" before dragging them.
The rest of the ideas sound fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You're right. It should instead just back up to an entire term or factor that has all of the selected objects, without changing the expression. If they are on different sides of the equation, that will fail, though. In such cases we probably shouldn't do anything.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Essentially, I need muddled mind-perusing to happen from basic code. These five conditions ought to get it done, under one condition: that an external articulation must be embedded by duplication or expansion. Is this consistently disregarded?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your code allows for selecting multiple expressions, but it immediately combines them and jumbles the equation. I've been considering something more standard:
- Clicking selects the minimal expression containing that point (as in the original).
- Dragging from a point with no expression selects all variables and numbers partially within the rectangle, and all other expressions fully within the rectangle, without changing anything.
- Shift-clicking selects the minimal expression containing all selected items.
- Control-clicking selects or deselects individual expressions without considering the rest of the selection.
The "combine" button can then be used to get the selected expressions into a single factor and term. Dragging the selection anywhere implicitly combines it first, and drags only if successful. We must be careful not to disturb the selection at the beginning of the drag, though.
There seems to be a large number of methods in the original code devoted to dragging operations. I would like to consolidate them or delegate them to the Operator classes, if possible. This could take quite a bit of design work.
Here's a list of the drags that I'm seeing so far. Tell me if I'm missing anything:
- Dragging a term (or part of one) to the other side of an equation subtracts it from both, inserting it as near as possible to the drop point.
- Dragging a factor (or part of one) below the other side of an equation divides it from both.
- Dragging a term within a sum changes order (but dragging part of a term only considers that term).
- Dragging a factor within a product changes order.
- Dragging a factor onto a sum distributes it.
- Dragging a factor out of a sum sometimes distributes it out, but sometimes drags the whole sum, other times just that term.
- Dragging a something out of a ratio will factor it to that side.
- Dragging a factor onto a ratio puts it on top, if you're lucky.
- Dragging an exponent onto its base tries to expand the base.
Others we might want to consider:
- Dragging a sign around.
- Dragging simple expressions in or out of derivatives, integrals, sigma sums, or pi products.
Now, considering all these cases, do we need more than the following methods:
- extractTerm
- insertTerm
- extractFactor
- insertFactor
- dragWithin
Furthermore, what if multiple things are selected? Or should we disallow that case entirely?
The functions you are suggesting should be a good start. Don't forget, though, that the users are monkeys dragging the mouse everywhere, and you have to read their mind. I would be surprised if it stayed as simple as these functions suggest.
This was one of the most complicated parts of the entire code, which is why there are so many different kinds of drags. I wouldn't worry about classifying them so much, though. If we do, we want to classify them first in terms of the kind of objects they can occur under/inside of.
Basically, I want complicated mind-reading to occur from simple code. These five equations should do it, under one condition: that an outside expression can only be inserted by multiplication or addition. Is this ever violated?
> I can answer definitively no. I think exactly one more is required to make it complete:
>
> dragOut
>
> Not every event will occur within any of the expressions on-screen, and sometimes even when an event occurs within the expressions on-screen, it is better to view is as really dragging something out of a sub-expression. (For example, if we had the term a+(b*c)/d and wanted to drag the 'b' out of the product on top so that we would have the expression a+b*(c/d), we would say that the 'b' was dragged out of the ratio. The term (b*c)/d
would be responsible for changing itself.)
In this particular case, the sum should try to handle the operation, but I agree that dragOut is a good idea.
I'm just thinking that in some circumstances, it will be appropriate for the Sum to pass the responsibility for the drag to dragOut, esp. if its other attempts to change the expression have had no effect. In the case I listed above, the change in the ratio (b*c)/d to b*(c/d) is what we would expect from dragOut if the term was standalone. If the sum determines that the drag did not move the entire term or change it in any way, (it probably called extractTerm on in), why not try to interpret the ratio as being standalone and calling dragOut on it?
On careful consideration, certain things might want to have small portions of their boundaries selectable. For example, highlighting just the equals sign in a relation, or a sign to be dragged around. Even one of the signs in a multipart sum, so it can be changed.
That raises some curious implementation issues, but I think it might be possible.
I'm not sure I like the idea of implicity combining objects when the selection is dragged. It would probably tend to leave the user more in the dark than they were to begin with because it is skipping steps. It would probably be better to simply make the user hit "combine" before dragging them.
The rest of the ideas sound fine.
You're right. It should instead just back up to an entire term or factor that has all of the selected objects, without changing the expression. If they are on different sides of the equation, that will fail, though. In such cases we probably shouldn't do anything.
Essentially, I need muddled mind-perusing to happen from basic code. These five conditions ought to get it done, under one condition: that an external articulation must be embedded by duplication or expansion. Is this consistently disregarded?