Re: [Gimp-developer] script-fu problem in 2.6
I haven't been following this discussion that closely; however, I would point out that the PDB function 'gimp-layer-get-mask' will return -1 if the layer does not have a mask. Yes. I manage to use that in 2.4 (because some strange reason), but the method does not work in 2.6. How would you make it work? (unless (= (car (gimp-layer-get-mask SharpenLayer)) -1) (gimp-layer-remove-mask SharpenLayer MASK-APPLY) ) Thanks!! L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script-fu problem in 2.6
saulgo...@flashingtwelve.brickfilms.com wrote: Perhaps we need to add gimp-layear-has-mask then. Until then you could use gimp-plugin-set-pdb-error-handler to take over the error handling in order to suppress the warning. I haven't been following this discussion that closely; however, I would point out that the PDB function 'gimp-layer-get-mask' will return -1 if the layer does not have a mask. Yes. I manage to use that in 2.4 (because some strange reason), but the method does not work in 2.6. How would you make it work? Thanks, L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] script-fu problem in 2.6
Hi, I have a script-fu that worked fine in 2.4 and it's broken in 2.6. It had a conditional to apply the layer's mask if it exists. This is what it read: (cond ((gimp-layer-get-mask SharpenLayer)(gimp-layer-remove-mask SharpenLayer 0)) ) Now it is broken. How do I tell script-fu 2.6 to apply a layer mask (if it exists)? I was unable to find something like a boolean gimp-layear-has-mask, and gimp-layer-remove-mask returns an error if the mask does not exist. Thanks!! L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script-fu menu
* El 02/03/08 a las 15:25, Laxminarayan Kamath chamullaba: I am not a GIMP developer, though I have been a spectator on this list for a while now. I suggest that you specify exactly what you are trying, and what exactly you are looking for. A detailed work-flow and a UI mock-up image would best describe what you want. Specify the problem.. not the solution. Sorry, I thought I was clear enough (did I specify the solution??) What I want to do is what is pretty standard in these cases: My script-fu has a lot of options, and a check box to use default values of these options. I want these options to become grayed out when the check box is checked. Just that. My other question was if it is possible to add text to a script-fu option window that is not related to an option of the script. But I do not know if these are possible in script-fu, and I didn't find a complete enough reference for script-fu. Thanks again, L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-developer Digest, Vol 66, Issue 3
Sorry, I thought I was clear enough (did I specify the solution??) What I want to do is what is pretty standard in these cases: You were certainly clear enough, I thought I was... but there is no way to do that using script-fu. If you need fine control of the interface, you'll have to use a more powerful language. Ok, this is what I suspected. Someone here told me some time ago to try python-fu, but my script is almost done since long time ago, and I am not sure if python-fu would do it. Of course C would... Thanks Bill! L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-developer Digest, Vol 66, Issue 4
Luis A. Florit wrote: But I do not know if these are possible in script-fu, and I didn't find a complete enough reference for script-fu. There is some documentation about Script-Fu at http://www.gimp.org/docs/. I have been putting together my own set of documentation for Script-Fu which you can find at: http://www.ve3syb.ca/wiki/doku.php?id=software:sf:start Amongst the things you will find there are a list of the items you can use in the register block. Thanks a lot Kevin, and all the others that kindly answered my post. Now at least I know that I cannot do what I wanted in script-fu. My next projects will be done directly in C or python-fu. It seems that script-fu is kind of 'stalled'... Cheers, L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] script-fu menu
Hi, I am writting a (almost finished) plugin in script-fu and wanted some features for the script-fu main option window of my plugin, but I was unable to find this googling. So it's probably not possible... I want to do these on the plugin option window: 1) Gray-out some options according to checkboxes; 2) Add arbitrary text, horizontal lines, boxes, or something like that. I would appreciate any pointer where I can find the above, if they are available features. Thanks a lot, L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Mouse problems using Wacom tablets
Luis wrote: I tried to install Inkscape Fedora RPM, but for some reason the last repository version seems highly broken (at least with my package setup). I should compile it by myself when I have some time (lots of libraries and dependencies). There are autopackages available at the inkscape website. You can choose the latest stable version or svn compilations. It's not the cleanest way to install a package, but it will work for your tests. Perfect. I installed and tested it (see below). Anyway, your problem description is EXACTLY mine. Did you try disabling the eraser (not the stylus)? In that way, the mouse works (but not the eraser, of course). You should move the stylus to 'activate' the mouse. Is this also the behavior in Inkscape? My pen hasn't an eraser (it isn't a Wacom) so I can't tell. What I could see is the same in Gimp and in Inkscape. Once you've used the tablet, it seems to catch the pointer, and the mouse becomes unuseful for the app. But if you close the program, everything works as it should. For my GIMP you don't need to close it. The mouse always works in other apps. Only in GIMP, and in the canvas, it does not work. I'm guessing it's a GTK problem because Gimp and Inkscape share the same menu for activating the tablet. But I really don't know if I'm right. Somebody pointed here that is a problem fixed in the newest versions of gtk+ and linuxwacom, but I'll have to wait those libraries to be in the Ubuntu repos, since I'm not so comfortable experimenting with that kind of libraries (GTK mostly, I don't want to break something if I don't know how to fix it - at least in my computer for work :-p). For me, Inkscape worked TOO WELL (?!). I mean, I opened the Inkscape, and everything worked without changing the preferences: mouse, stylus and eraser. I then opened the preferences, and everything was DISABLED! I enabled everything, and everything still worked. I disabled everything, and everything STILL worked... Crazy. When changing the state of the input devices, I got errors in the console, though: (inkscape:6099): Gdk-CRITICAL **: gdk_window_set_background: assertion `GDK_IS_WINDOW (window)' failed (inkscape:6099): Gtk-CRITICAL **: gtk_scrolled_window_add: assertion `bin-child == NULL' failed (inkscape:6099): Gtk-CRITICAL **: gtk_widget_realize: assertion `GTK_WIDGET_ANCHORED (widget) || GTK_IS_INVISIBLE (widget)' failed (inkscape:6099): Gdk-CRITICAL **: gdk_drawable_get_colormap: assertion `GDK_IS_DRAWABLE (drawable)' failed (inkscape:6099): Gdk-CRITICAL **: gdk_window_set_background: assertion `GDK_IS_WINDOW (window)' failed (inkscape:6099): Gtk-CRITICAL **: gtk_scrolled_window_add: assertion `bin-child == NULL' failed (inkscape:6099): Gtk-CRITICAL **: gtk_widget_realize: assertion `GTK_WIDGET_ANCHORED (widget) || GTK_IS_INVISIBLE (widget)' failed (inkscape:6099): Gdk-CRITICAL **: gdk_drawable_get_colormap: assertion `GDK_IS_DRAWABLE (drawable)' failed Another strange thing is that the 3 devices picked up the same tool. I mean, I couldn't set one tool for stylus and other for the mouse. But I don't know if that is even possible in Inkscape. If someone still was trying to understand what was happening, he will give up now! :-) Thanks, L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Mouse problems using Wacom tablets (was 2.3.18 deletes exif...)
For a long time, nothing has changed in GIMP with respect to XInput devices. So the fact that an upgrade introduced this problem seems to be a strong indication that the problem is elsewhere. I have similar problems using a Genius tablet. Once I used the pen, mouse is no longer detected in the canvas. But I think is a GTK+xorg issue and not Gimp's one, because the same seems to happen in Inkscape. Luis, you should try with inkscape as well (remember to activate the tablet as an input device). Besides of that, the device driver for my Genius tablet seems to be completely broken for GTK apps under Ubuntu Feisty Fawn (it worked in the previous version). I think it's a GTK problem and not Xorg's one, because MyPaint works fine, but gimp and inkscape don't. I tried to install Inkscape Fedora RPM, but for some reason the last repository version seems highly broken (at least with my package setup). I should compile it by myself when I have some time (lots of libraries and dependencies). Anyway, your problem description is EXACTLY mine. Did you try disabling the eraser (not the stylus)? In that way, the mouse works (but not the eraser, of course). You should move the stylus to 'activate' the mouse. Is this also the behavior in Inkscape? Thanks, L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.3.18 deletes exif data from images
* El 24/06/07 a las 14:57, Sven Neumann chamullaba: Bug GIMP is the only application, graphic or not, that showed this problem, in several years of daily use. The mouse works on every other application perfectly, and always did. Did you actually try it with another GTK+ application that has support for XInput devices? I don't know of another one but GIMP. Could you please point me such an application for testing? It is not surprising that applications that don't enable input devices are not affected. Yes, perhaps... Observe that what is affected is the mouse, not the tablet, though. And only in GIMP canvas, not in any other GIMP window. And through 3 fresh and complete OS upgrades (Fedora 4,5 and 6) the mouse is still broken in GIMP canvas. Gimp worked fine in Fedora 3 and below. For a long time, nothing has changed in GIMP with respect to XInput devices. So the fact that an upgrade introduced this problem seems to be a strong indication that the problem is elsewhere. Perhaps in the X server or, more likely, in the wacom driver. Of course there might also be something that GIMP does wrong. But the vast majority of GIMP users with a tablet doesn't seem to be affected by this problem. As I said already, someone who is affected by this problem will have to track it down. It is not reproducible for me and, as it seems, for no other GIMP developer. Yes, I understand the difficulty with this. Thanks, L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.3.18 deletes exif data from images (2)
Hi Mukund, Compiling the trunk, I saw that GIMP (also version = 2.3.18) needs libexif = 0.6.15, while there is no RPM repository with libexif version bigger than 0.6.13. (Probably most RPM based distros have the libexif outdated). Ah good. So there lies your problem :-) Yes. Thanks for your time, and sorry for the mess. Btw I use Fedora 7 (RPM based) and we have 0.6.15 in it. I still use Fedora 6 (too much work to find time for upgrading...) with 11 repositories, and the most recent is 0.6.13. But this is not unusual with Fedora. After many years with Red Hat/Fedora, am planing to migrate to Debian because things like this. Anyway, I'll download the 0.6.15 tarball and compile it. Thanks again, L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.3.18 deletes exif data from images
Hi Sven, So, yes, I state, publicly, again: this bug has been ignored for months (in fact, for years, since Fedora 4, and we are now in Fedora 7). No matter if you let me 'get away' or not. These bug reports have not been ignored. They are not GIMP bugs and have been reassigned accordingly. Most likely the bug is not even in GTK+ but on a lower level. The fact that it works for most people makes it likely that it is perhaps even just a misconfigured X server. Of course, yes, I can be wrong. Bug GIMP is the only application, graphic or not, that showed this problem, in several years of daily use. The mouse works on every other application perfectly, and always did. And through 3 fresh and complete OS upgrades (Fedora 4,5 and 6) the mouse is still broken in GIMP canvas. Gimp worked fine in Fedora 3 and below. Disabling the eraser (?!) in GIMP make the mouse work. X config (in particular, xorg.conf) was never changed. I know no X config could make all this happen. But I can be wrong. I am no expert on this (in anything, in fact). Someone who if affected by the problem will have to track it down. There is no chance that a core GIMP or GTK+ developer will find the time to debug a problem that he/she cannot reproduce. Indeed, this is a problem. The same problem that appears with intermittent bugs (the above is not intermittent, though). : Pals, : : I reported this bug in this list some time ago, and got no : answer (I think), and the 2.3.16 version still has the same bug: : The despeckle plugin shifts the image one pixel to the right, : and one to the bottom. Consequently, it is essentially useless. : If you draw in the middle of a white background a black cross : like this: : : x : xxx : x : : and run the despeckle plugin with radius 1, you get this : asymmetric output: : : x : xxx : xx : : Thanks, : : Luis. I hope you don't think the 'tone' was aggressive in this mail also... Yes, I do think that the tone of this mail was aggressive. You complain that you don't get an answer and you complain that the bug is still there. Not only there was no complain (but a remark where I even added 'I think'), but I also took the time to resend the same bug in a friendly way, and you call that aggressive! Clearly, you're going to say the first thing that comes to your mind just to maintain your position. Discussions under these terms are useless. Interestingly, yesterday someone suggested me in this list to read the page http://www.catb.org/~esr/faqs/smart-questions.html (quite interesting, BTW), where it says: - Much of what looks like rudeness in hacker circles is not - intended to give offense. Rather, it's the product of the direct, - cut-through-the-bullshit communications style that is natural to - people who are more concerned about solving problems than making - others feel warm and fuzzy. You simply can not demand that a bug is fixed. Again you insist on changing the words that I wrote. I never demanded anything to be fixed. In fact I never demanded anything. Just asked for the bug reports not to be ignored. Please, try to see the point on what I am trying to say... I do believe that GIMP is a great program, in fact the best OS image editor. Easily. And by using it I know that you all do a great job with it. As you know, I installed the trunk version, so I follow closely its development, and don't mind using devel versions with some sacrifices. Therefore, I know how fast it changes, and that means that there is a lot of work being done to it right now. So, it was never my intention to criticize any of you as developers. However, GIMP (as well as many other OS projects) is not the sole result of the developers. Of course you have the biggest part, but GIMP is also the result of the people that makes plugins, or the community that says something about its usability, or... the people that bother reporting bugs. It is very bad for a reporter to see 'his' bug unanswered and present in several versions after he reported it. What he must do then? He just stops reporting (as I did with Fedora). And the project and the community loose with that. And, unfortunately, this happens with GIMP. At least this happened with me. Three times. Perhaps, as you said, with good reasons: because maintainers are no longer around, or some other reasons. And perhaps you're right, and I am just too impatient (but not aggressive) reporting bugs... Or perhaps gimpdevel is overloaded with bug reports and you are very few to handle all of them. But I read posts like these before in gimpdevel, and never in the other mailing lists that I've participated. Even the ones with only 1 developer (Cartes du Ciel, Xephem). The fact is that this is bad for the project. This is bad for YOUR project. Perhaps, there is no way to improve this...? I only hope you don't think that everything is just fine as it is. L.
Re: [Gimp-developer] 2.3.18 deletes exif data from images
* El 22/06/07 a las 8:53, Sven Neumann chamullaba: Hi, On Fri, 2007-06-22 at 00:18 -0300, Luis A. Florit wrote: From aggressive answers, to unanswered mails (not that bad), It would help a lot if you could try to be more precise in your mails. That would avoid the need to ask for details. If a dialog is titled Save as JPEG, then why do you call it Save as ... several times? Only you seemed not to know, or didn't want to know, where the Save EXIF data option is in GIMP. Alex Pounds knew exactly what I was talking about, and understand the same as me by Save as ... dialog. Your message was so imprecise that even experienced GIMP developers could not tell what exactly you are talking about. Several plug-in can save EXIF data and without the information which plug-in you are using, there is not much we can do. You answered as if no such option never existed, and not as if there were many. Also, your questions are rather aggressive. It would help a lot if you could try to understand that people are working on this project in their free time. Of course. If something breaks in the development version, then this does not happen with the intent of breaking something. I never said that. We are all here in our free time, we are all here to try to make GIMP better for others and for us. Not only the developers, but also the ones that bother reporting bugs. It is also not a personal offense, but your mails make it look like one. I don't understand where you read that. Look at this for example: So: 1) Is the EXIF source in the all the 3 cameras (of 3 different brands) broken? 2) Why all the other graphic programs that I use (showfoto, gqview, gthumb, exiftool) always showed the EXIF data with no problem, and still show? 3) Why the Save EXIF data option in the Save as... dialog is no longer present? 4) Why GIMP deletes the EXIF data now? 5) If broken, why previous versions of GIMP preserve the EXIF data? GIMP 2.3.16 2.3.17 and 2.2.14 still work perfectly for me (in this respect; I had to stop using 2.3.17 because it crashed consistently, probably because of its known bug). Is this tone in any way helpful? The only thing you can achieve by putting it this way is to demotivate the developer working on this. Sorry, but I see no aggression in the above quote. I just tried to point to Mukund that this had nothing to do with broken EXIF, giving several arguments for that. To be precise. BTW, it is interesting to notice that you cut the paragraph that was right before the one you quoted, where I wrote: : Please excuse me, Mukund, but I will be very surprised : if this has something to do with broken EXIF data. Do you also think that an argument that begins with Please excuse me... is aggressive? Probably not, but for some reason you cut that sentence and took the next out of context. And still, it is not aggressive. My apologies to Mukund if he felt that. to ignored bug reports in bugzilla (VERY bad). Please point me to any ignored bug reports. We take bug reports very seriously and I will not let you get away stating in public that we would ignore bug reports. My bug report was sent to bugzilla.redhat when Fedora 4 was out. bugzilla.redhat is dead now. But I sent this email, with subject still the same bug on April 30 to this list (Gimp-developer Digest, Vol 56, Issue 1, to be precise): : However, about a year or two ago, I reported a bug in Bugzilla: : the mouse buttons in GIMP main image window do nothing when I have : attached a my Wacom tablet. ONLY in GIMP. This happened with Fedora : 4,5,6 (fresh installs), with GIMP stable and devel versions. It is : the only program that I have this problem, and the bug is still alive. And just a quick search in http://bugzilla.gnome.org/ in this precise minute returned this: http://bugzilla.gnome.org/show_bug.cgi?id=406440 (2007-02-10) http://bugzilla.gnome.org/show_bug.cgi?id=449590 (2007-06-20) So, 3 bugzilla reports of the same bug. 4 months and not a single answer. And still stated as unconfirmed! And still we cannot use the mouse in GIMP. So, yes, I state, publicly, again: this bug has been ignored for months (in fact, for years, since Fedora 4, and we are now in Fedora 7). No matter if you let me 'get away' or not. BTW, the thread of April 30 mentioned above was because a bug report I made in this list about a shift in the despeckle plugin was unanswered! I sent a second report (also included in the same Digest above): : Pals, : : I reported this bug in this list some time ago, and got no : answer (I think), and the 2.3.16 version still has the same bug: : The despeckle plugin shifts the image one pixel to the right, : and one to the bottom. Consequently, it is essentially useless. : If you draw in the middle of a white background a black cross : like this: : : x : xxx : x : : and run the despeckle plugin with radius 1, you get this asymmetric : output: : : x
Re: [Gimp-developer] 2.3.18 deletes exif data from images
I have a Panasonic FZ50 whose EXIF data was always preserved by GIMP. Now, opening a file straight from the camera with GIMP and immediately saving it deletes the EXIF. And in the Save as... dialog, there is no option to save (or not) the EXIF, as it always was. Not evey a grey unavailable option. There has never been such an option in the Save as... dialog. That's probably the reason why no one understood your mail and cared to answer. Sven On Thu, 2007-06-21 at 07:58 +0100, Alex Pounds wrote: There has never been such an option in the Save as... dialog. My copy of the Gimp disagrees with you on this point: http://www.ethicsgirls.com/stuff/exifshot.jpg That's not the Save As dialog which would be the file-chooser you get earlier in the process of saving an image. This is the dialog created by the JPEG plug-in. Sven Thanks for (yet another) (double) stupid answer, Sven. L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.3.18 deletes exif data from images
Hi Mukund, On Wed, Jun 20, 2007 at 09:01:16PM -0300, Luis A. Florit wrote: Here is the bug in question: http://bugzilla.gnome.org/show_bug.cgi?id=446809 In fact, this bug in 2.3.18 is not related (only) to Bibble. Yes, it's not limited to Bibble. That's a title stated by the reporter, but the bug encompasses the class of bugs where EXIF info is not saved when the EXIF info in the source image is broken (missing required tags). Various cameras/applications can make such images with faulty EXIF info. Please excuse me, Mukund, but I will be very surprised if this has something to do with broken EXIF data. I have 3 cameras: a Canon SD500, a Nikon Coolpix 4500, and a Panasonic FZ50. For the 3, I never have any problem with GIMP (or any other program). Now, for the 3, the Save as... dialog (yes, Sven, the Save as... dialog) show no Save EXIF data option, and for the 3 the EXIF data is now removed. So: 1) Is the EXIF source in the all the 3 cameras (of 3 different brands) broken? 2) Why all the other graphic programs that I use (showfoto, gqview, gthumb, exiftool) always showed the EXIF data with no problem, and still show? 3) Why the Save EXIF data option in the Save as... dialog is no longer present? 4) Why GIMP deletes the EXIF data now? 5) If broken, why previous versions of GIMP preserve the EXIF data? GIMP 2.3.16 2.3.17 and 2.2.14 still work perfectly for me (in this respect; I had to stop using 2.3.17 because it crashed consistently, probably because of its known bug). I have a Panasonic FZ50 whose EXIF data was always preserved by GIMP. Now, opening a file straight from the camera with GIMP and immediately saving it deletes the EXIF. And in the Save as... dialog, there is no option to save (or not) the EXIF, as it always was. Not evey a grey unavailable option. I reported this issue a week ago to this list, but got no answer. First, do a check with GIMP trunk and see if the issue has been fixed. If not, please report your image (the original source image) at the same bug too. We'll take a look at it and if it's a different bug, then we'll file another one for it. Please mark the bug as reopened too when you attach the image. Ok. Thanks the time you took to answer, Mukund. Cheers, Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.3.18 deletes exif data from images (2)
Hi Mukund, On Wed, Jun 20, 2007 at 09:01:16PM -0300, Luis A. Florit wrote: Here is the bug in question: http://bugzilla.gnome.org/show_bug.cgi?id=446809 In fact, this bug in 2.3.18 is not related (only) to Bibble. Yes, it's not limited to Bibble. That's a title stated by the reporter, but the bug encompasses the class of bugs where EXIF info is not saved when the EXIF info in the source image is broken (missing required tags). Various cameras/applications can make such images with faulty EXIF info. Please excuse me, Mukund, but I will be very surprised if this has something to do with broken EXIF data. I have 3 cameras: a Canon SD500, a Nikon Coolpix 4500, and a Panasonic FZ50. For the 3, I never have any problem with GIMP (or any other program). Now, for the 3, the Save as... dialog (yes, Sven, the Save as... dialog) show no Save EXIF data option, and for the 3 the EXIF data is now removed. So: 1) Is the EXIF source in the all the 3 cameras (of 3 different brands) broken? 2) Why all the other graphic programs that I use (showfoto, gqview, gthumb, exiftool) always showed the EXIF data with no problem, and still show? 3) Why the Save EXIF data option in the Save as... dialog is no longer present? 4) Why GIMP deletes the EXIF data now? 5) If broken, why previous versions of GIMP preserve the EXIF data? GIMP 2.3.16 2.3.17 and 2.2.14 still work perfectly for me (in this respect; I had to stop using 2.3.17 because it crashed consistently, probably because of its known bug). I have a Panasonic FZ50 whose EXIF data was always preserved by GIMP. Now, opening a file straight from the camera with GIMP and immediately saving it deletes the EXIF. And in the Save as... dialog, there is no option to save (or not) the EXIF, as it always was. Not evey a grey unavailable option. I reported this issue a week ago to this list, but got no answer. First, do a check with GIMP trunk and see if the issue has been fixed. If not, please report your image (the original source image) at the same bug too. We'll take a look at it and if it's a different bug, then we'll file another one for it. Please mark the bug as reopened too when you attach the image. Ok. I realized what happens. Compiling the trunk, I saw that GIMP (also version = 2.3.18) needs libexif = 0.6.15, while there is no RPM repository with libexif version bigger than 0.6.13. (Probably most RPM based distros have the libexif outdated). Observe that version libexif 0.6.15 has a delicate security bug that was only fixed in the last version 0.6.16 (2007-06-12). My fault, I should have checked better the config log. Sorry. Thanks again, Mukund. L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Rudeness on gimp devel, version 754 (was '2.3.18 deletes exif data from images')
On 6/22/07, Luis A. Florit wrote: Thanks for (yet another) (double) stupid answer, Sven. offtopic We are not going to compensate loss of Carol by become rude ourselves are we? Could we possibly take a deep breath, count to 10 and smile friendlier to each other? /offtopic Alexandre Of course you're right, Alexandre. The point is, again, the constant rudeness in gimp devel list... From aggressive answers, to unanswered mails (not that bad), to ignored bug reports in bugzilla (VERY bad). All this happened to me already. Anyway, just a question: Why this has been discussed so many times in this list I can refer to a previous thread ended in March 23, called 'Rudeness on gimp devel and bugzilla', where it was discussed how the rudeness here make people to pull out of the GIMP project. Or the last one about Carol. I never participated in a list where this was discussed even once. And here it is discussed constantly! Could this possible be due only because of one Carol? I've never talked with any Carol! In any case, *MY* rudeness is absolutely unforgivable. My apologies to you, Sven. Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.3.18 deletes exif data from images
Hi Mukund, Hi Alexander On Wed, Jun 20, 2007 at 10:06:53AM +0300, Alexander Rabtchevich wrote: Haven't found in bugs and SVN changelog. GIMP 2.3.18 (Windows) deletes exif data from images. There is a similar bug on bugzilla.gnome.org filed against the GIMP component (it may have been closed recently). Please find the bug and attach your source image (original) to it. It may be that your image's EXIF data is invalid and missing tags required in various IFDs. Raphael has put a patch into GIMP trunk recently to work around this issue and you can try that and see if the EXIF data is still deleted. If you can't find the bug, please file a new bug with the image in question and reply to this thread with the bug number. Here is the bug in question: http://bugzilla.gnome.org/show_bug.cgi?id=446809 In fact, this bug in 2.3.18 is not related (only) to Bibble. I have a Panasonic FZ50 whose EXIF data was always preserved by GIMP. Now, opening a file straight from the camera with GIMP and immediately saving it deletes the EXIF. And in the Save as... dialog, there is no option to save (or not) the EXIF, as it always was. Not evey a grey unavailable option. I reported this issue a week ago to this list, but got no answer. Thanks, L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] overwrite problem
* El 16/06/07 a las 16:09, Sven Neumann chamullaba: Hi, On Fri, 2007-06-15 at 02:41 -0300, Luis A. Florit wrote: I am having an 'overwrite file' problem in 2.3.18. When trying to save a file that already exists, ask as usual if you want to overwrite. If you say YES, it does NOT overwrite, and writes a Untilted.xcf file instead. Are you absolutely sure? What does it display in the image status bar? I got this 3 different days, and several times... I cannot reproduce this, tried with GTK+ 2.10.13 and GTK+ 2.11.3. Strange... Because now I cannot reproduce this either! And I made no systems updates. Well, sorry for this. If I get the same behavior again, will report back. Thanks, Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] exif data
Hi, Where is the option to save the EXIF data in 2.3.18?? Thanks, L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] overwrite problem
Hi, I am having an 'overwrite file' problem in 2.3.18. When trying to save a file that already exists, ask as usual if you want to overwrite. If you say YES, it does NOT overwrite, and writes a Untilted.xcf file instead. Thanks, Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] bash command inside script
Sorry for the empty email I've just sent. My mistake. Now, about my question: Is there a way to read the output of a bash command inside a script-fu? I want to make a script-fu that uses the ExifTool program output. This is to answer Kevin: Save the output from the ExifTool to a file and have the Script-Fu script read the file with the saved output. I think this is not practical for what I need (that of course you didn't need to know). My script has a field in the GUI to enter the ExifTool data. I think that copy-pasting the data to this field is easier than running Exiftool, saving its output to a file for each image. Now, the answer to Joao: two words: go python - Seriously. Script-fu has the advantage that it can have a small itnerpreter which can therefore live inside GIMP's source tree. And that is it. Of course, it fits whoever likes solving puzzles on how to perform simple tasks such as parsing a string letter by letter, or getting the output of a file. Python is a full featured language, which greatest advantage is to allow one to concentrate on his problem instead of the language. Just check some of the python-fu examples that come with GIMP itself. Use the os module to be able to spawn sub-proccess and read the output, like in:] import os files = os.popen (ls devel/gimp).readlines() for file in files: ... print file.upper() ... ACINCLUDE.M4 ACLOCAL.M4 APP AUTHORS (in time: the and ... are prompts put ther by the interactive interpreter, not part of the language itself) I agree. In fact, I always found the script-fu language (a variant of lisp, right?) simply horrible. However, my script-fu is 100% functional, and I think that it doesn't worth it the effort to translate the full script to python just because of this. But I will take your advice for the next time, and my next plugin will be in python from the beginning. Thank you both!!! L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] bash command inside script
* El 04/06/07 a las 16:49, Joao S. O. Bueno Calligaris chamullaba: On Sunday 03 June 2007 22:47, Luis A. Florit wrote: Hi, Is there a way to read the output of a bash command inside a script-fu? I want to make a script-fu that uses the ExifTool program output. Thanks! Luis. two words: go python - Seriously. Script-fu has the advantage that it can have a small itnerpreter which can therefore live inside GIMP's source tree. And that is it. Of course, it fits whoever likes solving puzzles on how to perform simple tasks such as parsing a string letter by letter, or getting the output of a file. Python is a full featured language, which greatest advantage is to allow one to concentrate on his problem instead of the language. Just check some of the python-fu examples that come with GIMP itself. Use the os module to be able to spawn sub-proccess and read the output, like in:] import os files = os.popen (ls devel/gimp).readlines() for file in files: ... print file.upper() ... ACINCLUDE.M4 ACLOCAL.M4 APP AUTHORS (in time: the and ... are prompts put ther by the interactive interpreter, not part of the language itself) js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] error on roundcorners
Hi, I am getting an error on the script round-corners.scm (gimp 2.3.17). A pop-up window opens with the following error: Procedural database execution of gimp-image-undo-group-end failed: and just that... Thanks, L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] bash command inside script
Hi, Is there a way to read the output of a bash command inside a script-fu? I want to make a script-fu that uses the ExifTool program output. Thanks! Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] still the same bug
Glad you all confirmed the bug, and sorry gg if I misunderstood you. However, I am not sure what histogram correction means here. I saw the same shift in the despeckle plugin for photographies, like a human face. Thanks, Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] still the same bug
For Bill: I reported this bug in this list some time ago . . . For philosophical questions, it is good to bring them up first on this list. But for actual bugs, in the sense of the program doing something that is clearly incorrect, it is best to file a Bugzilla report. The advantage, and disadvantage, of Bugzilla is that nothing reported there is ever forgotten -- and few reports are completely ignored. Well, I am really tired about reporting bugs at Bugzilla and not even getting an answer, specially for Fedora bugs. So tired that I don't even fill bugs anymore, and in fact planning to abandon Fedora. bugzilla.redhat.com = DEAD. But, for what you said, I assume the GIMP Bugzilla is good. However, about a year or two ago, I reported a bug in Bugzilla: the mouse buttons in GIMP main image window do nothing when I have attached a my Wacom tablet. ONLY in GIMP. This happened with Fedora 4,5,6 (fresh installs), with GIMP stable and devel versions. It is the only program that I have this problem, and the bug is still alive. For gg: I suspect it got ignored since one pixel offset errors are pretty much to be expected. ???!!! Well, now this answer was indeed unexpected! For me this kind of bugs is enough reason to never use a program!!! You cannot apply a filter with masks if it has shifts! I dont recall you mentioning the distortion last time. I think I did. could you provide more instructions to reproduce the error, Well, cannot tell you more... Adaptative, nonrecursive, 1 pixel radius, black=7, white=248. A 5 pixel cross in the middle of a white image, and I got a NONSYMMETRIC 6 pixel output like this: x xxx xx If you run it again, and again, you get a cellular automata. Another: Draw a small diagonal (bottom left to top right) segment, and despeckle 1 pixel in radius. Repeat Despeckle many times. You will get a diagonal moving cellular automata. Of course, I didn't discover this drawing crosses. I saw the obvious shift during despeckle in a real image. I removed my .gimpXXX files, and the bug persists. I just made a cross ran despeckle and see not difference at all. Did you use 1 pixel radius? In fact, the bug is present for any radius, but is hard to see it for big ones. For Geert: Is this really a bug, a radius 1 will give you a window of 3x3 pixels. No, I get a nonsymmetric output of 6 pixels. Only for the devel versions. The despeckle filter is a median filter, with a cross five of the nine surrounding pixels will yield a medium equal to one of the cross pixels. You cannot get asymmetric output from a symmetric input... Thanks, L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] still the same bug
Pals, I reported this bug in this list some time ago, and got no answer (I think), and the 2.3.16 version still has the same bug: The despeckle plugin shifts the image one pixel to the right, and one to the bottom. Consequently, it is essentially useless. If you draw in the middle of a white background a black cross like this: x xxx x and run the despeckle plugin with radius 1, you get this asymmetric output: x xxx xx Thanks, Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] despeckle plugin
Pals, The Despeckle plugin shipped with GIMP 2.3.15 has a strange behavior: it shifts the image 1 pixel to the right, and one down, at least in some channles. Compare with the plungin in gimp 2.2. Probably you already observed this. Thanks, Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] gimp_pixel_rgns_register
Pals,
As you noticed, this is my first plugin and I have many silly
questions... Sorry for bothering you with these.
What my plugin does is an iterpolation to get rid of noise by
means of a classical local analysis of a square neighborhood or
radius r of each pixel to change it (if necessary) after the analysis.
My plugin is working fine, using the 'gimp_pixel_rgn_set_row'
procedure and the shuffle raw function contained in
http://developer.gimp.org/writing-a-plug-in/3/myblur5.c
I am already using this in big images (5MB or more).
However, I saw that what is vastly used for plugins is
'gimp_pixel_rgns_register' with ONE iterator like:
for (pr = gimp_pixel_rgns_register (1, dest_rgn);
pr != NULL; pr = gimp_pixel_rgns_process (pr))
{
}
or even TWO iterators like:
for ( pr = gimp_pixel_rgns_register (2, dest_rgn, src_rgn);
pr != NULL; pr = gimp_pixel_rgns_process (pr))
{
..
}
I don't really understand what these for loop do, except that it
somehow loops between the tiles.
My questions: When to use one and when two iterators? Which one
should I use for a procedure like the one described in my plugin?
Is this indeed faster than the method I implemented based in myblur5.c?
Thanks a lot,
Luis.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp_pixel_rgns_register
Sven and Bill, I see. My plugin is already reasonably fast, so is good to know I don't need huge changes. Thanks a lot for your prompt answer!! Nice forum! Cheers, Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] how to call a plugin
Pals, I am feeling so silly in trying to develop a plugin... I am stalling even at the most easy tasks. Now, I just want to blur my drawable from my plugin. I tried this: GimpParam *rreturn_vals; gint nnreturn_vals; rreturn_vals = gimp_run_procedure(plug_in_blur, nnreturn_vals, GIMP_PDB_INT32, GIMP_RUN_NONINTERACTIVE, GIMP_PDB_IMAGE, param[1].data.d_image, GIMP_PDB_DRAWABLE, gimp_drawable_get (param[2].data.d_drawable), GIMP_PDB_END); However, I get the following error: Procedure 'plug-in-blur' has been called with an invalid ID for argument 'drawable'. Most likely a plug-in is trying to work on a layer that doesn't exist any longer. What am I doing wrong? Sorry for the silly questions and thanks! Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] how to call a plugin
Hi Bill, Now, I just want to blur my drawable from my plugin. I tried this: GimpParam *rreturn_vals; gint nnreturn_vals; rreturn_vals = gimp_run_procedure(plug_in_blur, nnreturn_vals, GIMP_PDB_INT32, GIMP_RUN_NONINTERACTIVE, GIMP_PDB_IMAGE, param[1].data.d_image, GIMP_PDB_DRAWABLE, gimp_drawable_get (param[2].data.d_drawable), GIMP_PDB_END); However, I get the following error: [...] The problem is the gimp_drawable_get. As you can learn in the GimpDrawable section of the libgimp documentation, this function does not return the integer ID of the drawable, it creatss a new struct containing information about the drawable. I think you should just use param[2].data.d_drawable. (The handling of drawables in libgimp is pretty awkward, but probably shouldn't be changed at this point because it would create huge backward compatibility issues.) Yep, it worked! Thanks a lot!! L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] about gimp_zoom_preview_new
Pals, I realized that gimp 2.3.15 (and some versions before) comes with zoom for previews. A very useful feature for what I want to develop (a noise reduction plugin). I added a line 'gimp_zoom_preview_new (drawable);' that I got from http://developer.gimp.org/api/2.0/libgimp/GimpZoomPreview.html The plugin complies just fine, but when trying to run it in gimp 2.3.15 the plugin crashes with a message in the console: plugin-full-path: symbol lookup error: plugin-full-path: undefined symbol: gimp_zoom_preview_new (gimp-2.3:21083): Gimp-Plug-In-WARNING **: gimp-2.3: plug_in_flush(): error: Broken pipe So, what am I doing wrong? Thanks! Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] about gimp zoom preview new
On Mon, 12 Mar 2007 15:22:49 +0100, Luis A. Florit [EMAIL PROTECTED] wrote: (gimp-2.3:21083): Gimp-Plug-In-WARNING **: gimp-2.3: plug_in_flush(): error: Broken pipe This is nothing to do with the zoom preview mate, you've got a blocked toilet!! I should call out a plumber, this could get messy. This often happens in older properties due to subsidence or nearby tree roots. LOL ! sorry, had to laugh at the way that error came out. ;) Sorry, I didn't understand your answer... I just want to add zoom buttons to the preview window. I saw that many plugins use this. How to do it? Thanks, Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] about gimp zoom preview new
Hi, On Mon, 2007-03-12 at 11:22 -0300, Luis A. Florit wrote: I added a line 'gimp_zoom_preview_new (drawable);' that I got from http://developer.gimp.org/api/2.0/libgimp/GimpZoomPreview.html The plugin complies just fine, but when trying to run it in gimp 2.3.15 the plugin crashes with a message in the console: plugin-full-path: symbol lookup error: plugin-full-path: undefined symbol: gimp_zoom_preview_new Looks like the plug-in is not picking up recent enough versions of libgimpui. Try ldd on the executable. Mmmm... I see... # ldd .gimp-2.3/plug-ins/anulardenoise linux-gate.so.1 = (0x00cf4000) libgimpui-2.0.so.0 = /usr/lib/libgimpui-2.0.so.0 (0x004f1000) libgimpwidgets-2.0.so.0 = /usr/lib/libgimpwidgets-2.0.so.0 (0x003db000) libgimp-2.0.so.0 = /usr/lib/libgimp-2.0.so.0 (0x0034d000) libgimpcolor-2.0.so.0 = /usr/lib/libgimpcolor-2.0.so.0 (0x002cc000) libgimpmath-2.0.so.0 = /usr/lib/libgimpmath-2.0.so.0 (0x00101000) libgimpbase-2.0.so.0 = /usr/lib/libgimpbase-2.0.so.0 (0x0033c000) libgtk-x11-2.0.so.0 = /usr/lib/libgtk-x11-2.0.so.0 (0x04fa) libgdk-x11-2.0.so.0 = /usr/lib/libgdk-x11-2.0.so.0 (0x053b) libatk-1.0.so.0 = /usr/lib/libatk-1.0.so.0 (0x02aaa000) libgdk_pixbuf-2.0.so.0 = /usr/lib/libgdk_pixbuf-2.0.so.0 (0x029d8000) libm.so.6 = /lib/libm.so.6 (0x00d4a000) libpangocairo-1.0.so.0 = /usr/lib/libpangocairo-1.0.so.0 (0x0543f000) libpango-1.0.so.0 = /usr/lib/libpango-1.0.so.0 (0x0533f000) libcairo.so.2 = /usr/lib/libcairo.so.2 (0x02a3c000) libgobject-2.0.so.0 = /lib/libgobject-2.0.so.0 (0x02979000) libgmodule-2.0.so.0 = /lib/libgmodule-2.0.so.0 (0x029d3000) libdl.so.2 = /lib/libdl.so.2 (0x00d73000) libglib-2.0.so.0 = /lib/libglib-2.0.so.0 (0x028d9000) libc.so.6 = /lib/libc.so.6 (0x0011) libgimpmodule-2.0.so.0 = /usr/lib/libgimpmodule-2.0.so.0 (0x00297000) libX11.so.6 = /usr/lib/libX11.so.6 (0x00ae4000) libXfixes.so.3 = /usr/lib/libXfixes.so.3 (0x0278c000) libfontconfig.so.1 = /usr/lib/libfontconfig.so.1 (0x0274f000) libXext.so.6 = /usr/lib/libXext.so.6 (0x00d9b000) libXrender.so.1 = /usr/lib/libXrender.so.1 (0x00de9000) libXinerama.so.1 = /usr/lib/libXinerama.so.1 (0x00dfa000) libXi.so.6 = /usr/lib/libXi.so.6 (0x02a32000) libXrandr.so.2 = /usr/lib/libXrandr.so.2 (0x00df4000) libXcursor.so.1 = /usr/lib/libXcursor.so.1 (0x0278) /lib/ld-linux.so.2 (0x00bea000) libpangoft2-1.0.so.0 = /usr/lib/libpangoft2-1.0.so.0 (0x0538) libfreetype.so.6 = /usr/lib/libfreetype.so.6 (0x026a5000) libz.so.1 = /usr/lib/libz.so.1 (0x00d79000) libpng12.so.0 = /usr/lib/libpng12.so.0 (0x02727000) libXau.so.6 = /usr/lib/libXau.so.6 (0x00d8e000) libXdmcp.so.6 = /usr/lib/libXdmcp.so.6 (0x00d93000) libexpat.so.0 = /lib/libexpat.so.0 (0x00dc6000) I compiled gimp with './configure --prefix=/opt/gimp' for it not to touch my stable gimp 2.2 RPM install. I am compiling the plug-in with /opt/gimp/bin/gimptool-2.0 --install plugin Thanks, Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] about gimp zoom preview new
Hi Sven, On Mon, 2007-03-12 at 19:11 -0300, Luis A. Florit wrote: I compiled gimp with './configure --prefix=/opt/gimp' for it not to touch my stable gimp 2.2 RPM install. I am compiling the plug-in with /opt/gimp/bin/gimptool-2.0 --install plugin You will probably have to set PKG_CONFIG_PATH to get this right. I am doing something wrong... I tried with this command: export PKG_CONFIG_PATH=/opt/gimp/lib/pkgconfig ; /opt/gimp/bin/gimp-2.3 and I still having the same error. Thanks, Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] about gimp zoom preview new
gg, I didn't get your joke at a first sight. English is not my language... BTW, it was funny. :) L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] about gimp zoom preview new
Hi Ori, * El 12/03/07 a las 19:55, Ori Bernstein chamullaba: On Mon, 12 Mar 2007 19:36:42 -0300, Luis A. Florit [EMAIL PROTECTED] said: I am doing something wrong... I tried with this command: Yes, yes you are. export PKG_CONFIG_PATH=/opt/gimp/lib/pkgconfig ; /opt/gimp/bin/gimp-2.3 and I still having the same error. PKG_CONFIG_PATH only affects where stuff looks as it gets compiled. Also, you'd want to use PKG_CONFIG_PATH=/opt/gimp/lib/pkgconfig:$PKG_CONFIG_PATH, to keep the old stuff in there (assuming it's non-empty). IIRC, you'd want to set $LD_LIBRARY_PATH=/opt/gimp/lib/ for runtime. Interesting. In fact, I didn't recompile GIMP, I only did a export LD_LIBRARY_PATH=/opt/gimp/lib:$LD_LIBRARY_PATH and the zoom preview worked! :) However, I am getting many errors. One of them is due to the fact that I don't know how to retrieve the origin of the preview. For non-zoom previews, the funcion 'gimp_preview_get_position' gives you the origin. I wasn't able to find the correspoding one for zoom_preview (gimp_zoom_preview_get_position does not exist?!). Another one is that I don't know which is the equivalent to 'gimp_drawable_preview_draw_region' for zoom_preview. Thanks for the help, and the prompt answers!!! Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preview window does not work
My plugin is working fine, after I found my bug and the one in the blur example. It's just annoying. Then please explain the bug in the example code and send us a patch (preferably against SVN) that we can apply so that others won't run into the problem again. http://svn.gnome.org/viewcvs/gimp-web-devel/trunk/writing-a-plug-in/ Unfortunately, the code has more that one bug, or the correction I made didn't solve the issue completely. Using your last code in http://svn.gnome.org/viewcvs/gimp-web-devel/trunk/writing-a-plug-in/3/myblur5.c?revision=207 (that still shows the shift), I did an experiment. First, I made a symmetric image with a set of lines: http://w3.impa.br/~luis/fotos/lixo/grid.jpg and then blurred it with the code and radius=20. I got this: http://w3.impa.br/~luis/fotos/lixo/grid_blurred.jpg You can see three problems: 1) The old 1-pixel-down shift. 2) The two dark bands (20 lines each) at top and bottom of the image. 3) Even much intriguing is the grey band right below the top one, also of 20 lines! And it is homogeneous (no likes inside)... My 'solution' (change 'x1, y1,' in line 241 by 'x1, y1+1,') took care of the shift, but not of the banding. The homogeneous grey band just moved to the bottom... (you cannot imagine the mess this does in my code!) I think that the problem is that this shuffle function is implemented without taking into account the drawable height. Now: Could anyone please show me a SIMPLE code where the tile handling is properly implemented, without bugs? I mean, the same blurring plugin would be just perfect, but without bugs... From this buggy example, I just don't understand how they work, so I am not able to find the bug. You should realize that this is all just volunteers effort. Someone wrote this tutorial years ago and another volunteer added it to the gimp-developer web site. It will take another volunteer to improve it and to fix the example code. And yet even more volunteers will have to show up in the future to keep the tutorial uptodate. Of course I understand this. We are all volunteers. This was not the point. Anyway, thank you for your time, Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preview window does not work
* El 08/03/07 a las 1:57, [EMAIL PROTECTED] chamullaba: In general just try to keep cool. You are perfectly right in complaining about being lead astray by a bad code example and in your place I would be equally pissed off about the time I had wasted. I'm sure dismissive comments don't to much to releave the frustration either. Hopefully your comments will lead to some corrections being made. This was not the problem: I didn't complain about bugs, I looked for an answer to a bug in my code that I finally found. I didn't want to send any bug report for such a thing. What pissed me off was that I was requested to send a bug report, and when I sent it, the same guy answered that it was ok the code to have bugs since it was for demo purposes only! BTW, I believe that this is one of the main reasons why Fedora is weakening fast: unattended bugs that are leading to an OS so full of bugs that people are simply abandoning it. That is sad, and certainly not good for Linux. Dont worry too much about the LibGimp-CRITICAL message. I am getting that as well, you are running a development version, presumably current svn, expect some errors and messages. My plugin is working fine, after I found my bug and the one in the blur example. It's just annoying. Thanks, Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] preview window does not work
Pals, I made my first plugin in C for gimp, based on the one here: http://developer.gimp.org/writing-a-plug-in/3/index.html Unfortunately, this plugin has several bugs, that translated to my own, and I am not being able to detect them (is there any other source like the avove to get some base plugin to work on?) Sorry for the not very objetive question: The preview window updates when I change the parameters, but only in the top-left corner, where the preview appears. In the rest, it updates with some previous data, or some garbage. When I run the plugin for the second time, it is ok. That is, there is some buffer that is not being freed... Should I clean the region after a gimp_pixel_rgn_init call? Sometimes this also occurs on the main window. Thanks, Luis ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
