Re: [Gimp-developer] Why GIMP is Inadequate
Hello .. a word, if I may.. even if I'm not a gimp dev.. The fact that people don't understand what's happening in the project can only mean two things: 1. What's happening in the project is not communicated to users. That may be very well the case But Every day, I run into people who say why photoshop? There's GIMP, a perfect substitute.. On some forums at least. Often, these people never got their hands on a program which supports adjustment layers, 16-bit handling, LAB-handling and so on. And this hasn't to be photoshop in the first place, by the way. So GIMP is sufficient to them, which is perfectly fine! BUT I DO understand the other side if they complain that these people don't have a clue, but they misinterpret the statements of these GIMP-users that the devs themselves (you) think about GIMP as a perfect photoshop replacement.. which it isn't (and the devs don't think it is..). So to speak, this special breed of GIMP-evangelists ( or OpenSource-evangelists, which you can find on any Linux forum... they are often like XX is a PERFECT substitute for closed-source YY, and if it isn't, then you don't need it in the first place..) do more harm than good. As far as I've come to understand it, GIMP has the VISION to become a full fledged, free pixel-based graphics editor. No more, no less. It's an unhappy fact that we (.. I'm hobby photographer myself) are waiting for some features for many years.. But that's how it is.. and there's no alternative for *NIX systems I can think of, with Krita heading more in the drawing-direction or whatever you might call it... But with a whole lot of people just whining and not contributing nothing will get better.. 2. Some users don't care about what's communicated to them and stick to misconceptions they've grown to take for truth. This is true, too. As always But I won't put all of the arguments aside. Keep up your good work everybody don't get frustrated! Regards, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
Hello, just because I found a nice jargon entry, which supports my view, I relate to that old topic again. On Wed, Apr 21, 2010 at 12:33:15PM +0200, Oliver Bandel wrote: [...] I would do EVERY pointer set to NULL, when defining it. And normally I also would set ANY other value to a certain value, when defining it. This has helped me to track errors as early as possible. [...] To Heisenbug you find: In C, nine out of ten heisenbugs result from uninitialized auto variables, fandango on core phenomena (esp. lossage related to corruption of the malloc arena) or errors that smash the stack. http://www.jargon.net/jargonfile/h/heisenbug.html So, unininitialized auto variables is explicitly mentioned. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hello from an Inkscape filters developer !
On Sun, Nov 07, 2010 at 06:42:52PM +, Ivan Louette wrote: Just to say Hi and tell that I would be interested to discuss and contribute to the Gimp/Inkscape synchronization. [...] I'm not one of the Gimp-developers, even I looked a littlebid into the code. But I think this would be a good idea. I use inkscape not since long, but it has some nice features, which are not available in Gimp. On the other side for pixeil graphics, Gimp is more advanced, of course. Exporting from svg to bitmaps in inkscape could be enhanced. But also some of inkscape's vector features migth make sense to be integrated into Gimp. At least something like a common API that allows programmers to access both internal specific program APIs from the outside with one such interface/API for both, would be fine. So, if I have one API to load and change a picture through one of both programs (maybe implemented via plugins in Gimp and... inkscape... hmhhh does inkscape has a plugin-mechanism? not sure) transparently, this would be nice. ..just an idea. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hello from an Inkscape filters developer !
On Mon, Nov 08, 2010 at 02:21:06AM +0300, Alexandre Prokoudine wrote: On 11/7/10, Ivan Louette wrote: Just to say Hi and tell that I would be interested to discuss and contribute to the Gimp/Inkscape synchronization. I develop Inkscape SVG filters from the beginning of Inkscape 0.47 development cycle and I asked me for example if some exchanges between filters data could be possible between the two programs in the future, or if someone would be interested to discuss about what could be done in this area. Hi Ivan, The plan is to use GEGL for I/O in the future, and as far as I can tell GEGL already supports SVG and some SVG features like blending options (implemented as operations), see [...] Good to know. :) Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IMPORTANT: GIMP AND OPENSOURCE SCAM ON EBAY!
On Thu, Sep 23, 2010 at 01:27:41PM +0400, Alexandre Prokoudine wrote: On 9/23/10, Abir Sadik wrote: This is some really serious violation going on, and i hope someone will do something about it. In my experience there is nothing you can do about that, educating that kind of repackagers is just wasting your time. We in Audacity project tried dealing with this, got nowhere and simply ignore this. [...] Just sell Gimp for lower price including all sources, and the one will go away ;) Or isn't it posible to give a comment there on the seller? Just add Gimp-url there and people will avoid to buy it... Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] shorthanded and outnumbered (Re: Native RAW support)
On Mon, Sep 20, 2010 at 01:39:42PM +0400, Alexandre Prokoudine wrote: [...] The way things are going native RAW support in GIMP using GEGL + some can-opener library will likely require a dedicated developer in the team. Which the team doesn't seem to have right now, being heavily shorthanded and outnumbered. [...] A problem I talked about with people more than once. I for myself like writing code from scratch and find it very annoying and exerting to work with code I don't know. So what I often asked for is something like an overview on the Gimp-code. A documentation could help, but I personally would prefer workshops, where I can ask the more expereienced developers on who things are done. This saves a lot of time and can motivate people. Otherwise some developers that could help a lot would just do different things. I looked at Gimp's code, and it's much code. I don't know how other people see it, but such an intro-workshop would make sense to me. It's just a matter of effective work. Some things can be said in one or two sentences as answer for a question, or otherwise would take people weeks to get it from documentation (or even longer, if the docukmentation is spare or outdated). Different people, different working and learning styles. If thge core developers insiste that poeple who want to help has to have frustrating time consuming experiences with other people's code first, than no wonder development has slow progress. Some weeks ago I asked on irc for some help in gimp script programming. The answers I got were rather uninformed - from people who seem to be developers in Gimp. No useful answer, rather rhetoric questions instead of answers. I then got the answer from someone else, who has nothing to do with Gimp coe development, but did a lot Gimp scripting. For me this was again something like: even the core developers don't know Gimp, but someone else, who rather is artist and does some scripting for himself, knows the details. IMHO this comes from the behaviour that people just look at some code, start to hack and don't know the rest of the program. And I would guess, that's, because there is nobody who has an overview, or at least nobody who want's to provide that knowledge in a way that other people can jump in more easily - withgout just looking at some small portions of the code. The time that is needed to look into a big bunch of code could also, maybe more effectively be used to write something different from scratch. And that's maybe the reason, or at least one of the reasons, why there are not enough people that work in the Gimp core (shorthanded and outnumbered). Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] shorthanded and outnumbered (Re: Native RAW support)
On Mon, Sep 20, 2010 at 09:25:12AM -0300, Joao S. O. Bueno wrote: On Mon, Sep 20, 2010 at 7:38 AM, oli...@first.in-berlin.de wrote: On Mon, Sep 20, 2010 at 01:39:42PM +0400, Alexandre Prokoudine wrote: [...] The way things are going native RAW support in GIMP using GEGL + some can-opener library will likely require a dedicated developer in the team. Which the team doesn't seem to have right now, being heavily shorthanded and outnumbered. [...] Oliver - this rant has no reason to be. Sorry for that. It makes no sense to start working in a project the size of GIMP without having to learn the code already in there first. [...] I didn't say people should not look into the code. I meant: before looking into the code, an OVERVIEW on the code base would be helpful. Looking into the code without an overview yields to people with too narrow view on the code. Maybe that is good for other people, but not for me. I say it again: there are different styles of work. Is this is not addressed, then it makes no sense to mourn about shorthanded and outnumbered developers. If that situation should be changed, new developeers should be invited. And not everybody who could contribute will have enough time to read Megabytes of Code, just for fun. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] shorthanded and outnumbered (Re: Native RAW support)
On Mon, Sep 20, 2010 at 05:31:07PM +0100, Øyvind Kolås wrote: On Mon, Sep 20, 2010 at 2:10 PM, oli...@first.in-berlin.de wrote: Oliver - this rant has no reason to be. Sorry for that. It makes no sense to start working in a project the size of GIMP without having to learn the code already in there first. [...] I didn't say people should not look into the code. I meant: before looking into the code, an OVERVIEW on the code base would be helpful. Looking into the code without an overview yields to people with too narrow view on the code. Maybe that is good for other people, but not for me. I'll bite ツ There is various libraries that GIMP depends on: [...] I maintain two of these projects, babl and GEGL, the following links point to overviews of the directory structures used for their source codes: [...] Thanks. I already have decided to write some code on top of GEGL. If it progresses as I hope, this will be something that I will use instead of Gimp-scripting. Nevertheless a program wiuth GUI would be fine, so I hope Gimp will progress fast, if not with my help, then maybe without it. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Fwd: Drawing per Script
Hi, On Mon, Sep 13, 2010 at 05:21:09PM -0300, Joao S. O. Bueno wrote: On Sun, Sep 12, 2010 at 8:58 AM, oli...@first.in-berlin.de wrote: Hello, Hi I tried drawing per Script. I'm using Python. I can already use vectors for drawing circles, and set single points. I did not found a way to create rectangles, or lines. You are probablu using pdb_gimp_vectors_bezier_stroke_new_ellipse to draw circles, right? I use: pdb.gimp_vectors_bezier_stroke_new_ellipse So I think it's what you are talking about, just the absolute name is different. What does prevent you from using the calls for gimp_vectors_bezier_stroke_new_moveto and gimp_vectors_bezier_stroke_lineto to draw lines? I looked for draw and did not find functions that do it. So, in short words: I did not found thos functions. (Don't forget to alias then in your code to shorter names, last you have really undereadable stuff) If it does not eat up too much ressources in Python... ...you mean using def for creating a function that just calls the other one? or are aliases what Python offers as a separate feature? [...] Aren't there pdb-functions that draw a line? Do I have to create it pixelwise? In a loop? As I stated above, there are calls to draw lines. Are you even using the procedure browser? (Help menu - Procedure browser) - I use the procedure browser. But it does not help me, if I look for names that aren't there ...if I look for draw I got nothing. The circle-drawing function via bezier I found by accident/chance. In Python you can access the image data directly, using calls to get the pixel regions if you want to as well (that is about 100x faster than gimp_drawable_set_pixel due to the function calls involved for each pixel change) How can I access the pixel data directly? That would be very interesting to me, especially for some other scripts, where I think about even more intensive work. [...] So, besides my hints above: when I need speed on a PDB using script (which includes python scripts), I found out that GIMP's undo system is the cause for a significant slow down. Creating an Undo group does not help - you have to disbale the undo with pdb.gimp_image_undo_disable OK, I will try that. Thanks for all that hints. :) Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Drawing per Script
Hello, I tried drawing per Script. I'm using Python. I can already use vectors for drawing circles, and set single points. I did not found a way to create rectangles, or lines. Aren't there pdb-functions that draw a line? Do I have to create it pixelwise? In a loop? When using the circle drawing with vectors I would expect that this technique can do it's work fast. But it's very slow (using a loop to set paths in those vectors). (In OpenGL for example there are Vertex Arrays that can be used to speed up drawing. Something like that in GIMP, and available for scripting would be nice.) (I also saw, that what on the GUI are Paths internally are called vectors. To make things better undesrstandable, it would make sense to give things the same name... but maybe there is more to vectors and I don't see it so far. Why are there different names?) How can I speed up my drawings without switching to C? With my Python script I need about 3 or 4 seconds just for drawing 2072 circles. This seems very slow to me. If I also would need to write pixels of a line pixel-wise, I would also await to have very slow scripts. Special functions for drawing lines from within Python-plugins, that use C-speed would be fine. Gruß, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Newbie startup problems
Hi, On Thu, Aug 26, 2010 at 01:55:22PM +0530, Phani Bhushan Tholeti wrote: Hi, I am new to GIMP (its source, usage and features). I had joined this list with a view to contribute to GIMP. I did manage to get it to compile and run (though my code is old - about a month or two). Currently I am giving the manual a try (to get used to GIMP), but its HUGE and a lot of features for me to learn. :( or :) ? The wiki took me here: http://gimp-wiki.who.ee/index.php/Hacking:Source_Tree [...] Oh, an overview on the organization of the source tree! Thanks! I didn't knew that link. Thanks! Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] (no subject) plus dockables
On Thu, Aug 26, 2010 at 09:11:25PM +0200, g...@catking.net wrote: [...] Since the subject here is (no subject) I will add a related comments on some similar oddities in the menu system [...] Sorry, I was too tried, it was Re: [Gimp-developer] scanner support should be File-Acquire before; I made a typo in editing... with mutt I can use my editor to directly change the mailheader - and also do some nasty stuff. It should be in the same thread as the scanner support-thread. I want to comment on how hard/illogical it is to find the layers dockable dialogue without knowing what gimp calls it and knowing that dockable dialogues are found on the windows menu. There are many things like that. I'm not long enough on this list to know all the old discussions, but AFAIK Sven Neumann once (some years ago) was interviewed by the Cahos Radio, and mentioned there, that one person did a complete usability anylsis. I don't know idf this work has already been finished and published. Would be interesting to see at the recommendations. I mean: not necessarily adopt all such things (maybe thera ara also other concepts and ideas), but at least it could be something for a discussion. Thanks for your comments on GUI inconsitencies. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] drawing with even number of pixels
Hello, I could not find a way to convince a drawing-tool (pen or brush) to use even number of pixels. Scaling always yielded to odd number of pixels 1,3,5,... So I could not draw a line with two pixels width, which I would like to have. Will that be possible somehow? I see no reason, why the number of pixels must be odd. For me this looks as either buggy or a design flaw. Any ideas on that? (Or do I just have to convince Gimp somehow, and don't know the method?) Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Alignment-Tool Guides
On Sun, Aug 22, 2010 at 06:23:37PM -0700, Bill Skaggs wrote: [...] My recollection is that layer border are already magnetic, too. New feature? Since when? I have 2.6.7 here. Can it be disabled? Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Measurement-Tool cleared when taking Guides
Hello, when I use the measurement tool, and then try to pick a guide, the measurement tool is blown away from the screen. I can't see that this is a feature. If I measure one distance, I know it. The next step might be: measure the same distance somewhere else, and place a guide at the new point. How to circumvent this behaviour of clearing the measurement tool? Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scripting-Questions
Hi Jerry, thanks for your hints. Another question: I want to use gimp-file-load-layer and don't know how to access it. Any idea? Ciao, Oliver On Sat, Aug 21, 2010 at 06:23:04PM -0400, Jerry Baker wrote: Hi Oliver, 1) Insert a layer at lowest position... The image.add_layer method position argument is what you need to specify. 0 places a new layer at the top, 1 would be under the first layer, 2 under the second layer, etc... image.layers give you the list of layers in the image. Use len(image.layers) to place it at the bottom... Console example: # Get Active Image image = gimp.image_list()[0] # Create a new layer new_layer = gimp.Layer(image, My New Layer, image.width, image.height, RGBA_IMAGE,100, NORMAL_MODE) # Add Layer Lowest Position image.add_layer(new_layer, len(image.layers)) 2) Fit canvas to layers You'll want to use: gimp-image-resize-to-layers Console: image = gimp.image_list()[0] pdb.gimp_image_resize_to_layers(image) 3) The current documentation at http://www.gimp.org/docs/python/index.html and the pdb is about the best we gimp-python users have. There are a few sites out there with some posts, but everything is pretty dated. I'm currently picking away at a full tutorial and complete updated reference which I'll post here when I get it completed. I'm about 75% completed with it. On 08/21/2010 05:08 PM, oli...@first.in-berlin.de wrote: 1)image.add-layer: how can I insert at the lowest position? 2) how can I script Fit canvas to layers? 3) gimp.* / pdb.* and so on: which names using for Python, when looking at the procedure browser? For example: i could not find out, how to call gimp-file-load-layer I tried with gimp.* with pdb.* without that also The procedure browser seems to be good for scheme-users, but for Python this is just a hint, and needs permanently dabbling around. Where can I find better documentatoion for Python-scripting? Ciao, Oliver ___ 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] Alignment-Tool Guides
Hello, I just did some picture editing and thought that it would be good to have the possibility to allow guides and alignment tool to work together. For example it would be helpful to have the possibility of aligning guides to the center or border of a layer. Also nice would be to have the possibility to have layer borders to be magnetic (of course not as default), or something like Guides from Layer borders. What do you think? Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Another set of feature-wishes regarding Guides
On Sat, Aug 07, 2010 at 07:07:00PM +0200, Tobias Ellinghaus wrote: Am Samstag, 7. August 2010 schrub oli...@first.in-berlin.de: Hello, 1) it is possible to make guides invisible/visible and to make them magnetic/nonmagnetic. Both features are independent, which is good for some situations. To make them invisible as well as non-magnetic at the same time, two check boxes must be enabled/disabled. The possibility to make both with one click would be fine: visible magnetic / invisible non-magnetic. I don't have an installed GIMP around so I cannot test it: are invisible guides magnetic? If not then your request is void as making them invisible will also make them non-magnetic. If yes then that sounds (at least to me) like a bug/design flaw. [...] OK, today I'm in the Gimp-bugfile-contest... my second bug for today: https://bugzilla.gnome.org/show_bug.cgi?id=627588 ...maybe I will add moreif time allows. (I rather should edit my pics, but if that shows me more bugs...) Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Scripting-Questions
1) image.add-layer: how can I insert at the lowest position? 2) how can I script Fit canvas to layers? 3) gimp.* / pdb.* and so on: which names using for Python, when looking at the procedure browser? For example: i could not find out, how to call gimp-file-load-layer I tried with gimp.* with pdb.* without that also The procedure browser seems to be good for scheme-users, but for Python this is just a hint, and needs permanently dabbling around. Where can I find better documentatoion for Python-scripting? Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] small Wishlist regarding Guides
On Sun, Aug 01, 2010 at 06:42:00PM +0300, LightningIsMyName wrote: [...] - Adding Multiple Guides (there is a Script for this on www.meetthegimp.org, but native would be nice) This feature is good for some repetitive tasks, where a lot of Guides will be needed, something like a guide-grid. Can you give a direct link to the script? I definitely agree this sounds useful - it's worth checking if we can simply include this script with GIMP (or at least if you give us a link to it, we'll be able to write something similar with extra features if needed). [...] From this thread: http://forum.meetthegimp.org/index.php/topic,735.0.html There are Links to some versions of that script. Pick the last one. ;) Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rotational Motion Blur
On Wed, Aug 18, 2010 at 12:50:34PM +0200, g...@catking.net wrote: On 08/18/10 11:07, Tor Lillqvist wrote: A motion blur is a retinal effect that has a time dependence. Is motion blur actually something people perceive with their eyes and brain, or something that only exists in physical artefacts? (Either intentionally created by an artist to give the impression of motion, or as an direct result of the method the still or motion picture was created.) And we have been so used to it that we know what it means, even if it doesn't correspond to what we actually see? (But yeah, gg's arguments make sense.) --tml Good point, the equal weighting probably is close to what a silver nitrate film camera would record, which is probably what this was intended to model. [...] The human eye has sharpness only in the middle of sight. Things that move forward and can't be focussed, obviously willo be unsharp. and translation and rotation therefore will also give unsharpness in the human eye/brain. So this is not only what a camera would record. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Layer-Visibility in rotate tool: always 100%
Hello, in the rotate tool, when I make the visibility 100% this simply does not work. The layer that will be rotated is always 100% visibile. Will it be enough to mention it here (because of a possible quick fix)? Or should I file a bug-report (or maybe there already is one for that problem?)? It's Gimp 2.6.7. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer-Visibility in rotate tool: always 100%
...this is only in backward (correcting) mode. Maybe it's intended behaviour... ?! On Tue, Aug 17, 2010 at 09:37:34PM +0200, oli...@first.in-berlin.de wrote: Hello, in the rotate tool, when I make the visibility 100% this simply does not work. The layer that will be rotated is always 100% visibile. Will it be enough to mention it here (because of a possible quick fix)? Or should I file a bug-report (or maybe there already is one for that problem?)? It's Gimp 2.6.7. Ciao, Oliver ___ 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] Color Changing Features that I'm looking for...
Hello, sorry it is a german text, but looking at the pictures might say enough: http://eye.de/tip_labstaerken.shtml Theese feature of changing color tones is, what I'm looking for since a while. It's necessary to have Lab-mode, which seems to be nonsense to some developers, but the results show me: it makes sense to use that mode. Maybe not as underlying representation, but available to users it should be. Maybe a conversion filter that makes RGB-Lab and Lab-RGB, available for users (and their scripts) would be helpful. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Zoom tool kills other tools... hmhhhh
Hello, quite often I want to use the zoom tool and zoom into an area which I just have marked for cutting with the knife tool. But when using the zoom tool instead of the %-selections below the picture, the zoom tool deactivates the cutter. This might make sense in some situations, or even in a lot of situations... but when I just want to zoom into the part, where I think I could cut, this is not helping. It would be nice - maybe with a key pressed, when selecting the zoom tool - that it does NOT deactivate the cutter (or othe tools). For example a selection is not destroyed by the zoom tool. But the area that the cutter wants to cut - somehow - also is a selection. And this one IS destroyed. That's somehow not consistent, IMHO. What do you think? Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Paspertout for cutter - how dark can it become? (and size of selected area)
Hello, the paspertout-area for cutting... IMHO it would be fine to have adjustable brightness/darkness for those areas which would be cutted away. Sometimes the default is good. But sometimes I would like to have the selected-for-cutting area being completely darkened. Would that be possible? Ciao, Oliver P.S.: Would it even be possible to automatically (or by command) scale the selected area to become as big as the window alloes (fit window size)? This would also be very helpful for cutting photographs to the right size, and see, how it looks in the end. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Another set of feature-wishes regarding Guides
Hello, 1) it is possible to make guides invisible/visible and to make them magnetic/nonmagnetic. Both features are independent, which is good for some situations. To make them invisible as well as non-magnetic at the same time, two check boxes must be enabled/disabled. The possibility to make both with one click would be fine: visible magnetic / invisible non-magnetic. Also it would be fine to have keyboard-shortcuts for all those check-boxes. 2) an even more advaned usage of Guides would be, to have Guide-layers. One could disable guides on a guide-layer completely, when swictching off the eye for that layer, and enable them again like any other layer, when clicking on the corresponding layers-eye. With that feature one could do very complex graphics easily. Together with layer-groups, one could have layer-group specific guides, which will make it even more powerful. Guides that will not be part of a group would be acting globally, and guides that are part of a layer-group would be activated only together with that group. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Another set of feature-wishes regarding Guides
On Sat, Aug 07, 2010 at 07:07:00PM +0200, Tobias Ellinghaus wrote: Am Samstag, 7. August 2010 schrub oli...@first.in-berlin.de: Hello, 1) it is possible to make guides invisible/visible and to make them magnetic/nonmagnetic. Both features are independent, which is good for some situations. To make them invisible as well as non-magnetic at the same time, two check boxes must be enabled/disabled. The possibility to make both with one click would be fine: visible magnetic / invisible non-magnetic. I don't have an installed GIMP around so I cannot test it: are invisible guides magnetic? [...] Yes. And this can be very irritating/annoying. If not then your request is void as making them invisible will also make them non-magnetic. If yes then that sounds (at least to me) like a bug/design flaw. Aha :) Also it would be fine to have keyboard-shortcuts for all those check-boxes. It should be possible to assign them youself. [...] OK. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] small Wishlist regarding Guides
Hello, I have a small wishlist regarding Guides. - non-rectangle-bound guides: Guides that can be enabled to have any angle, which means that they do not have to be restricted to be 0 degrees or 90 degrees (being parallel to the window). This feature can be helpful, e.g. when correcting pictures, or for drawing parallels that do not fit the 0/90/180/270/360 degree orientation. It would be good, to enable/disable this behaviour via toggle box, so that normal behaviour will be available and guides can be restricted to classical window-parallel behaviour. - boundary guides, instead of middle.guides: Guides, where the outer boundary of a drawing tool snaps to the guide (instead the middle of the drawing tool snapping to the guide). This would be helpful for drawing in general, and correcting pictures: the color will not pass this line of the guide, which means, you can be sure no color enters a certain region. - Adding Multiple Guides (there is a Script for this on www.meetthegimp.org, but native would be nice) This feature is good for some repetitive tasks, where a lot of Guides will be needed, something like a guide-grid. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [oli...@first.in-berlin.de: Re: small Wishlist regarding Guides]
hello, this should have been sent to the list... so my answer forwarded to here. - Forwarded message from oli...@first.in-berlin.de - Date: Sun, 1 Aug 2010 23:40:45 +0200 From: oli...@first.in-berlin.de To: LightningIsMyName lightningismyn...@gmail.com Subject: Re: [Gimp-developer] small Wishlist regarding Guides User-Agent: Mutt/1.5.20 (2009-06-14) Hi, On Sun, Aug 01, 2010 at 06:42:00PM +0300, LightningIsMyName wrote: Hello - non-rectangle-bound guides: Guides that can be enabled to have any angle, which means that they do [...] I think we have seen this request already several times and I definitely agree it could be useful. Your request made me take a look at the code (app/display/gimpdisplayshell-draw.c, app/core/gimpimage-guides.c, /app/core/gimpguide.c) and it actually seems possible. I'll add it to my to-try list for when I have some more time. Fine :) [...] - boundary guides, instead of middle.guides: Guides, where the outer boundary of a drawing tool snaps to the guide (instead the middle of the drawing tool snapping to the guide). This would be helpful for drawing in general, and correcting pictures: the color will not pass this line of the guide, which means, you can be sure no color enters a certain region. This does not seem trivial to code - in fact with how I remember the paint core works, this is going to be one very hard hack... Also, I think that if the purpose is just to stay inside of the lines you can use a selection (create it using the guides and freeform [...] The selection does not has the magnetic behaviour as a guide has. Maybe even a freely definable guide would help here, or a magnetic selection, or something like this ?! [...] - Adding Multiple Guides (there is a Script for this on www.meetthegimp.org, but native would be nice) This feature is good for some repetitive tasks, where a lot of Guides will be needed, something like a guide-grid. Can you give a direct link to the script? I didn't found the link by myself, but I have the script local on my machine and can attach it. It's not writen by me. But I may look for the original link later (or ask the admin). I definitely agree this sounds useful - it's worth checking if we can simply include this script with GIMP The GUI/behaviour could be enhanced, and could be more Gimp-like. But it's already useful and has saved me a lot of time in some tasks. (or at least if you give us a link to it, we'll be able to write something similar with extra features if needed). I will attach it here. I hope attachements are not blocked here. Ciao, Oliver import os from gimpfu import * import os.path import pygtk import gtk gettext.install(gimp20-python, gimp.locale_directory, unicode=True) def debugMessage(Message): dialog = gtk.MessageDialog(None, 0, gtk.MESSAGE_INFO, gtk.BUTTONS_OK, Message) dialog.run() dialog.hide() def findMaxDimensionOfImage(Image, Direction): if (Direction == 0): limit_value = pdb.gimp_image_height(Image) -1 else: limit_value = pdb.gimp_image_width(Image) -1 return limit_value # This defines the class class addMultipleGuidesDialog: # Things to do with the image reference imageRef = 0 def set_imageRef(self,Image): self.imageRef = Image def get_imageRef(self): return self.imageRef # Things to do with the guides we create thisGuide = 0 def set_thisGuide(self, guideRef): self.thisGuide = guideRef def get_thisGuide(self): return self.thisGuide # RadioGroup radio_group = [] def set_radioGroup(self, radioGroup): self.radio_group = radioGroup def get_radioGroup(self): return self.radio_group # Adjustment the_adjustment = 0 def set_adjustment(self, newAdjustment): self.the_adjustment = newAdjustment; def get_adjustment(self): return self.the_adjustment # Labels (possible to change later for translation purposes) Labels = [Horizontal, Vertical, Add, Close, Remove Last] #Labels = [H, V, A, C] def get_Labels(self, labelIndex): return self.Labels[labelIndex] # This is a callback function. The data arguments are ignored # in this example. More on callbacks below. def hello(self, widget, data=None): print Finished def findActiveRadioButton(self): active = [r for r in self.get_radioGroup() if r.get_active()][0] return active.get_label() # call back for the Add button def add_guide(self, widget, Data): activeLabel = self.findActiveRadioButton() position = Data.get_value() if (activeLabel == self.get_Labels(0)): currentGuide = pdb.gimp_image_add_hguide(self.get_imageRef(), position) else: currentGuide = pdb.gimp_image_add_vguide(self.get_imageRef(), position) self.set_thisGuide(currentGuide
[Gimp-developer] Rotation-Tool: center point and grid
Hello, when using the rotate tool, I can enable a grid that is shown. I also can move the center point. What I want to have, is, that the center point's center also is at one crossover of grid lines. Where (which file) can I change that? Would that also be a feature that would be picked up into the regular source tree? I would like to have such a feature inside my regularly installed gimp. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] No more automatic file-type detection im GIMP 2.7?
Hello, For some days, the automatic file type detection in the image-open dialog of my daily-build GIMP 2.7 (git version) doesn't work anymore... GIMP wants to load the UFraw plugin instead (which I don't have installed for GIMP 2.7 as far as I remember.. so it stops with an error message just stating that UFraw is missing.) Opening works well selecting the file type manually (tiff, jpg..) though... Any ideas? Is it just me or a problem of GIMP 2.7 at the moment? Thanks in advance, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How to create a new tool?
Hi, On Mon, Jun 14, 2010 at 11:39:27AM +0800, Bear wrote: hi, I am a newbie on GIMP development. Now I wanna create a new tool. For example, I wanna create a Text Tool which as same as GIMP owned. I copyed these files: [...] Ah, what a good idea... instead of changing the tools that are there, just making your own ones (and starting with CopyPaste). Ah, fine this way I may also add some stuff... and will not need to argue why older stuff needs to be changed. It doesn't need to be changed. The old stuff can be there, and new stuff *might* be added later (or not mentioned at all). Good inspiration, thanks! Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] who is interesting in writing java api to gimp
Hi, On Sun, May 09, 2010 at 09:35:53AM +0800, Hades wrote: thanks for your help,but I still want to know why few people like to do some api in java. [...] Maybe, because Java is crap. I also think about providing a foreign language interface to Gimp, but would use OCaml. But maybe an OCaml binding to GEGL would also make sense. I'm just very new to Gimp, and I'm not experienced with the huge code base I just do some hacking in my local repository, but so far did just some simple changes but did not start adding another language-interface to Gimp; just thought about it (like you also do). Maybe I will not even start it. (There is other stuff I'm working on also.) Gimp is written in C, and uses some libraries that also provide OO-functionality. There is glib and gtk+; and for the graphical processing gegl will be used more and more. I doubt that Java will provide things that are new (because OO is already in use inside of gimp, as just mentioned) and needed. I have seen some Java projects, and it always was a mess to handle it. The reason to use Java is often said: compatibility. But I have seen problems in this respect many years ago; Java-people told me, things were better now; and just some months ago I saw the same problems again. So, the main reason does not hold. because the pure java code to do the graphics manipulation is a saddly things,even including the sun's JAI. So, you say, that it's not good. But why adding a Java-API then? OCaml would make sense to me, because it would add functional programming and a strong and rigid type system things, that Python not brings in. With Ptython it's sometimes a mess, because it's type coercion is very close to that of Perl and Tcl. But at the moment I think, instead of adding such a new language interface, it would make even more sense to make a rewrite from scratch with another language. ( But I would not await for people to enter this. ;) ) This might also make sense for your Java idea. ;) I heard Java is good for GUI-programming. So you might start a Gimp-clone ;) But when it uses gtk also, then you just use a different language for the same GUI library would this make sense? With Java not, I would guess... And: be aware, that the Gimp code base is very huge. So, I'm not sure I would start such a thing. But you seem to be very motivated... At the moment I'm working on other stuff, and just looking what the experienced Gimp developers do. AFAIK there are massive changes planned in the code base... ...and so, if you add your stuff now, you might have to meet a moving target...?! (Not sure how long the API will be stable, hopefully it will be stable for a longer time.) The fine with using git is, that one can add his own changes and nevertheless can slurp in the new code from the main developers. (with rebase-ing) So you also could start your Java-stuff, if you want, and maybe one day, when it's good, and would convince people that it is necessary and cool, they might be interested in importing it. But I doubt that this will be the case. Nevertheless, you could develop your code locally, and when it's ready to use, then just upload your code to a server and maybe people would like to try it, even if it is not official part of Gimp. (if nobody is interested, at least you can use it for yourself.) I started learning git, to be able to manage the Gimp code, to jump into the Gimp-development; and I saw, that this tool is really helpful... it's the ultimative tool for handling code in such big projects. If you already know how to use it, you could start with codding right now (otherwise: learn git, it's cool.) So we may see your code online in a year or so? ;) Even I dislike Java, I mean, you could just start it. Some people might enter to help you. The ImageMagick and GIMP is good enought ,not like toy.But the ImageMagick cann't do much psd file perform. [...] I thought psd-format is also not completely supported in Gimp. ...and: would you write a Java language interface for gimp, just to use the psd-import from Gimp? Couldn't this be done easier otherwise? Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] I hava a dream:if GIMP can do WebService
On Sun, May 09, 2010 at 10:30:04AM +0200, Michael Schumacher wrote: On 09.05.2010 03:56, Hades wrote: If GIMP can do WebService , It is a rather simple task to get the basic GIMP functionality - i.e. everything the gimp class offers - to work with Python's SimpleXMLRPCServer. [...] Oh, this is interesting. Good hint, thanks. See http://registry.gimp.org/node/10 for a very basic example. In order to become useful, many convenience functions will have to be added. [...] OK. I don't need Gimp for a Web-Service, but in this way, maybe one could do a different kind of Gimp-Scripting... :) Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] who is interesting in writing java api to gimp
On Sun, May 09, 2010 at 06:11:43PM +0200, oli...@first.in-berlin.de wrote: [...] With Ptython it's sometimes a mess, because it's type coercion is very close to that of Perl and Tcl. [...] OK, maybe it's a littlebid exaggerated, heheh ;) And Python is comparingly clean, compared to Perl. So, I mean, it's good to have it available in Gimp. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
Zitat von Sven Neumann s...@gimp.org: On Wed, 2010-04-21 at 18:30 +0200, Martin Nordholts wrote: On 04/21/2010 01:58 PM, Oliver Bandel wrote: Even only temporarily valies, if set to a certain value, like 0 or NULL, will help in finding problems. I agree, and I try to initialize all local variables that I either add or modify the declaration of. I don't think it would be worth to commit a patch that initializes all variables though because it would break git blame. I don't think the git history of a file is a reason that should keep anyone from committing code cleanups. Oh, yes. I see it the same way. The question is rather if this particular cleanup is worth the hassle and if it would really result in an improvement when it comes to readability and maintainability of the code-base. The answer from my experience is: it absolutely is worth it. And I doubt that the code will ne that much more unreadable. In situations where it bloats up the code, I would guess it reasons that should better end in refactoring the code. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
Hi Frederik, my main attend was to mention the problem of pointers, regarding uninitialized values. That's why I insisted on Null, and it makes sense often to use 0 or 0.0 for other values. As strings are char*, NULL should be used, not . You are right, that in some seldom situations it might make sense to initialize values to other start values. But they should always be predictable. If for example 0 is part of the used range of values and you have -1 not in that range, -1 might make sense. For example filedescriptor-stuff in Unix-system-near applications might start with fd = -1 and if something goes wrong or you acidently removed your initializing funtion, the -1 will show you a problem. Other values for example might be: INT_MAX or INT_MIN. What is the special on all those values? The special thing is, that they are EXCEPTIONS to what is normal. Other languages have exceptions built in, and you can catch them. The same is here: a NULL-pointer is an exception. And it's the only exception that you have for your pointers, that is working all the time.If you may have a set of function pointers, which only can be valid, you also can test against them. But even in that case, NULL would be an exception too. For int values enums are often a good idea, or language / system constants. So, all in all: the most interesting values for initilazisation at definition are those values, that should never occur. Only against them you can test. glib provide those tests for incoming parameters; but if the caller has forgotten initialization, your test gives you wrong feeling of security. And if you in your function miss the init to real values, at least the EXCEPTIONAL init, right at the beginning of your function will the called functions - if thex test their arguments - fail. So, to set the tests into a working mode, you must provide it values, that it can detect. So much for now. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
Zitat von Sven Neumann s...@gimp.org: Hi, On Thu, 2010-04-22 at 14:38 +0200, Fredrik Alströmer wrote: For the record, I'm not necessarily against setting a predefined value to variables sometimes. I'm just against doing it for the wrong reasons, and I'd much rather have the compiler say Warning: might be used uninitialized in this context as a part of the static analysis, rather than chase down the bug where a value is 0 at run time (remember, I'm primarily talking corner cases here). Totally agreed. I also prefer the compiler telling me that a refactoring I've just done is not correct because I forgot to initialize a variable in a code path. This has happened to me and the compiler warning caught some potential bugs. If we would always initialize all variables this mistake would have gone unnoticed. [...] If this case would be undetected by the compiler, but you have initialized it to your EXCEPTIONAL value at the same line, at which the variable is defined, then - when running the code, it would have shown you your problem. Will the compiler stop execution on any warning? It should, and not compile any code that gives warnings, otherwise your attempt will not work. People will ignore it just for testing. And that's the beginning of the problems ;-) The other case is: values change during the meantime. If you reset them to the exceptional values after usage, especially I mean pointers here, that's a good idea. And in those cases the compiler would not show you a warning on non-initialized values, but the tests on validity will work. BTW: just some days ago I saw a bug fix in glib. In this fix, after freeing some memory, the pointer was set to null. I was happy to see this. :) Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
Zitat von Tor Lillqvist t...@iki.fi: You are right, that in some seldom situations it might make sense to initialize values to other start values. But they should always be predictable. You didn't get the reasoning about letting the compiler, or valgrind, catch use of uninitialized variables, did you? I got it. But the compiler throws a warning and not an error on it. So, it's possible to get running code. The same is here: a NULL-pointer is an exception. Only if you try to dereference it. No, I mean exception in a different way. It's an exception even if you don't dereference it, because it will be one, if you dereference it. Dereferencing a pointer that is not NULL, but contains nonsense, not necessarily pops up as a problem. But it will be a problem, when the code is in usage, that is: at the customer or, neing more general: at the user. Murphy's Law. :) There are some standard C library functions, and many GTK+ stack functions, where passing a NULL pointer for a parameter is a documented fully normal way to specify some semantic variation of its API. And the way it is handled is, to check against NULL, because NULL is special. And it's the only exception that you have for your pointers, Well, as such some API could very well define some well-known special (exceptional) pointer values and give them semantic meaning by themselves (i.e. the contents of what they point to would be irrelevant). That doesn't happen often, but it would be perfectly normal C. I mean something like: typedef struct FooBarStruct *FooBar; extern const FooBar FooBarMUMBLE; extern const FooBar FooBarPLUGH; Yes, I like this idea. it's not used often. But it just adds more exceptional values to NULL. And you only can detect them as exceptional, if you know that definitions. If you cast them to something else, you have problems to detect them. But NULL is given from the language as really special value. (And normally should be (void*) 0.). The above idea is nice, and adds more of exceptional values, but not as distinctionable as NULL. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
Zitat von Torsten Neuer tne...@inwise.de: Am Freitag, 23. April 2010 08:39:52 schrieb Oliver Bandel: Zitat von Sven Neumann s...@gimp.org: Hi, On Thu, 2010-04-22 at 14:38 +0200, Fredrik Alströmer wrote: For the record, I'm not necessarily against setting a predefined value to variables sometimes. I'm just against doing it for the wrong reasons, and I'd much rather have the compiler say Warning: might be used uninitialized in this context as a part of the static analysis, rather than chase down the bug where a value is 0 at run time (remember, I'm primarily talking corner cases here). Totally agreed. I also prefer the compiler telling me that a refactoring I've just done is not correct because I forgot to initialize a variable in a code path. This has happened to me and the compiler warning caught some potential bugs. If we would always initialize all variables this mistake would have gone unnoticed. [...] If this case would be undetected by the compiler, but you have initialized it to your EXCEPTIONAL value at the same line, at which the variable is defined, then - when running the code, it would have shown you your problem. You are comparing a bug turning up when actually running the code vs. turning up when compiling it. I prefer to find and fix it *before* the code gets executed. I do prefer this too. Whenever a compiler is able to tell about a possible bug development is quickened. Which is one of the reasons some languages have explicitly been designed to allow for good static code evaluation. Yes. [...] Ignoring warnings just for testing is bad style and contra-productive. Any serious programmer doing that should be slapped with a wet trout. I have seen this all to often at work. It's just a warning... The other case is: values change during the meantime. If you reset them to the exceptional values after usage, especially I mean pointers here, that's a good idea. Agreed with that. But then again, optimally these pointers themselves should not exist any more (which means you can't dereference them). What you seem to be talking about here is the use of global variables that get re-used over and over. Resetting those to sane values is absolutely a must, but one should avoid the use of global variables whereever possible in the first case. Let it be a field in a structure that will be used even after the free. And if normally after the free that pointer will not be used... be sure, one day it will be re-used, and the NULL-check then fails. :) That's going to be fun. :) In case of library functions dealing with pointers, on the other hand, one cannot be sure whether the pointer itself is destroyed after the memory is freed. So setting the pointer to a sane value is a must and cannot be avoided. OK, so I see you agree. Many people are maybe not aware of that problem, I would think. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
Zitat von Tor Lillqvist t...@iki.fi: You are right, that in some seldom situations it might make sense to initialize values to other start values. But they should always be predictable. You didn't get the reasoning about letting the compiler, or valgrind, catch use of uninitialized variables, did you? [...] Let's just take an example that makes it more clear. See attachement ( I hope the list allows attachements ). I get two results: with char* mytext = NULL; = oli...@siouxsie:~$ a.out selected number: 0 Text: ATTENTION! No text selected. Fix Bug, please! selected number: 1 Text: two selected number: 2 Aborted oli...@siouxsie:~$ = Instead ov abort() I could select whatever I want. I, as programmer, have control about it. With char* mytext; I get = oli...@siouxsie:~$ a.out selected number: 0 Text: ATTENTION! No text selected. Fix Bug, please! selected number: 1 Text: two selected number: 2 Text: two selected number: 3 Segmentation fault oli...@siouxsie:~$ = In this case I have no control. Compiling with -Wall: = oli...@siouxsie:~$ vim checks.c oli...@siouxsie:~$ gcc -g -Wall checks.c oli...@siouxsie:~$ a.out (...) = Using valgrind: In case of char* mytext = NULL; = oli...@siouxsie:~$ vim checks.c oli...@siouxsie:~$ gcc -Wall checks.c oli...@siouxsie:~$ valgrind a.out ==29758== Memcheck, a memory error detector ==29758== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==29758== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info ==29758== Command: a.out ==29758== selected number: 0 Text: ATTENTION! No text selected. Fix Bug, please! selected number: 1 Text: two selected number: 2 ==29758== ==29758== HEAP SUMMARY: ==29758== in use at exit: 4 bytes in 1 blocks ==29758== total heap usage: 1 allocs, 0 frees, 4 bytes allocated ==29758== ==29758== LEAK SUMMARY: ==29758==definitely lost: 4 bytes in 1 blocks ==29758==indirectly lost: 0 bytes in 0 blocks ==29758== possibly lost: 0 bytes in 0 blocks ==29758==still reachable: 0 bytes in 0 blocks ==29758== suppressed: 0 bytes in 0 blocks ==29758== Rerun with --leak-check=full to see details of leaked memory ==29758== ==29758== For counts of detected and suppressed errors, rerun with: -v ==29758== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) Aborted oli...@siouxsie:~$ = In Case of char* mytext; = oli...@siouxsie:~$ vim checks.c oli...@siouxsie:~$ gcc -Wall checks.c oli...@siouxsie:~$ valgrind a.out ==29795== Memcheck, a memory error detector ==29795== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==29795== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info ==29795== Command: a.out ==29795== selected number: 0 Text: ATTENTION! No text selected. Fix Bug, please! selected number: 1 Text: two selected number: 2 ==29795== Conditional jump or move depends on uninitialised value(s) ==29795==at 0x4005C5: print_text_checks_null (in /home/oliver/a.out) ==29795==by 0x400692: print_all_messages (in /home/oliver/a.out) ==29795==by 0x4006CD: main (in /home/oliver/a.out) ==29795== ==29795== Conditional jump or move depends on uninitialised value(s) ==29795==at 0x4E6FA50: vfprintf (vfprintf.c:1601) ==29795==by 0x4E79BE9: printf (printf.c:35) ==29795==by 0x4005DF: print_text_checks_null (in /home/oliver/a.out) ==29795==by 0x400692: print_all_messages (in /home/oliver/a.out) ==29795==by 0x4006CD: main (in /home/oliver/a.out) ==29795== ==29795== Use of uninitialised value of size 8 ==29795==at 0x4E72A87: vfprintf (vfprintf.c:1601) ==29795==by 0x4E79BE9: printf (printf.c:35) ==29795==by 0x4005DF: print_text_checks_null (in /home/oliver/a.out) ==29795==by 0x400692: print_all_messages (in /home/oliver/a.out) ==29795==by 0x4006CD: main (in /home/oliver/a.out) ==29795== ==29795== Conditional jump or move depends on uninitialised value(s) ==29795==at 0x4E9B6ED: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1314) ==29795==by 0x4E72711: vfprintf (vfprintf.c:1601) ==29795==by 0x4E79BE9: printf (printf.c:35) ==29795==by 0x4005DF: print_text_checks_null (in /home/oliver/a.out) ==29795==by 0x400692: print_all_messages (in /home/oliver/a.out) ==29795==by 0x4006CD: main (in /home/oliver/a.out) ==29795== ==29795== Use of uninitialised value of size 8 ==29795==at 0x4E9B6F3: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1316) ==29795==by 0x4E72711: vfprintf (vfprintf.c:1601) ==29795==by 0x4E79BE9: printf (printf.c:35) ==29795==by 0x4005DF: print_text_checks_null (in /home/oliver/a.out) ==29795==by 0x400692: print_all_messages (in /home/oliver/a.out) ==29795==by 0x4006CD: main (in /home/oliver/a.out) ==29795
Re: [Gimp-developer] Testing on NULL an unitialized values
hehe, the segfault did not came from the char* mytext, but from wrong indexing in the vector. :( my fault :( Heheh... nevertheless valgrind is on my side ;-) Somehow I got no crash from the uninitialized char*, but that might only happen after release at the user's computer: It's unpredictable. maybe there was a \0 at that address. The main thing I wanted to show: how to track such variables? The compilers and help tools do not always help. If this were more than just showing that problem, I now should clean up my code... to one day also enter the realm of clean programming ;-) Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
it's better not to initialize local variables. The compiler is actually smart enough to give you a warning might be used uninitialized, always initializing to something will hide that warning. And you'll use your uninitialized value (which will always be zero, or whatever) unaware of that it's not sensibly initialized. You don't need that warning anymore. They were invented for languages that allow undefined values, and prohgrammers that leave them undefined (mostly by accident). You definitley know that there is one certain start value. But which value is it have? Is it always the same? And the same on all computers. Ciao, Oliver P.S.: For example it's also good after freeing memory, to set the pointer to NULL. Some people say: not necessary. But it has helped me finding bugs. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Success-return-value
Hello, is there a convention for return values in Gimp, which says: on success return TRUE or a value, and on fauilure FALSE or NULL? Or can it be different at different sources, rather be a taste of the one who developped something? Ciao, oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Testing on NULL an unitialized values
Hello,
since some days I'm browsing through the Gimp-Code.
What I have seen so far looks very tidy.
But I also found some things that I would do differently, throughout
the whole code, and maybe also in the libs (I didn't looked at them in
detail).
I would do EVERY pointer set to NULL, when defining it.
And normally I also would set ANY other value to a certain value,
when defining it.
This has helped me to track errors as early as possible.
Example:
==
/*/
/* public functions
/
GimpContext *
gimp_context_new (Gimp*gimp,
const gchar *name,
GimpContext *template)
{
GimpContext *context;
g_return_val_if_fail (GIMP_IS_GIMP (gimp), NULL);
g_return_val_if_fail (name != NULL, NULL);
g_return_val_if_fail (! template || GIMP_IS_CONTEXT (template), NULL);
context = g_object_new (GIMP_TYPE_CONTEXT,
name, name,
gimp, gimp,
NULL);
if (template)
{
context-defined_props = template-defined_props;
gimp_context_copy_properties (template, context,
GIMP_CONTEXT_ALL_PROPS_MASK);
}
return context;
}
==
The test
if( template )
makes only sense, if you can be sure that uninitialzed values
will definitelky be NULL.
If you are not sure that uninitialized values will be NULL,
then the test
if( template )
makes no sense.
So:
- either consequently setting all pointers to NULL,
even you are intended to just right after this will set it
to another value; if you forget this, then you at least has
your NULL in the pointer.
- or: you can completely avoid such tests as the above mentioned one,
because you are sure that you alkready have initialized values.
The former decision is the one that leads to easy maintainable code.
The later decision is, what I would call going to become crap.
It's a lot of work, looking for such stuff in all files.
But I would say, it will definitely help in tracking down errors
early.
I can say this from many years of C programming.
Any comments welcome.
Ciao,
Oliver
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
Zitat von Tor Lillqvist t...@iki.fi: The test if( template ) makes only sense, if you can be sure that uninitialzed values will definitelky be NULL. You must have missed the g_return_val_if_fail (! template || GIMP_IS_CONTEXT (template), NULL) . It checks if template is NULL or a pointer to a valid GimpContext. If template is some random non-NULL value, the test will fail and a warning message will be printed. Such warning messages indicate a programmer error and should be dealt with during development. [...] Nice to know, but I was talking on things like the *context in that funcion. Even only temporarily valies, if set to a certain value, like 0 or NULL, will help in finding problems. The mentioned function just was an example. Uninitialzed values I see nearly everywhere in the code. Dereferencing NULL is easy to find, because it crashes early. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
Zitat von Sven Neumann s...@gimp.org:
On Wed, 2010-04-21 at 12:33 +0200, Oliver Bandel wrote:
Example:
==
/*/
/* public functions
/
GimpContext *
gimp_context_new (Gimp*gimp,
const gchar *name,
GimpContext *template)
{
GimpContext *context;
g_return_val_if_fail (GIMP_IS_GIMP (gimp), NULL);
g_return_val_if_fail (name != NULL, NULL);
g_return_val_if_fail (! template || GIMP_IS_CONTEXT (template), NULL);
context = g_object_new (GIMP_TYPE_CONTEXT,
name, name,
gimp, gimp,
NULL);
if (template)
{
context-defined_props = template-defined_props;
gimp_context_copy_properties (template, context,
GIMP_CONTEXT_ALL_PROPS_MASK);
}
return context;
}
==
The test
if( template )
makes only sense, if you can be sure that uninitialzed values
will definitely be NULL.
template isn't uninitialized here. It is a parameter passed to
gimp_context_new() and it may either be NULL or a pointer to a valid
GimpContext object. This is even checked right at the beginning of the
function.
Yes, you are right.
But context is not initialized at definition.
It get's it's value later on.
When changing code, forgetting to set a value later might bring problems.
GimpContext *context = NULL;
Right after beginning of the function is, what I mean.
In this small function one can oversee what's going on.
In larger functions it's not always obviously, and such
semmeingly non-necessities can help in shrinking down debugging
time from weeks to minutes, especially in big projects.
I prefer programming in paranoid mode ;-)
It helps, if the coffee is empty with early core dumps... ;-)
When I see the huge database and complexity of gimp, I prefer such
a way even more. :)
When I look at scheme.c, it has some thousands lines and some
functions are many screens long... DEK would say: a function should
not be larger than one page or screen size I agree in that point.
Ciao,
Oliver
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
Hi, Zitat von Omari Stephens x...@csail.mit.edu: On 04/21/2010 11:58 AM, Oliver Bandel wrote: Zitat von Tor Lillqvistt...@iki.fi: [...] Even only temporarily valies, if set to a certain value, like 0 or NULL, will help in finding problems. The mentioned function just was an example. Uninitialzed values I see nearly everywhere in the code. Dereferencing NULL is easy to find, because it crashes early. Hi, Oliver Have you programmed with glib before? [...] No, I'm new to glib. I had it in mind since a while, because it also provides different kind's of trees. But only now I have real contact to it. A lot of defensive programming techniques differ between straight C and C-with-glib. For instance, the guards at the top are common, and (I imagine) gimp_context_copy_properties has similar guards. As such, it's the job of the called function, not the caller, to check if a pointer they want to dereference is NULL. Of course the called function has to test it on NULL/non-NULL. But the function that creates a pointer does it's job best, if it starts with a NULL right at the time of the definition. My rule of thumb, which has helped me a lot is: ALWAYS INITIALIZE, even if some lines later you assign a value. But if you forget this part, or change code and the assignment is lost by accident, then there is a pointer that is NOT NULL. Result: your tests on NULL fails! So: all your gurading is disabled, if there is an unitialized pointer. This has the advantage that you don't check a pointer for NULL 10 times across 10 different function calls when you only use it once, all the way at the bottom. I prefer checking it ten times to checking it 0 times ;-) Of course, if you actually dereference a value (like the template pointer in the snippet you posted), you should test it before you dereference it. The test against NULL will fail, if you forgot to assign a value. If the value is assigned at definition (NULL for a pointer), this makes the checks working always. Maybe I had it not very good explained in my first mail, what I mean. So, I hope I have clarified it. In short, you might want to see what sort of defensive techniques are customary or appropriate for a given context before concluding that we're programming blind. I didn't say blind programming. But maybe also switching the light on is a god idea. ;-) Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
Zitat von Martin Nordholts ense...@gmail.com: On 04/21/2010 01:58 PM, Oliver Bandel wrote: Even only temporarily valies, if set to a certain value, like 0 or NULL, will help in finding problems. I agree, and I try to initialize all local variables that I either add or modify the declaration of. I don't think it would be worth to commit a patch that initializes all variables though Hmhhh... ...but the next time when you work on a function, you could just do that part too? I really have thought about a patch that i sintended just to do only that: adding the initializations. because it would break git blame. git blame? Can you explain me that? Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
Zitat von Sven Neumann s...@gimp.org:
On Wed, 2010-04-21 at 12:33 +0200, Oliver Bandel wrote:
Example:
==
/*/
/* public functions
/
GimpContext *
gimp_context_new (Gimp*gimp,
const gchar *name,
GimpContext *template)
{
GimpContext *context;
g_return_val_if_fail (GIMP_IS_GIMP (gimp), NULL);
g_return_val_if_fail (name != NULL, NULL);
g_return_val_if_fail (! template || GIMP_IS_CONTEXT (template), NULL);
context = g_object_new (GIMP_TYPE_CONTEXT,
name, name,
gimp, gimp,
NULL);
if (template)
{
context-defined_props = template-defined_props;
gimp_context_copy_properties (template, context,
GIMP_CONTEXT_ALL_PROPS_MASK);
}
return context;
}
==
The test
if( template )
makes only sense, if you can be sure that uninitialzed values
will definitely be NULL.
template isn't uninitialized here.
[...]
To explain, what I meant:
The function, that calls gimp_context_new()
gives template to gimp_context_new().
If THE CALLING function - for some reason - gives a non-NULL but
non valid pointer to gimp_context_new(), shit happens.
Ciao,
Oliver
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New on this list... how to start juming into Gimp-dvelopment?
Hi, Zitat von Simon Budig si...@budig.de: Oliver Bandel (oli...@first.in-berlin.de) wrote: I'm new on the developer list. Welcome. I would like to help in pushing into the direction of overcoming the 8-Bit limitation. Also interesting would be for me to have more knowledge on the plugin-stuff; I had already written some little Python-plugins, but to know more about that would be fine I also think about implementing a foreign language interface for OCaml. For the 8-bit limitation the important keyword is GEGL, which is the project we want to base on for higher bit depths. Pippin is the person in the know there. [...] Where is the main problem? Is the problem to import GEGL into Gimp, or is GEGL not advanced enough to use it in Gimp at the moment? So: is the work to be done at the Gimp-side or at the GEGL-side? At the moment I'm using Ubuntu and used the apt-get source gimp to download the sources of the current Gimp on my distribution. I looked for the necessary tools, which were not all installed. So then I installed them. I suspect this is not the current gimp source you're getting there. I know. But with current I meant: the sources that were used to compile the Gimp, which I have installed at the moment as a binary. For development you really need to look at the stuff in the git repository. OK. So I first look at git. I have heard of it, but not used it so far. Of importance are the three git repositories babl / gegl / gimp, which need to be built and installed (in your own prefix, not (!) parallel to the system installed babl/gegl/gimp versions). For gtk+ and glib development code the system stuff *might* be too old, we have debian testing as a rule-of-thumb of the versions we depend on. Yes. Using non-standard locations hopefully will not need too much effort. Is this all easy going with ./configure? I hope so. Are there scripts, especially for installing all the stuff locally, so that Gimp-development can be done in this way with just a one-liner? A lot of other information is available at http://developer.gimp.org/faq.html OK, I will read it. [...] It looks like a lot of code... It is. But it is IMHO really good code... :) I have looked into some of the code... I looked on-systematically at some places. The first file I picked had a lot of hard coded values inside, doing it without defines, so I was shocked at the first moment... ;-) but the other files I looked into looked quite good. The coding style is close to what I use for my own code, and all in all it looked good, yes. :) If you drop by in #gimp on irc.gimp.org (aka gimpnet) ask questions (and wait patiently, it is not really a real-time-response channel) aha. Some days ago I asked something quite unpatiently, and got no answer during the time I was looged in... So, thank you for clarification. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] New on this list... how to start juming into Gimp-dvelopment?
Hello, I'm new on the developer list. I like to look for possibilities where I can help in the Gimp-development. I'm using Gimp since about 1 1/2 years, starting with Rolf Steinort's nice video tutorials. Gimp has helped me solving some picture enhancements in the emantime, but it also has some limitations. Here I want to help. I would like to help in pushing into the direction of overcoming the 8-Bit limitation. Also interesting would be for me to have more knowledge on the plugin-stuff; I had already written some little Python-plugins, but to know more about that would be fine I also think about implementing a foreign language interface for OCaml. But I should start with some small steps I think. I have just looked into some *.c files, but rather unsystematically. At the moment I'm using Ubuntu and used the apt-get source gimp to download the sources of the current Gimp on my distribution. I looked for the necessary tools, which were not all installed. So then I installed them. And at the GEGL-part I encountered other problems: there is a library babl, which is already installed, but seems to be out of date. I got the sources, but the mentioned confiugure-script was not there. I tried other ways, but did not get it compiled, and so I did not got something Gimpy to play with. So no easy start jumping into Gimp was possible. What would you recommend as a setup for the develeopment? Are there already scripts for the Gimp-developers that just can be used? For example: maybe there is a bunch of scripts that invoke svn update's and maybe also installation of the stuff that is used to develop the software (automatically compiling all the libraries in local directuries)? Any ideas on what stuff can be done at the begin, without influencing other parts of the current development? Starting with svn conflicts would be not that good, IMHO. Also I'm looking for an overview on the whole source and the way the software is organized. It looks like a lot of code... Also maybe it would make sense to go to developer meetings? I'm located in Berlin. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why doesn't --enable-debug turn off optimization?
Zitat von Omari Stephens x...@csail.mit.edu: It seems like running configure with --enable-debug should also disable optimization; otherwise you end up with a bunch of magically inlined or optimized-out function calls, optimized-out variables, and confusing execution order. Thoughts? [...] AFAIK gcc inlines starting with -O3 and higher. I'm not sure what happens with optimizations with less than -O3, but maybe the result is not that extremely chaotic. Completely disabling optimizations would make sure that debugging might be possible easily. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] UI problem in bump-map plug-in dialog
Hi! I've found a UI problem in the bump-map plug-in dialog. If the open files have to many layers, not all layers can be displayed in the option menu. They fit not in a single column on the screen. To select the layer you want to use for the bumpmap, you have to close all unneeded files or to reduce the amount of layers. Both methodes are not very suitable. Maybe we can replace the option menu with a widget like the layer dialog. I'm using Gimp 1.2.3/linux but think version 1.3.x has the same problem. Bye! Oliver -- http://www.blup-bbs.de http://www.des-or-mad.net ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] LZW Patent outside US
On Fri, Jun 29, 2001 at 09:22:07AM +0200, Juergen Osterberg wrote: The true inequity of the Unisys patent is not 'obviousness'. It's that they waited until every web site on the planet was using GIF before they started to enforce it. That gave them the maximum chance for royalties. regarding the LZW algorithm I was always wondering in which countries *outside* the US Unisys holds a patent on that. Obviously nowhere (yet) in Europe?! Someplace else? Havent found any information on that (such as on burnallgifs.org etc.)? I've heard they're trying to enforce this patent on web providers who are hosting GIF images. In my opinion, this is absolutely senseless, as they only hold the patent on the *compression* (and decompression) algorithm. But images are never compressed or restored on webservers, so providers should say: We host anything here, it doesn't matter to us what it is. In any case only the programs that make gifs or those that show them have some relationship with the patent, right? Well, anyway, if the software business is going on like this, soon we'll have more lawyers than programmers in it! But, have a lot of fun with GIMP programming, each feature is one step forward! happy coding, Oliver Freyd ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
