Re: [Gimp-developer] next generation size entries

2007-12-18 Thread Simon Budig
Martin Nordholts ([EMAIL PROTECTED]) wrote:
 Simon Budig wrote:
  Martin Nordholts ([EMAIL PROTECTED]) 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

-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] next generation size entries

2007-12-17 Thread Martin Nordholts
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
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] next generation size entries

2007-12-17 Thread Simon Budig
Martin Nordholts ([EMAIL PROTECTED]) 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
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] next generation size entries

2007-12-17 Thread Martin Nordholts
Simon Budig wrote:
 Martin Nordholts ([EMAIL PROTECTED]) 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
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] next generation size entries

2007-10-27 Thread Alexandre Prokoudine
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
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer