On Sun, 27 Jan 2008 12:39:13 +0100, Fredrik Alstromer wrote:

As requested, I'm moving this discussion to the mailing list... for the history, see the bugzilla entry 76616.

Just to get a few things straight, I've stumbled on the fact the you can't do simple arithmetic expressions in any widget whatsoever (most prominently, boundary measurements), and I figured, since this bug had been open since 2002, there probably wasn't much going on, so just to get the pot stirring a little I hacked together a little recursive descent parser / evaluator.

Hi,

you may like to look at this bug I originally opened on gimp but later got transfered to gtk+ since that project controls the widget. I provided a patch but it's been dead in the water for over a year. http://bugzilla.gnome.org/show_bug.cgi?id=358137

Even a trivial mod like that seems too much for gtk to deal with so you may need to consider the chances of adding the behaviour you want. That almost certainly means gimp will need to derive it's own replacement for spin widget which seems to be the direction you are heading anyway.

Assuming you can get acceptance of your idea, which seems like a very useful feature, you may like to consider the drag and drop angle as well. I patched gtk+ locally because it was a constant hindrance to just about everything I do with gimp.

gg/

The common problem that I can see everyone is trying solve is to have the result of a math eqn in the entry boxes. Beware of the random idea that follows. And feel free to kick my butt- I am someone who has resisted to look at the code for six years.

GIMP Calculator (or the "Script-Fu console for the masses"): This has access to all the elements of the current running GIMP. Much like the Script-Fu console. The main difference is this can live as a Dialog (like any other dialog - layers, fonts, brushes,etc). Another difference being, unlike script-fu console, the gui is geared at quick access to all the details. That is , with autocompletion, quick ways to choose window, layer , drawable, etc. Choosing their properties also should be easy.
It should be able to accept normal equations rather than scheme. The result should be draggable and droppable in any corresponding entry widget. It should also be able to leverage the "color picker" and "measure" tools.
Another main difference from script-fu should be that it cannot modify the current state of the GIMP - remember - it is just a calculator.

That will allow me to do flexible calculations like - The size of new icon(image) must be 2.7 times the last icon i created. and just drag the results into the "new image" dialog. The workflow i see is :
I go to the "Document History" dialog, pull the image I want to measure into the calculator - the calculator expands it into whatever it wants . I type a dot after that (to access the property) and it gives me a list of properties in a autocomplete box. I complete it to "dimensions" or "size" and add "* 2.7"

It shows the result as a draggable "measurement" widget. which i can drag to the new window dialog.

The above looks like too many steps, but the repeatable manner makes it fast - the human mind need not search for the information.

Hi,

On Mon, 2008-01-28 at 16:50 +0000, William Skaggs wrote:

I don't have anything to say about how this should work, but I'd like to make some suggestions about the approach to development. Mostly it should be possible to do this in a modular way -- evaluating expressions doesn't really have anything to do with the details of size entries. So I suggest your effort should go into writing a function that looks like

gchar *gimp_math_expr_parse (info, expression)

But Frederick did exactly that already. The code he attached to the bug report does this.

What needs to be done now is to get straight what exactly we expect from the parser/evaluator and to adapt that code to the GIMP coding conventions and GIMP unit system.

Sven