[Gimp-developer] Re: Gimp usability tests

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>From: Nathan Carl Summers <rock@xxxxxxxx>
>
>> Test the crop tool too -- it fails for large images as well, or when
>> zoom is used for seeing image details.
>
>It would be very useful if we can determine which are the biggest
>impediments to usability here.

I have gimp 1.2.3; has the crop tool changed since?
The crop tool has these problems:

 -Crop rectangle can be resized only from two corner points;
  in a large image with zoom-in, only what may be visible is the edge
  of the crop rectangle, but the edge cannot be grabbed and dragged
  (which would desirable); likewise, only the move-corner may be
  visible and thus the rectangle cannot be resized

 -The crop tool appears only in one of the views (of the same image);
  the crop rectangle cannot be resized on the view where the
  resize-corner is visible (the other view would be used to observe
  when the rectangle is good)

 -Undo of the crop operation does not return to the same state;
  the crop rectangle is lost -- though, redo does work but there is
  no hint on what rectangle is being cropped

 -When crop is started, the crop tool dialog appears annoyingly
  in the front; dialog has to be moved before the cropping can be
  continued

 -The dialog follows to different desktops (in Gnome) (but so does the
  main dialog)

These are not problems to me, but I will mention them here:

 -Considering the above undo problem, a plain click to center of the
  crop rectangle maybe should not launch the crop operation (ctrl+click
  would work better)

 -When pointer moves outside of the image, then distance between
  the pointer and the dragged point grows 

>There are three factors which come to the top of my mind:
>
>1) The extreme brokenness of autoscroll. Autoscrolling tools currently
>scroll far too quickly to be useful in most cases.

Had not been problem here. I make the initial crop rectangle, then
zoom-in and pan, and then resize the rectangle (when possible).

>2) Users may not be aware of how to change zoom levels without loosing
>tool state.

Not problem here.

>Or, in the case of the rectangular select tool, there is no
>real way to usefully change the zoom, since the entire operation must be
>performed in a single drag manuver.

Yes, but then I prefer make initial selection and then would resize
after zoom-in and pan. I don't need zoom-in in the middle of the
dragging.

>3) The interface mechanics (feel) of the tools may need some redesign.
>For instance, maybe the crop tool should automatically size itself to the
>bounds of the current selection.

Ok.

>Perhaps the rectangular selection tool
>should work somewhat like how the old bezier select tool did (where you
>could edit the outline of the selection by clicking at the right points,

All vertex and edges could be grabbed and dragged. This would solve
the problem where I have zoomed-in and only a part of the edge is
visible.

>This would, of course, make selection CSG operations more difficult

Keep all current selection methods, and add new unirectangle selection
method.

Note that the unirectangle tool would work this way:
The tool maintains the rectangle vertex/edge model. When the grabbing
is released, the vertex/edge model stays and the selection mask is
created. When the vertex/edge model is re-grabbed, the selection mask
is undoed. When the tool is finished, the selection mask stays and
can be reshaped with the other selection tools.

Therefore, there is no need for CSG operation within the unirectangle
tool.

>If you have any suggestions I haven't covered here, I would be interested
>to hear them.

When the unirectangle tool is on, the vertex/edge model of the rectangle
should be editable in the manner used in CAD software. Handling one
rectangle would be relatively easy, but what if we later need similar
system for more complex objects? Then we should have a better tool
for handling such objects and operations on them.

My suggestion is that we add Qoca constraint solver to the GIMP CVS for
easy testing. I'm not familiar with any constraint solver, but such
a solver made the first interactive drawing program at 1962 more
powerful than many software today. I have placed a few selected
papers, including Qoca related papers, available at
  ftp://ftp.funet.fi/pub/sci/audio/devel/constraints/
 http://ftp.funet.fi/pub/sci/audio/devel/constraints/

Regards,
Juhana

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux