[Gimp-developer] New option for the fill tool (feature suggestion/request)
Sorry, I'm not a programmer so I wouldn't know how to do this myself but I'd like to suggest a new feature for the fill tool. How about an option to use the cursor position as a start point for tiling fill-patterns rather than the top left corner of the layer? Perhaps this could be greyed-out when fill mode is set to colours rather than patterns. I still want the whole layer/selection filled, but wherever the cursor is when I click it is where the top-left pixel of the filling pattern should be aligned to. I'd find this useful sometimes, would anyone else? _ Share life as it happens with the new Windows Live.Download today it's FREE! http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New option for the fill tool (feature suggestion/request)
Hi Shin, I'd hardly find this useful but for some very specific patterns. Instead, I'd suggest you tried using layers and layer masks in your workflow, more or less like this: once you select the area to be filled, create an empty layer, create a layer mask on it, choose from selection (and empty your selection afterwards) There you are - you now fill the whole layer with your pattern and transform it however you like, with translation (not move tool), scaling, rotation, etc... js -- On Thursday 22 November 2007 02:14:56 pm Shin Diggar wrote: Sorry, I'm not a programmer so I wouldn't know how to do this myself but I'd like to suggest a new feature for the fill tool. How about an option to use the cursor position as a start point for tiling fill-patterns rather than the top left corner of the layer? Perhaps this could be greyed-out when fill mode is set to colours rather than patterns. I still want the whole layer/selection filled, but wherever the cursor is when I click it is where the top-left pixel of the filling pattern should be aligned to. I'd find this useful sometimes, would anyone else? _ Share life as it happens with the new Windows Live.Download today it's FREE! http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007 ___ 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] finalizing the task list
On Nov 22, 2007 1:03 AM, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Wed, 2007-11-21 at 18:32 -0600, Chris Mohler wrote: On Nov 20, 2007 7:26 PM, Chris Mohler [EMAIL PROTECTED] wrote: Does this sound reasonable? Is there anything I missed? Any volunteers to work on this list? Formatted it a bit better: http://cr33dog.fedorapeople.org/misc/gimp_task_list_02.html http://cr33dog.fedorapeople.org/misc/gimp_task_list_02.ods This is a nice start, but I think we need a lot more information in the short description. So one row per task is certainly not going to be sufficient. But it's probably a good idea to finalize the structure and layout before we go into filling in all the details. OK. Should these tasks be added perhaps? http://wiki.gimp.org/gimp/ToDo I won't have much time to work on the list today, but I can make changes tomorrow or over the weekend. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New option for the fill tool (feature suggestion/request)
Shin Diggar wrote: Sorry, I'm not a programmer so I wouldn't know how to do this myself but I'd like to suggest a new feature for the fill tool. How about an option to use the cursor position as a start point for tiling fill-patterns rather than the top left corner of the layer? Perhaps this could be greyed-out when fill mode is set to colours rather than patterns. I still want the whole layer/selection filled, but wherever the cursor is when I click it is where the top-left pixel of the filling pattern should be aligned to. I'd find this useful sometimes, would anyone else? That sounds like a sane idea to me, but it's a sad to add another tool option for this. Would be great if you could figure out a way to add support for this without adding another tool option. You could try turning to gui.gimp.org for input. Regards, Martin Nordholts ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] using the GIMP donations
Sven Neumann wrote: Hi, On Thu, 2007-11-22 at 07:58 +0100, Martin Nordholts wrote: For quite some time I have thought about setting up a system that would allow donors to donate money to a specific feature, e.g. donate money to implement a Polygonal Selection Tool. The money in this Polygonal Selection Tool Pool would eventually raise to rather interesting levels, and the person that provides a patch that implements this tool would be eligible to collect the money in that pool. We discussed this in the past and the conclusion was that we don't want to accept money for specific features and that we consider bounties a bad idea. I am willing to pick up this discussion again but I can tell you that I haven't changed my mind on this and strongly oppose this idea. So my take on this is a strong no. And that's without even considering the huge administrative work and the legal problems that are involved. Sven On a second thought, yes it would be a bad idea to reserve money donated _not_ to specific things, for specific things. But I still can't see why it would be a bad thing to allow donors to donate money to specific features and what legal problems that would then arise. The administrative overhead would fall on me to the extent possible, and as long as patches are GPL and taxes etc are handled, what legal problems would there be? Maybe these problems are bigger than I currently see - Martin Nordholts ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] using the GIMP donations
From: Martin Nordholts [EMAIL PROTECTED] The administrative overhead would fall on me to the extent possible, and as long as patches are GPL and taxes etc are handled, what legal problems would there be? Maybe these problems are bigger than I currently see The problems are bigger than you currently see. Here are just some of them: 1) Do you really know how to make a payment to somebody in an arbitrary foreign country without violating either the law in your country, the law in the country where the GIMP funds are held, or the law in the country of the person who receives the money? 2) What will guarantee that you keep such good records that, should you suddenly disappear from the GIMP project, other people will be able to make sure that agreements are not violated? 3) What if somebody donates for a specific feature and then is unhappy with the result? 4) What if you pay somebody for a feature and then find that the code is not usable because it violates a copyright or patent? Etc, etc, etc. Let me point out that there is nothing to forbid a company from paying somebody to develop a GIMP feature, so long as the company itself manages all the finances and contracting. Best wishes, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] using the GIMP donations
Martin Nordholts wrote: But I still can't see why it would be a bad thing to allow donors to donate money to specific features and what legal problems that would then arise. The administrative overhead would fall on me to the extent possible, and as long as patches are GPL and taxes etc are handled, what legal problems would there be? Maybe these problems are bigger than I currently see Many volunteer developers might be put off by the fact that the GIMP project is compensating certain contributors while others are expected to perform basically the same tasks for free. Gaining a few developers on compensated projects might very well result in an overall loss in development contributions. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] some gimply thoughts
On Nov 23, 2007 6:03 AM, GSR - FR [EMAIL PROTECTED] wrote: Hi, [EMAIL PROTECTED] (2007-11-22 at 1544.46 +1030): Hi Liam, On Nov 22, 2007 9:45 AM, Liam R E Quin [EMAIL PROTECTED] wrote: Evidence that auto levels loses details -- take a photograph (or a scanned engraving, or whatever) and open Levels, and press autl. Note that the little triangles marking the end-points are not under the ends of the black part - in The 'Value' controls are not effected by 'Auto'. Look at the R,G,B,(A) controls instead. And then you see it changes them, in a destructive way. All 'Auto' does, is: 1. Set the input range to min(CHANNEL), max(CHANNEL) -- ie the lowest used value of that channel in the picture, and the highest used value of that channel in the picture. No, it does not. It sets min and max inside the histrogram used range (play with Lin/Log setting if this is not clear). There is a way anybody can test it: 1 Create new image, 512*512 2 Render plasma, with seed 0 and turbulence 1 3 Run Levels, click the auto button, look at all the channels OOPS! You get: R 9 1.0 229 | 0 255 G 12 1.0 194 | 0 255 B 25 1.0 241 | 0 255 Those settings are destructive, Red 0-9 becomes 0, Red 229-255 becomes 255, and so on. You can look for such pixels before applying the operation, mark with guides or points, then look what they are after. You can also look at the code and see how it iterates over the histrogram until it decides it has eaten enough. It does not stop when it reaches the first non zero, which would be non destructive (as in any input channel value gets mapped to a new, different, output value, rounding and precission issues aside). Okay, well this is not what I expected and I won't be using Levels Auto in the future - I hate clipping. I had thought that Auto was supposed to perform the same function as Colors-Auto-Stretch contrast -- to stretch the current R,G,B range ends to 0,255, clearly it doesn't. It would be nice to have an Auto button in Curves that did achieve this result. 2. Set the output range to 0, 255 for each CHANNEL in R,G,B (and possibly A) Because the output range is full, there is literally no way that this operation can reduce detail. If the input range is not full, there is loss, as shadows and highlights are lost and become flattened, grouped in the same result. GSR ___ 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
[Gimp-developer] OpenPalette Implementation.
Hi, I would like to ask for the development team's consideration for implementing the OpenPalette format for their palettes. OpenPalette is really hoping for a medium with interoperability and flexibility. The file format is XML-based; there's a DTD and XSD already written and ready for business. There's a lot more information at the site (http://openpalette.uk.to), if you are willing to look into it. You can also download a PDF concerning OpenPalette here. Thanks; if you have any questions, I'm ready to answer. - Never miss a thing. Make Yahoo your homepage.___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] OpenPalette Implementation.
Hi, I would like to ask for the development team's consideration for implementing the OpenPalette format for their palettes. OpenPalette is really hoping for a medium with interoperability and flexibility. The file format is XML-based; there's a DTD and XSD already written and ready for business. There's a lot more information at the site (http://openpalette.uk.to), if you are willing to look into it. You can also download a PDF concerning OpenPalette here. Thanks; if you have any questions, I'm ready to answer. It would seem straightforward enough to have GIMP load or save your OpenPalette files -- a plug-in could easily be written or the built-in function enhanced to offer the option. It would be beneficial to have a common format for palettes shared between different editing programs; however, adoption as a replacement for the current palette file format would up to others. The format seems rather wasteful of filespace, with the tags using about three times the space of the data; but I guess that's the nature of XML (and I am trying to get over decades of being a bit-pincher). I feel it is a requirement that your format support some way of declaring the palette's license, which would typically be a couple of dozen lines in length. Owing to the length, perhaps a separate tag should be allowed for. The same could be said about a comment field, offering multiple lines of descriptive commentary could prove useful. I would assume that your format will eventually have the type attributes for the value element expanded to include more than just the 24-bit RGB colorspace. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: my summary.
Hi, On Thu, 2007-11-22 at 08:47 +0100, [EMAIL PROTECTED] wrote: I find it rather arrogant to presume that those who can code are the only ones who can contribute to development and as a consequence anyone who can code is also an authority on graphic design and UI implementation. I have never presumed that and I think that this should be very clear from the discussions on this list. You completely ripped my argument out of context and a public apology for this accusation would be proper. Most of your input lately is rather destructive and it certainly not helpful in the process of improving GIMP and its development process. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] finalizing the task list
Hi, On Thu, 2007-11-22 at 10:55 -0600, Chris Mohler wrote: OK. Should these tasks be added perhaps? http://wiki.gimp.org/gimp/ToDo They should be considered, and as far as I can see, this has happened. But they don't belong on the task list unless we decide that they should go there. This list on the Wiki is a list of user wishes, added by less than a handful of users. It is very important that we listen to such requests. But our challenge is to use this information to identify the problems that the users are trying to address here. Then we can look for solutions that fit into the bigger picture. The bigger picture which is defined by our product vision and by the wishes and requests of all users. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] using the GIMP donations
Hi, On Thu, 2007-11-22 at 18:12 +0100, Martin Nordholts wrote: But I still can't see why it would be a bad thing to allow donors to donate money to specific features and what legal problems that would then arise. What would be the advantage if we allowed it? I can only see disadvantages if we allow people to use their money to influence our decisions on the future of GIMP. And I also expect that it will have a negative effect on the overall motivation of developers to work on the code for free. The administrative overhead would fall on me to the extent possible, and as long as patches are GPL and taxes etc are handled, what legal problems would there be? Maybe these problems are bigger than I currently see I am sure there are many that you and me can't even imagine. But I don't see the point in discussing the legal and admininstrative problems unless we first come to the conclusion that we consider bounties and feature-bound donations a good idea. And so far the consensus on this list and on GIMP developer meetings has been that it isn't. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
