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
