RFE: enhance expression evaluator in input boxes

[Kieran Clancy]

Follow-up report to: Bug #171282 “Calculator in input fields”

The concept is simple enough:

When I am modifying an object's property or filling in toolbox options, and there's a field for length, position or even just an integer, I want Inkscape to support some simple in-field calculations. It would also be great if I could specify units and have Inkscape understand how to convert them to the current display units.

Here's a bit of an outline of how I think this could work:

When a user changes the field, a function is used to pre-process it and replace it. Currently this is already done by Inkscape for some fields; for example if you type just 0.5 into a field it will sometimes change to 0.500 automatically.

If the input is not recognised, it should become red and prevent the user from activating the change with the keyboard (by keypress like enter) until fixed. If not fixed and the user cancels the operation or presses Esc, it will return to the (valid) value before the change.

Types of arithmetic / conversions supported:

Basic mathematical operations, with highest precedence first

* multiply
/ divide
% modulo
+ add
- subtract
( <expr> ) evaluate <expr> first
<whitespace> ignored

This should be supported by all numerical fields. (If the field is an integer-only field, truncate fractional part after finishing entire calculation.)

If a binary operator is the first non-whitespace input to a field, the previous input should be automatically recalled and inserted before the inserted operator.

Examples:
Typing "2*88" in a field should be replaced by "176"
Typing "29.7/21" would give you the ratio of any ISO A paper size (~=1.414~=sqrt(2)).

Unit operations:

For fields representing lengths or coordinates, accept '<expr>mm', '<expr>cm', '<expr>in', '<expr>%','<expr>px','<expr>pt', etc, where <expr> is either a number of a valid number or mathematical expression.

These should work regardless of which units are currently being displayed.

That is, if I am displaying my units in millimetres and I type '1in' into the width field, it should be updated to display '24.5'.

Furthermore, it should be possible to combine units, so "3*14.2cm+10/3pt" would work as expected.

I think that it would be such a useful feature, and I don't think it should be difficult to make?

Bonus features:

If this ends up being done, perhaps keep in mind that in future it might be cool to support some extra functions and operators:

^ exponentiation operator
sin(), cos(), tan(), exp()

Contextually relevant variables:

l / last (previous value)
dw / docwidth (width of document)
dh / docheight (height of document)
w / width (width of current object - if applicable)
h / height (height of current object - if applicable)
x / xpos (x position of current object - if applicable)
y / ypos (y position of current object - if applicable)

Other context-sensitive parameters? Maybe they can be summarised in the field's on-hover tooltip. (For example, circle objects might have a 'r / radius' parameter.

[su_v (suv-lp)]

Already implemented in trunk (for Inkscape 0.49):
<http://wiki.inkscape.org/wiki/index.php/Release_notes/0.49#Simple_calculations_in_spinboxes>

Linking as duplicate to
Bug #171282 (sf1488591) “Calculator in input fields”
<https://bugs.launchpad.net/inkscape/+bug/171282>

Please add a comment here and revert the duplicate status here if you don't agree and think these are different feature requests.

[Kieran Clancy (clancy-kieran+launchpad)]

(Not sure if commenting here will remove the duplicate status -- sorry if it does -- feel free to put it back.)

Honestly, I was surprised that this hadn't already been requested, but when I searched in the related words box it had nothing remotely relevant to this -- do you know why lp didn't find it when I entered words like 'calculator', 'unit' and 'input'?

[su_v (suv-lp)]

Unlinking
- Bug #1024362 “RFE: Support unit and numerical arithmetic and conversion in input boxes”
as duplicate from
- Bug #171282 “Calculator in input fields”
again since this recent feature request goes beyond the current implementation (which only supports add, subtract, divide, multiply and some basic unit conversion based on the current unit chosen in the unit selector if present) and it makes sense IMHO to keep this as separate feature request to enhance the current implementation:

- extend basic functions to include:
  % modulo
 ^ exponentiation operator
- add basic trigonometry functions:
  sin(), cos(), tan(), exp()
- possibly: extend unit support
- possibly: contextually relevant variables

[Johan Engelen (johanengelen)]

additional idea: entering "60%" results in 60% of previous value

[LucaDC (lucadc)]

Johan, for your idea I would suggest writing "*60%", to preserve the case when you want to enter "60%" as absolute value.

[ScislaC (scislac)]

I want to back luca here... I think in terms of entering a percentage as a value it should remain relative... if you want 60% of the number you can just do "value*.6" and hit enter in the field to get an absolute value to that equation.

[LucaDC (lucadc)]

Well, the idea of writing "*60%" is not bat, at least for those who are not so used to think 60% as 0.6 (and I know many of them, my sons included).
However, it would be just one case in the units management, considering % as a unit of 1/100.
A different case is writing "+60%": this case could be treated apart and it would be useful to refer it to the previous measure (always for those who find difficult to translate it into a "*1.6"). Of course this could work only if written alone, not inside more complex expressions (I'm thinking about someone that would like to write "+60%-10mm" which is easy to understand by a human but, I suppose, more difficult for the code).

[Chris (chris-spacelab)]

The OP adds the idea of reading a leading + or - as relative change (more or less). While that is not a good idea because you would not be able to enter negative measures or to copy-paste values with leading + into the fields, I suggest to use a leading @ as indicator for a relative change. @ would behave similar to the suggested l variable but additionally allow inputs such as @2cm instead of l+2cm to move 2 cm starting from the old coordinate. Yes, some convenience thing, so the @ could be subject of discussion, but don't do the leading binary operator magic and please do the variables :-D.