On 10/27/07, Sven Neumann wrote:

On the user interface side we would want a variety of widgets that can be used with the size models. Scales/sliders should be supported as well as spin-buttons with unit menus and entries that allow the user to input text such as "4.5 cm".

In some cases some simple math equations support would be useful. E.g. being able to input "4.5 cm + 2.7", press Enter and see "7.2cm". Is it part of the plan?

Alexandre

Sven Neumann wrote:

Moin,

I would like to propose another project. Whether we want this for 2.6 or later pretty much depends on whether we find someone who wants to work on this. But I think we absolutely need this if we want to improve our user interface.

What I am talking about is size entries. Widgets that allow the user to specify a size either in pixels, physical units or relative to some other size. Such widgets usually show up in groups and the relationship between them needs to be considered as well. We currently have a widget for this and it is

(a) cumbersome and error-prone to use from a developer point of view

(b) cumbersome to use from a user point of view

(c) ugly and needlessly large

It would be great if we could develop something to replace all our size entries. We want something that is flexible enough to cover the complex cases (see for example the Print Size dialog or the SVG import plug-in), but it should still be straight-forward to use for the simple case.

We definitely need an architecture here that follows a model-view concept. Code that deals with changes to sizes shouldn't have to care about the widget that the user actually deals with. At some point I have experimented with something into this direction. The result is GimpUnitStore and GimpUnitComboBox as found in the app/widgets directory. Definitely far from what we need, but perhaps looking at this code can give some ideas about how one could tackle the problem.

On the user interface side we would want a variety of widgets that can be used with the size models. Scales/sliders should be supported as well as spin-buttons with unit menus and entries that allow the user to input text such as "4.5 cm".

I think it is important to first get a very good idea of what the requirements are. It would be good to have a list of use cases and a pretty good specification of the user interface. Then we can think about a model to cover this.

Sven

Hi

I'm currently interested in looking into this, mostly because I think this needs a clean solution before I will be able to cleanly finalize the GimpRectangleTool.

Wouldn't some kind of hierarchical model-view be useful here? One would associate a unit-dependant widget with a list of "unit-models"("model" as in "model-view") in a hierarchical manner, where the bottom unit-model would be the unit-model in use for the image worked on.

Let's discuss this with the Size-entries in the Rectangle Select Tool Options as an example of how this hierarchy could be set up. The Width entry would be associated with unit-models in the following order:

1. its own unit-model 2. the other (Height) entry unit-model 3. The image unit-model.

This would mean that if no units were specified in the Rectangle Tool Options, the unit for the Width-entry would be the unit of the unit-model of the the image. If the Width-entry contains 100 and the image unit is mm, changing the image unit to cm would change the Width-entry to contain 10. Maybe even writing out "10 cm" would make sense.

If the user then wrote "3 m" (meters) in the Height entry, the Width entry would start to use the unit of the Height-entry instead since that is closer to it in the unit-model hierarchy, so it would display 0.01m.

Finally the user could write something like "0.01m in inches" in the Width entry and the Width entry would then activate it's own unit-model and use inches instead.

Erasing the unit in the Width unit could deactivate its own unit-model and it would fall back on using the unit-model of the Height entry if that would be active, otherwise use the unit-model of the image.

Now, the UI and coding details here are very fuzzy, and the exemplified unit-model hierarchy is questionable. I just wanted to throw the idea of hierarchy-based unit-models onto the list and maybe get some feedback on it.

This would need a lot more thought, and my current plan is to put more thought into this whenever I have some GIMP hacking time over.

The general approach would be to create independent families of classes of which objects then could be combined in different ways to create the desired widgets and families of widgets with the desired behavior.

- Martin Nordholts

Martin Nordholts (enselic@gmail.com) wrote:

I'm currently interested in looking into this, mostly because I think this needs a clean solution before I will be able to cleanly finalize the GimpRectangleTool.

I have a prototypeish parser running here, specified with yacc:

$ ./parseunit 2m + 3in
Result: 2.076200 m
40cm / 2in
Result: 7.874000
2m * 3ft
syntax error
2m * 3ft / 2in
Ergebnis: 35.998171 m

It kind of tries to track the dimension of the value entered and currently bails out for dimensions > 2. Not very reliable but it might help for a good start of the parser.

If you're curious I'll put the code online somewhere.

Bye, Simon

Simon Budig wrote:

Martin Nordholts (enselic@gmail.com) wrote:

I'm currently interested in looking into this, mostly because I think this needs a clean solution before I will be able to cleanly finalize the GimpRectangleTool.

I have a prototypeish parser running here, specified with yacc:

If you're curious I'll put the code online somewhere.

Please do, it would be useful to have a look at it.

Thanks, Martin

Martin Nordholts (enselic@gmail.com) wrote:

Simon Budig wrote:

Martin Nordholts (enselic@gmail.com) wrote:

I'm currently interested in looking into this, mostly because I think this needs a clean solution before I will be able to cleanly finalize the GimpRectangleTool.

I have a prototypeish parser running here, specified with yacc:

If you're curious I'll put the code online somewhere.

Please do, it would be useful to have a look at it.

http://www.home.unix-ag.org/simon/files/parseunit.y

I am not really convinced that it is a good idea to track the dimension of the entry with the grammar, it probably is easier to do this generically in the code and later check that the final result has dimensions 1 or 0 (default unit).

Bye, Simon