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 _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
