Re: [Gimp-developer] finalizing the task list
Hi Bill, On Sat, 2007-12-15 at 18:18 +, William Skaggs wrote: I think I probably would be able to come pretty close to turning the list that Chris Mohler created into a more-or-less complete 2.6 roadmap I don't think that a roadmap for 2.6 is what we are aiming for, at least not for publishing on the website. What we actually need is a not-too-long list of interesting tasks that shows where GIMP is heading. These tasks should be things that we agreed on, things that we are sure we want to see implemented sooner or later. Some of the items on this list can be marked as scheduled for 2.6, but most things on it will probably be open. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP at the 24C3
Hi, as announced earlier, some GIMP developers are going to meet at the 24th Chaos Communication Congress (24C3) http://events.ccc.de/congress/2007/ We already discussed that travel costs for such events should be reimbursed from GIMP donation money. For this event, I would like to transfer EUR 1000 from the GIMP account. We would use that money mainly for travel costs. Should something be left, we will spend it on pizza. Does anyone see a problem with that? Please object now or never... Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP at the 24C3
hey! in this context i wanted to announce that i'm still searching some folks for presenting the gimp on the chemnitz's linux days in march 2008! chemnitz is in south-east germany. i'm looking for advanced users or developers, preferedly from germany. there are waiting 2 days of sitting 'round and answering questions and doing 1 or 2 workshops. there will be approx 3000 visitors... i belive that traveling coast will be indemnified. food and housing by organzizer. you will just need your laptop or pc. if there are give-aways or some stuff to sell, tell me... http://linux-tage.de hope my english is not too bad and someone is interested sebastian Am Sun, 16 Dec 2007 13:48:51 +0100 Sven Neumann [EMAIL PROTECTED] babbelte: Hi, as announced earlier, some GIMP developers are going to meet at the 24th Chaos Communication Congress (24C3) http://events.ccc.de/congress/2007/ We already discussed that travel costs for such events should be reimbursed from GIMP donation money. For this event, I would like to transfer EUR 1000 from the GIMP account. We would use that money mainly for travel costs. Should something be left, we will spend it on pizza. Does anyone see a problem with that? Please object now or never... Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Sebastian Laube http://blog.emuman.org http://emuman.org icq 150923421 jabber: [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP at the 24C3
On Sunday 16 December 2007 09:48, Sven Neumann wrote: Hi, as announced earlier, some GIMP developers are going to meet at the 24th Chaos Communication Congress (24C3) http://events.ccc.de/congress/2007/ We already discussed that travel costs for such events should be reimbursed from GIMP donation money. For this event, I would like to transfer EUR 1000 from the GIMP account. We would use that money mainly for travel costs. Should something be left, we will spend it on pizza. Does anyone see a problem with that? Please object now or never... never. :-) Enjoy it! js -- Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ 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 disclaimer/favourite | -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
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
