Hi,

Juhana Sadeharju writes:

I'm puzzled: do you people make perfect initial selections or how you scope with the problem? Do you have any problems at all? Why not? (I could gather a couple of examples if you think there are no problems at all.)

The fact that the selection tools need to be improved is well known, thus your rant is completely pointless.

In audio editors, the selection can be re-adjusted easily by grabbing and dragging the selection edges. I proposed similar rectangular selection tool for GIMP here a few months ago.

This has been proposed years ago and if someone gets around to implement it, the patch will certainly be accepted.

(GIMP does not anymore compile in my Linux -- we should work out the tools together, if at all.)

Well, something is wrong with _your_ Linux then. But unless you tell us about your problems, we won't be able to help you.

Sven

Hi,

Juhana Sadeharju writes:

Does GIMP compile in unpatched RedHat 9? RedHat 9 is already a year old, which is a long time.

Probably not without updating a few libraries. Please read the file INSTALL. The dependencies are clearly outlined there. www.gimp.org has a detailed list also.

Sven

On Wed, 21 Apr 2004, Juhana Sadeharju wrote:

From: Roman Joost

Tasks for the first test (all-day-usage; all of the are common tasks for all people, except the one where the indicated group is mentioned):

Could you also make a proper usability test for the rectangular selection? I seem to be forced to use the re-try approach where I start making the rectangular selection from scratch if it goes wrong (and the initial fine-tuning never goes right at first time!).

It also seems to be impossible to make precise selections in large images (e.g., 800x800 to 6000x6000). Both large selections and long narrow selections on large images are trouble. If zoom-in is used, even relatively small images becomes "large".

This is a good idea for a usablilty test subtask. While the difficulties with the selection tools are well known by the developers, that doesn't change the fact that a usablilty test can show the extent to which it is a problem. (In fact, usablilty tests often start with known or suspected weaknesses.) I for one would be interested in seeing the results, should your suggestion be added to the test.

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. 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.

2) Users may not be aware of how to change zoom levels without loosing tool state. 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.

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. 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, or cause the selection change to actually occur by clicking in the center.) This would, of course, make selection CSG operations more difficult, so perhaps a third method, where the only selection operations are select the interior of a path, invert, and QuickMask, may actually be more useable, and should be tested as well.

I'm puzzled: do you people make perfect initial selections or how you scope with the problem?

Generally what I do is make a "rough cut" in the large and then adjust the selection using the CSG operations. This is pretty unsatisfying sometimes, as you mention, like when you need to move the boarder of a wide selection up a few pixels. Often that requires a lot of adding and subtracting before you get it right.

If anyone wants implement the unirectangular selection tool and/or improve the crop tool, please don't hesitate ask my improved designs. (No patent pending.)

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

(GIMP does not anymore compile in my Linux -- we should work out the tools together, if at all.)

I'm having a difficult time understanding what "we should work out the tools together, if at all" means, but I assume you meant to say that you wouldn't mind help getting GIMP to compile on your machine, which of course the GIMP developers are more than happy to help with. Unfortunately, due to the fact that there are many things that could potentially be at issue here, and Burrito, the GIMP developers' official psychic, has been a little vague as of late, it would probably help us to know more specifically what problem you are having. The last error messages you got (other than the annoying "Make [56872165]: leaving subdir foo/bogus/stuff: Error 1" messages) are most likely to be useful.

Rockwalrus

Hi,

Nathan Carl Summers writes:

1) The extreme brokenness of autoscroll. Autoscrolling tools currently scroll far too quickly to be useful in most cases.

I remember a patch for smooth autoscrolling. That would certainly improve things. Now where was that patch again ...

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. 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, or cause the selection change to actually occur by clicking in the center.)

The problem with readjustable selections is that selections are basically grayscale masks. So what appears as a rectangular selection to you is just a buffer of numbers to The GIMP. Readjusting the selection basically means transforming this grayscale mask. Such a transformation will always introduce errors and fuzzyness.

In order to improve this, we should probably ditch the rect and ellipse select tools and replace them with vector tools. The path tool as it is implemented now is just a special case of a vectors tools and it shouldn't be too hard to implement tools to create basic shapes. These shapes could then be converted to a selection, just like Path->To Selection works now. But I think that's exactly what you were proposing also, isn't it?

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

Simon said that implementing CSG operations on vectors would be not feasible. But IMO it would be a prerequisite for better selection tools. Since Inkscape introduced add, subtract, intersect and union for vector shapes lately, I don't see why we shouldn't manage to do the same.

Sven

Sven Neumann (sven@gimp.org) wrote:

The problem with readjustable selections is that selections are basically grayscale masks. So what appears as a rectangular selection to you is just a buffer of numbers to The GIMP. Readjusting the selection basically means transforming this grayscale mask. Such a transformation will always introduce errors and fuzzyness.

In order to improve this, we should probably ditch the rect and ellipse select tools and replace them with vector tools. The path tool as it is implemented now is just a special case of a vectors tools and it shouldn't be too hard to implement tools to create basic shapes. These shapes could then be converted to a selection, just like Path->To Selection works now. But I think that's exactly what you were proposing also, isn't it?

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

Simon said that implementing CSG operations on vectors would be not feasible. But IMO it would be a prerequisite for better selection tools. Since Inkscape introduced add, subtract, intersect and union for vector shapes lately, I don't see why we shouldn't manage to do the same.

Ok, maybe you misunderstood me or I expressed it the wrong way: It would of course would be very good to have CSG operations available, but I am not particularily eager to implement them: I don't have a lot of experience dealing with the floating point issues that are basically unavoidable. The stuff in libart unfortunately only operates on straight line segments, which is not feasible when dealing with user-created objects (you don't want to make beziers a sequence of straight lines, when the user should be able to edit that stuff after the CSG operation...).

I did not yet look at the stuff in Inkscape.

Bye, Simon

Hi,

Simon Budig wrote:

Sven Neumann (sven@gimp.org) wrote:

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

Simon said that implementing CSG operations on vectors would be not feasible.

Ok, maybe you misunderstood me or I expressed it the wrong way: It would of course would be very good to have CSG operations available, but I am not particularily eager to implement them:

I hope I'm not the only one asking myself this question... what is a CSG operation?

Cheers,
Dave.

dneary@free.fr (2004-04-22 at 2052.21 +0200):

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

Simon said that implementing CSG operations on vectors would be not feasible.

Ok, maybe you misunderstood me or I expressed it the wrong way: It would of course would be very good to have CSG operations available, but I am not particularily eager to implement them:

I hope I'm not the only one asking myself this question... what is a CSG operation?

Constructive Solid Geometry. I have seen it mostly in 3D apps, ie, you have solid cube and you substract a solid cilinder and get a cube with hole, then you had a piramid on top, and you end with a home like thing with a hole, and so on. With 2D (closed) vectors it should be similar, add, substract and interesect them to get different shapes.

GSR

On Thursday 22 April 2004 15:52, David Neary wrote:

I hope I'm not the only one asking myself this question... what is a CSG operation?

CSG stands for "Constructive Solid Geometry", and is used to refer to operations like "union", "intersection", "add" and "subtracting" geometric forms in a computer represented drawing.

Obviously "Solid" doesn't apply here. :-) Maybe we could use "CPG" - Constructive Plain Geometry instead ?
Nonetheless, the acronym is widely used enough that I and the at least those who replied on this thread could promptly understand what it was about.

Cheers,
Dave.

Hi,

GSR - FR wrote:

dneary@free.fr (2004-04-22 at 2052.21 +0200):

I hope I'm not the only one asking myself this question... what is a CSG operation?

Constructive Solid Geometry.

Oh, *that* CSG. Why didn't you say so? Sheesh, of course I knew *that*...

Cheers,
Dave.

GSR - FR wrote:

dneary@free.fr (2004-04-22 at 2052.21 +0200):

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

Simon said that implementing CSG operations on vectors would be not feasible.

Ok, maybe you misunderstood me or I expressed it the wrong way: It would of course would be very good to have CSG operations available, but I am not particularily eager to implement them:

I hope I'm not the only one asking myself this question... what is a CSG operation?

Constructive Solid Geometry. I have seen it mostly in 3D apps, ie, you

Hmm. I thought it meant Ctrl-Shift-[Alt/]Graph

have solid cube and you substract a solid cilinder and get a cube with hole, then you had a piramid on top, and you end with a home like thing with a hole, and so on. With 2D (closed) vectors it should be similar, add, substract and interesect them to get different shapes.

Sounds like the same thing to me. ;-)

Chris

On 04/27/04 09:25, Juhana Sadeharju wrote:

-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

Would it be possible to solve this issue by placing "transient corners" on the image? By this I mean: leave the four corners as-is, but if the visible image does not contain two corners (one of which is move, the other must be resize) to place "transient" or "psudo-corner" grippies on the extremes on the visible crop selection?

IE: you've zoomed in on a portion of the selection so that the only thing visible is the vertical selection bar, no corners. A grippie appears at the top of the visible screen as though there were a corner grippie that allows horizontal resizing. A similar grippie appears at the bottom allowing horizontal moving. Similar but complimentary for verticals. Would this be hard to implement?

regards, Chris