Re: [Gimp-developer] Some changes to the "Edge" plug-in
Hi, On Tue, 2007-12-18 at 00:23 +, 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some changes to the "Edge" plug-in
Michael Schumacher wrote: > 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? 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. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some changes to the "Edge" plug-in
Hi, On Mon, 2007-12-17 at 20:51 +, 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some changes to the "Edge" plug-in
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 -- GIMP > http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki > http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins > http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some changes to the "Edge" plug-in
Hi, On Mon, 2007-12-17 at 20:21 +, 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some changes to the "Edge" plug-in
Sven 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? I am only an average programmer, and there are many things about GIMP that I don't understand, but I *am* an expert on image processing. I have a pretty good understanding of algorithms and their advantages and disadvantages -- I can tell you, for example, why Gaussian blur is much faster than Selective Gaussian Blur, and what will go wrong if you try to apply the same speed-up trick to Selective Gaussian Blur. I know the difference between the Sobel and Laplace algorithms for edge detection. I can tell you why Lighting Effects creates ugly artifacts on the pixel scale, and how the algorithm should be changed to fix this. And so on. As an expert, I have a pretty good sense of which techniques are useful, both for experts and ordinary users, and what it takes to use them. I can tell you, for example, that it is quite wrong to say that edge detection is only useful for image processing experts. It is essential for all kinds of artistic effects: just try putting an edge-detect layer on top of an image, and playing with layer mode and opacity, and you will quickly get a sense of the possibilities. 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. 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. 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. > This can be discussed. But going ahead and doing the change > before it is being discussed is not acceptable. That simply means that no change can ever be made. This is really the heart of the problem. Fixing it doesn't mean ignoring people's opinions, it means having some way to override opinions that are uninformed and arrive at a decision that can be implemented. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some changes to the "Edge" plug-in
From: Csar Rolln [EMAIL PROTECTED] > 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. 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 -- an ugly, uneven edge in the great majority of cases. For tiling, the goal is to *avoid* making the border of the selection visible. I think you probably have never actually tried to use the Edge plug-in in this way, or you would have seen this for yourself. -- Bill___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some changes to the "Edge" plug-in
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some changes to the "Edge" plug-in
Hi, On Mon, 2007-12-17 at 00:12 +, 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@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some changes to the "Edge" plug-in
William Skaggs wrote: > 2) Added an "invert" control, so that you can see the edges as dark >lines on a light background. Without this, the preview is almost >useless. I did some voodoo to make "invert" the default for >interactive use, but not to change the result when "edge" is called >from the PDB. The new "invert" argument is optional. If it is >omitted, a value of FALSE is used, which gives the same behavior as >the plug-in has had previously. How was invert added as an optional parameter? Script-Fu is picky in that it checks the number of arguments being passed in a PDB call against the number of arguments listed when the function was registered. If you don't add the parameter to the list of arguments in the register call, how is a user to ever discover the optional parameter since it won't be shown in the Procedure Browser. If you do add the parameter to the list of arguments in the register call, users can discover the existance of the new parameter but you run the risk of breaking any Script-Fu scripts which only pass the original number of parameters. -- Cheers! Kevin. http://www.ve3syb.ca/ |"What are we going to do today, Borg?" Owner of Elecraft K2 #2172 |"Same thing we always do, Pinkutus: | Try to assimilate the world!" #include | -Pinkutus & the Borg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some changes to the "Edge" plug-in
Okay, that provoked a lot of controversy on #gimp. Let me follow up here because it's easier to say things in a coherent way. > 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. 2) Added an "invert" control [...] This seems to have been uncontroversial. > 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. If we pop up the dialog showing a menu with "Algorithm: Prewitt" displayed, then the message this conveys is, "You need to know that the Prewitt algorithm is being used". On the other hand, if we pop up a dialog showing "Method: default", then the message is, "you don't need to know what method is being used, but you can change it if you want to". I believe that the second message is the correct one, even for the great majority of technically-oriented users. 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. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
