Hi,

On Mon, 2007-12-17 at 00:12 +0000, William Skaggs wrote:

1) Changed the menu entry from "Edge" to "Sharp Edges". Having an entry called "Edge" in the "Edge-detect" category is silly, and the thing that distinguishes this plugin is that it detects edges between neighboring pixels, that is, sharp edges.

It's a basic principle of organization that the name of an item should not be the same as the name of a category. I don't care whether this plug-in is "Simple Edge" or "Basic Edge" or "Classic Edge", but it's wrong to have a plug-in called "Edge" in the "Edge-detect" category.

You have a point here. But you also need to look at the costs of renaming a menu item. The documentation needs to change and users need to learn the new name. With the amount of plug-ins that we have it is rather difficult to keep track of changes so IMO we should try to avoid them.

2) Added an "invert" control [...]

This seems to have been uncontroversial.

Adding it as a parameter to the plug-in-edge procedure is very controversial as it breaks the API. It looks as if you added it as an optional and hidden extra parameter. You can as well don't expose it to the PDB then.

Adding it to the UI is also difficult as it is not part of the standard algorithm that this filter implements (see below) and it mainly adds clutter to the user interface.

3) Changed the default method to Prewitt, which I believe gives the closest match to what users are hoping for. I renamed the method-selector menu from "Algorithm" to "Method", and renamed the Prewitt entry to "Default", also putting it at the top.

This was very controversial -- people feel that it is "dumbing down" the interface. I don't think so, and I would like to explain why. One of the principles of interface design is to show users the information they need to know, and *not* show them things that they don't need to know. Now, GIMP violates the second part of this in dozens of ways, so users quickly get in the habit of ignoring things they don't understand, but there is a price for this: users are never really sure what they must pay attention to and what they can safely ignore. (There has been a lot of improvement, but there is still a long way to go.)

Okay, let's apply this to the "Algorithm" setting. Do users need to know this? No, because (1) all of the methods give pretty similar results in most cases, with only subtle differences between them, and (2) even the majority of technically-oriented users don't know the meaning of terms like "Sobel", "Prewitt", "Gradient", etc.

This plug-in implements a fundamental algorithm in image processing. It is essential that we offer it and that we name it explicitely. If I was about to change the user interface of this filter, then I would go as far as showing the convolution matrix that is being used. Next to the matrix (which could be editable), there would be the selector for the classic presets of convolution kernels. If I remember correctly, we even have a bug report that asks for this.

As you already noted, this plug-in does not have much use for the casual user. But it is essential for anyone who wants to do scientific image processing. We should optimize this dialog for the professional who knows what he/she is doing and who certainly expects this filter to be available (and recognizable).

I would like you to revert all changes to this plug-in and discuss them here before any changes are being done in SVN.

4) Removed the "wrap-style" radio buttons from the interface [...]

This was a little bit controversial. Let me add that as far as I can see, it was a mistake to create these options in the first place. The idea behind the Wrap option was to let a user make tileable patterns, but it will actually have the opposite effect, by almost always drawing an edge at the border of the selection. I don't believe that anything except Smear is actually useful. Certainly showing users a set of choices labeled "Wrap", "Smear", and "Black" must be a bad thing to do -- even for sophisticated users.

This can be discussed. But going ahead and doing the change before it is being discussed is not acceptable.

Sven

On Dec 17, 2007 10:32 AM, Sven Neumann wrote:

As you already noted, this plug-in does not have much use for the casual user.

Quite in opposite. Edge detection is one of the steps to make sky not look pale on photos ;-)

Alexandre

4) Removed the "wrap-style" radio buttons from the

interface [...]

This was a little bit controversial. Let me add

that as far as I can

see, it was a mistake to create these options in the

first place. The

idea behind the Wrap option was to let a user make

tileable patterns,

but it will actually have the opposite effect, by

almost always drawing

an edge at the border of the selection. I don't

believe that anything

except Smear is actually useful. Certainly showing

