I see with version 0.97.9154 some of my wishes have come true! Thank you Andrey!
Just to stoke the fire, here's some more for discussion:
1) Equal sign "=", i.e. "Evaluate Numerically", only causes the value of the last assignment operation to be displayed in a "line" block, and it is in line with the first, rather than the last assignment operation. This seems to limit the use of line blocks to the right-hand side of an assignment operation to provide a logical visual output. Since you can use a line block to cluster assignment operations, I wish it would display the numerical value in line with every
assignment operation contained in it, i.e.:
|"First Input"
|A:= 1
|"Second Input"
|B:= 2
|"First Relationship"
|C:= A + B = 3
|"Second Relationship"
|D:= B + C = 5
2) Again in line blocks: when saved as executable, they will only display one input/output field in the SMath Viewer. This makes it necessary to use a style in laying out the calc sheet for the Viewer that is not very suited to a printed document. However, if you want to create an executable to produce standard calculation sheets, you either end up with a well layed out Viewer app or with a well laid out output document, but not both. There is already a way to hide expressions in the executable (collapsed areas), I think a better way to render line blocks would be to somehow frame them in the windows form. But, coupled with the issue at point 1, I suspect that line blocks were not really meant to be used that way, so, maybe, a new type of block/region/area would be necessary for this implementation? I like the ability to cluster expressions, so, maybe a "Group" command, like the one used with Shapes in Microsoft Office or AutoCAD might be useful there?
3) Rendering engine for text is more limited than maths rendering engine, e.g.: in a caption that refers to a variable with suffixes, such variable will not be graphically rendered (it will show as "A.b", for example), although you can still have greek characters using Ctrl+G, so why can't we have the same rendering capacity for text as we have for maths, with the only difference that spaces are allowed and evaluation is not performed? Surely, most of the work on the rendering has already been done for the maths region, so it should (and here's the wishful thinking part...) be just a matter of removing the evaluation part and including rendering of spaces and linefeeds/carriage returns that is already available in the text fields.
4) Some Design Codes (e.g. the dreaded Eurocodes) make extensive use of commas in suffixes for variables. A workaround is to use a semicolon as an element separator in lists, matrices, etc. This way the comma character is available as plain text for use in suffixes. However, when the document is re-opened, all the commas in the suffixes disappear. The calculation sheet still works, but it becomes inconsistent with the nomenclature of the Standard used in the calculations. Any way to fix that? All it needs to do is not to delete all the commas when you close (or re-open) an SMath document.
5) A few more options for headers and footers would be nice, especially the ability to have a standard template that can be filled in from the Viewer, possibly in tabulated form and with the possibility to include a company logo, just to give calc sheets a more professional appearance. Currently I use a MS Publisher template that I edit and load as a .png as a background in SMath, but that forces me to spread my calcs around the "cluttered" parts of the background picture. Ideally SMath should be stand-alone for any form of data input.
6) Log scale graphs please! Acoustic and electronic calcs use them heavily.
7) Some extra features for the formatting toolbar: I know that Bold, Italic and Underlined are already implemented (Ctrl+B,I or U respectively). But newbies (and I'm doing a fair amount of proselitysing) don't know about them. Also, currently, any font changes are handled by editing the code within each .sm file. I think a font selector or a style sheet selector (I know, I asked this before...) would make for a smoother user experience.
Edited by user 18 February 2014 20:22:53(UTC)
| Reason: Not specified