Re: [Gimp-developer] astronomical use of GIMP
2010/11/18 Łukasz Czerwiński lc277...@students.mimuw.edu.pl: Another limitation of using GIMP for a 3 color image is that GIMP does not use what are known in Photoshop as Adjustment Layers. Adjustment Layers How about adding this missing feature to GIMP? Best wishes, Łukasz Czerwiński I am under the impression that the functionality of adjustment layers are a very tiny subset of the capabilities that GIMP will have if GEGL is ever integrated. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Definition #5 is bad, but what about #1-4???
On Wed, Oct 28, 2009 at 7:35 PM, vabijou2 vabi...@yahoo.com wrote: Lame, crippled, inept, deficient, or sexual deviant . I get that it's an acronym, but that doesn't mean it isn't incredibly strange to want to associate a project that the developers are proud of with any of these interpretations! You are restarting an argument that is already a decade old, and has been fought to conclusion a dozen times over. If you REALLY think it needs to be revisited, read all of the old posts and come up with a new point to make, or at least address the reasoning given repeatedly for not changing. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Would single-window fix usability nightmares?
On Wed, Oct 21, 2009 at 5:54 PM, Ilya Zakharevich nospam-ab...@ilyaz.org wrote: I can see how a John Do can blame GIMP for GTK+ issues, but I don't see why GIMP developers should bother about John Do's misconceptions about software development. These are not misconceptions. Software does not modularize; at least not in the sense of dilution of responsibility. If you use a library, its bugs BUG YOU. Of course software responsibility modularizes. When World of Warcraft had graphics glitches on DirectX but not on OpenGL, whose fault was that? If your answer was Microsoft, move to the head of the class. WoW users complained to Blizzard, who responded Microsoft's library is broken, switch (temporarily). Everyone waited for Microsoft to fix the DX problem (which never happened, ATI and nVidia implemented workarounds in their drivers instead). Expecting Blizzard's developers to fix (or even acknowledge) bugs in Microsoft's code is silly[1]. [1] plenty of WoW players are also silly, and thus continued to blame Blizzard, as you are blaming GIMP now for bugs in GTK+. Yes, I am calling you silly. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP in-game feature
I believe that the GIMP logos are licensed under the GPL. If you wish to have them relicensed as CC then you could speak to the author of a particular logo. I am not sure about compatibility with the Free Art License. 2009/8/30 Eckhard M. b...@neeneenee.de: Please, can someone answer my request. Thanks. Am Samstag, den 29.08.2009, 19:59 +0200 schrieb Eckhard M. Jäger: Dear GIMP developers, i am a artist of the TORCS-NG racing game project. TORCS-NG is the active development fork of the famous open source 3D racing game TORCS. In the past the TORCS-NG team startet creating virtual brands for car- and track design. I proposed to feature open source projects we (the TORCS-NG team) love. We like to feature GIMP as a panel at the border of a track or a car skin too. So we like to get the permission to do so and we like to know what kind of license the GIMP logo has (the artwork must be distrubuted as CC/ Free Art License). We created a small gallery so you can imagine what TORCS-NG will be. Here you find examples of car skins: http://www.neeneenee.de/torcs-ng/gallery/ Best regards. Eckhard M. Jäger ___/\___ Plastiktütenpenner ist kein anerkannter Beruf. |\/\/\/| | |Bart. | (O)(O)b...@neeneenee.de C _) | ,_/ Linux for Designers - http://my.opera.com/area42/blog/ | / SweeTS delicious Typo3 development - http://typo3.area42.de/ / \ ___ 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 mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Remove zoom tool...
Pro tip... ctrl+mousewheel = zoom, regardless of which tool you are using. On Thu, Aug 6, 2009 at 10:01 PM, Luis Diego Alpizar Alpizardiego.1...@hotmail.com wrote: I wanted to ask if removing the zoom tool, from the toolbox to some new place(for the new UI) was something you devs plan to do, if you didn't hear this before, i find the zoom tool not usefull, as is better a single button(+,-) in some part of the GIMP window, because clicking 2 times in order to zoom in or out(and therefore, changing from zoom in to zoom out, would require a lot effort) for something that can be more easy to do, i find myself afected my workflow when i'm doing some photomanipulation. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] cant save image with new comment
On Tue, Aug 4, 2009 at 2:12 PM, Sven Neumanns...@gimp.org wrote: We are not talking about a save failure here. An image w/o changes does not need to be saved. So there is no failure here. I believe this has been thoroughly contradicted in this thread already. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] cant save image with new comment
On Mon, Aug 3, 2009 at 3:51 PM, Jay Smithj...@jaysmith.com wrote: On 08/03/2009 03:28 PM, Alexia Death wrote: Why only 5 seconds? why not until something else happens? IMHO 5 seconds is not enough. One of my annoyances with a couple of other programs that I use a lot is that such types of messages stay around too long in those programs. What if you look at the screen 30 seconds or 5 minutes or 2 hours later that message is still there? It is now completely out of context! I disagree. If the last thing I did that generates such a message was try to save, then even 2 hours from now it still has THAT context (that is, the last thing you did). Keeping the message in the status bar until it is replaced is, imho, the minimum possible solution to this problem. I, like some others in this thread, would prefer a modal dialog. On Mon, Aug 3, 2009 at 5:27 PM, Martin Nordholtsense...@gmail.com wrote: When you do a File - Save you want to make sure that your changes is safely written to disk, right? If you have made no changes, what is then the point in writing the file again? The user should be able to trust that GIMP does the right thing and it is unfortunate whenever GIMP doesn't. But showing a modal dialog whenever the user presses Ctrl+S twice is to me a really bad idea UI-wise. Maybe I just want to 'touch' the file and saving is the fastest possible way to do that. Perhaps I modified or deleted the file on disk, and want to save the copy that exists in GIMP over whatever is on the disk. I am not sure if GIMP is already aware of this situation In some situations, the Save operation produces dialogs from the export plugin, which do not affect the image in GIMP but do affect the saved image. What if I just want to change the decisions that I made there? (again, this may already be handled well). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On Sun, Jul 19, 2009 at 6:36 PM, Martin Nordholtsense...@gmail.com wrote: * Add larger variants of the circle and fuzzy circle brushes, say 50, 100, 250 and 500 px I really wish the brush system was improved to make this unneccessary. We should be able to smoothly scale vector-ish brushes (a circle is a pretty simple primitive) and avoid wasting so much space on duplicated brushes like this. Circle and Fuzzy Circle should be two brushes. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature Request: Layers from Image ( Linked Layers )
On Sat, Jun 13, 2009 at 9:32 PM, kevinfmw...@gmail.com wrote: The feature is mainly for the possibility of having templates. The idea is that you can place a layer that is a link to a certain image, so you can have 9 layers on top of each other and each one being an image. The idea is that you no longer have to Load image as layer every time you change an image because the layer would be the image and would update itself. My current workflow for this functionality is to edit my images in GIMP and maintain the Template in Inkscape. That sort of thing belongs in a vector editor anyway, imho, and it already does the link to image file thing that you are describing. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please, Please Bring Back Old GIMP.
I disagree with of course and naturally. When I close [child/sub] windows[/tabs] in most applications, then reopen the [functionally] same window, I expect it to come back in the same state it was in when I closed it. I regularly open and close the dockable windows, and add/remove things to them, and the amnesiac nature of all apsects of this process is very annoying. On Mon, May 25, 2009 at 8:06 PM, David Gowers 00a...@gmail.com wrote: Of course, if you close a dockable, you are saying 'throw away all information about this dockable', so in that case, naturally when you open a dockable of the same kind, it is simply put in a default position and size. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [wish] center on focused area on zoom out
The most natural-feeling zoom tools I have used do something similar to this. Instead of centering on the mouse cursor, they zoom such that the pixel under the mouse cursor does not move. This makes the zoom feel very smooth, imho. On Mon, May 18, 2009 at 2:46 PM, Kurt Pruenner l...@gmx.at wrote: Maybe it's just me, but I would expect the mousewheel zoom to center on the mouse cursor while hitting + and - on the keyboard should zoom from the center... ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [wish] when pasting without any reference use mouse cursor position
When you paste a second time, the first paste should still be visible and selected(?) and the floating selection is the current drawable, and thus the second paste end up on top of it (allowing for difference in paste sizes), right? Can you elaborate on the precise order of operations that results in the second paste ending up somewhere random? On Fri, May 15, 2009 at 3:16 PM, Maciej Pilichowski bluedz...@wp.pl wrote: On Friday 15 May 2009 20:40:21 Sven Neumann wrote: GIMP doesn't place the pasted content randomly. What makes you think so? Because I don't see any relevance in second paste to what I do (and where I do) and I see no relevance between first paste and the second one. And it should be. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
On Sun, Apr 26, 2009 at 8:01 AM, yahvuu yah...@gmail.com wrote: peter sikking schrieb: I like the innovative nature of the idea. And i'm not aware of a raster file format which features that concept. I just want to point out that PNG supports a background color (and the GIMP plugin to save PNG offers an option to save the current brush background color as the image background color), and being the only format to do so we should probably consider its specified functions and suggested behavior as potential starting points for GIMP's handling of such. 4.2.4.1. bKGD Background color The bKGD chunk specifies a default background color to present the image against. Note that viewers are not bound to honor this chunk; a viewer can choose to use a different background. For color type 3 (indexed color), the bKGD chunk contains: Palette index: 1 byte The value is the palette index of the color to be used as background. For color types 0 and 4 (grayscale, with or without alpha), bKGD contains: Gray: 2 bytes, range 0 .. (2^bitdepth)-1 (If the image bit depth is less than 16, the least significant bits are used and the others are 0.) The value is the gray level to be used as background. For color types 2 and 6 (truecolor, with or without alpha), bKGD contains: Red: 2 bytes, range 0 .. (2^bitdepth)-1 Green: 2 bytes, range 0 .. (2^bitdepth)-1 Blue: 2 bytes, range 0 .. (2^bitdepth)-1 (If the image bit depth is less than 16, the least significant bits are used and the others are 0.) This is the RGB color to be used as background. When present, the bKGD chunk must precede the first IDAT chunk, and must follow the PLTE chunk, if any. See Recommendations for Decoders: Background color. = 10.7. Background color The background color given by bKGD will typically be used to fill unused screen space around the image, as well as any transparent pixels within the image. (Thus, bKGD is valid and useful even when the image does not use transparency.) If no bKGD chunk is present, the viewer will need to make its own decision about a suitable background color. Viewers that have a specific background against which to present the image (such as Web browsers) should ignore the bKGD chunk, in effect overriding bKGD with their preferred background color or background image. The background color given by bKGD is not to be considered transparent, even if it happens to match the color given by tRNS (or, in the case of an indexed-color image, refers to a palette index that is marked as transparent by tRNS). Otherwise one would have to imagine something behind the background to composite against. The background color is either used as background or ignored; it is not an intermediate layer between the PNG image and some other background. Indeed, it will be common that bKGD and tRNS specify the same color, since then a decoder that does not implement transparency processing will give the intended display, at least when no partially-transparent pixels are present. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] shared layer mask or layer mask reference to previous
Isn't this a feature that is on the [unwritten] won't be implemented because it will Just Work if we ever get GEGL integrated with GIMP list? On 3/31/08, Miroslav Talasek [EMAIL PROTECTED] wrote: I and my many friends need this feature. We want that layer mask can be as reference to previous layer as photoshop. I have several layers but i wont olny one mask for some of layer. Simply shared layer mask as photoshop ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