users a set of

choices labeled "Wrap", "Smear", and "Black" must be

a bad thing

to do -- even for sophisticated users.

Please, don't remove the Wrap and Smear options, because it are useful (tileable patterns is a example).
Removing the functionality of GIMP isn't usability.

You can put them under a label named "border options" like the convolution matrix plug-in.

Sorry if my English is poor.

______________________________________________ ¿Chef por primera vez?
Sé un mejor Cocinillas.
http://es.answers.yahoo.com/info/welcome

Hi,

On Mon, 2007-12-17 at 20:21 +0000, William Skaggs wrote:

As I tried to explain, Wrap is not useful with edge detection. It is very useful with blurring, because it makes opposite edges look similar. With edge detection, all it does is to cause an edge to be drawn at the border of the selection

If it actually does that, then the implementation is buggy.

Bill, please revert all your changes to the Edge plug-in. When that that has happened, we can look at the plug-in again, isolate its problems and try to fix them.

When this development cycle started I said that I don't want to see any changes in SVN that haven't been announced and discussed beforehand. I was serious about that and I am not willing to accept that this policy is broken. I know that this can be annoying but I don't see how we can get 2.6 done in time otherwise.

Sven

William Skaggs wrote:

So I have a pretty coherent vision of which filters are useful for which tasks, and what sort of interface a user needs in order to make use of them. I feel that, given a free hand, I would be able very rapidly to turn GIMP's filter collection into something that the great majority of users, both experts and non-experts, would be much happier with. I wouldn't get everything right, of course, but I could make it a lot better.

And you do feel that the way to do this is to just commit things, and everyone else has to keep up with the changes without knowing what others are to be expected, and if something isn't right, we'll just have to revert it?

Michael

Hi,

On Mon, 2007-12-17 at 20:51 +0000, William Skaggs wrote:

You have a point here. But you also need to look at the costs of renaming a menu item. The documentation needs to change and users need to learn the new name. With the amount of plug-ins that we have it is rather difficult to keep track of changes so IMO we should try to avoid them.

I don't agree. I think that many changes are needed, and that the way to make things simple for documentation writers is to do them quickly and coherently. The thing that is *really* difficult for doc writers is to document things that they don't understand, or that have bad interfaces.

I believe, and I know that Peter believes, that the current collection of filters is an incoherent mess, assembled without any underlying concept of usefulness. Are we doomed to live with this forever?

Of course not. But I don't see how changing a perhaps badly chosen menu name to something that is as arbitrary and meaningless is going to help anyone. The only thing it does is causing confusion among our users. They will ask themselves why we keep changing the names of filters without any good reason.

The frustrating thing is that there seems to be no way to move in that direction. Any suggestion for change is met with, "please raise this question on the developer's list", which simply means "no", because it is easy to see that topics raised on the developers list never lead to decisions.

If no discussion happens, then you can take that as consensus that what you proposed is fine and that noone will object to see this change being made in SVN.

In any case, as Peter has pointed out, discussing each individual change separately is a bad approach, because it is impossible for people to understand the coherent vision that the changes are directed toward.

Perhaps. But just going ahead and doing individual changes on your own without even letting us know that you see yourself on a greater mission is definitely not the way to go.

Sven

Hi,

On Tue, 2007-12-18 at 00:23 +0000, William Skaggs wrote:

No! The way I did it was broken. But the whole process is broken. It is impossible to fix the interface if every tiny change can be vetoed by any random person. The question is, how to find a process that actually allows change to occur.

I would actually rather call that what you did "random changes". I am quite confident that if we had a look at the plug-ins and isolated their usability problems, then we could find solutions that we can agree on.

One thing that would help is to improve consistency in the plug-in user interfaces. For example, if there are several plug-ins that need to have a user interface for the border behavior, then this part of the user interface should look and feel the same in all those plug-ins. That would help our users more than if we removed this part of the user interface on the assumption that it is not useful.

Sven