Perl Server question
I had sent the following mail to gimp user mailing list HI!!! I have been using perl for scripting and gimp 1.1.04, with no problems. Recently I upgraded Gimp to ver 1.1.29 and all my perl-gimp programs went for a toss,I am lost as no errors are thrown at me.(Starting gimp or running perl script) I suspect, perl server which comes along with gimp is the problem because in gimp 1.1.4, there is a option "perl server" in the drop down menu of "xtns" (on gimp main tool bar) but the same is absent in gimp 1.1.29. I would like to know if this (perl server) option should still showup in the dropdown menu of gimp 1.1.29? if yes what should I do. Thanks for patience Chetan
Re: revert/undo/question?
[EMAIL PROTECTED] (2000-11-10 at 1243.23 +0100): However exactly the same happened to me, which meant loss of half an hour of work. I'll add a warning dialog just as the "chanes were made to %s. really close?" one. Yes, it should ask if undoable "Reverting 'imagename' will lose all Sorry, I meant "non undoable". changes including undo stack" "Revert" "Cancel" (two lines + two buttons, the important part is the buttons labels). This is clearly a cool idea but it's also clearly a fat feature :( [...] Maybe a good idea for 1.3... The undoable (without question then ;] ) revert would be cool indeed. Until it can be coded, I would like it to ask (that is easy coding, no?) and the docs show that is not undoable in this version, but maybe in next (aka check next version with a dummy image), and that opening another instance of the same image is a good solution too (cos you can save the first try or the second). GSR
Re: revert/undo/question?
[EMAIL PROTECTED] (2000-11-09 at 1830.06 +0100): I just found out the hard way that File-Revert is not undoable (I slipped with the pen). Shouldn't that be either undoable OR an action that the user had to acknowledge? Yes, one of those two. I would like undo, see below. I think "revert" should really revert everything, including clearing the undo stack, just if you had just opened the file. Then I would close and open the image, which is one step more (but easy most of times, ctrl+w, go to last recent used list and reload), cos I am sure what will happen, or load the file again and work on it (closing the doubtful version when I am sure about the new one). I would like, if possible (code freeze, etc), to be undoable, otherwise it is a menu entry that you can do quickly with (two) keycombos. However exactly the same happened to me, which meant loss of half an hour of work. I'll add a warning dialog just as the "chanes were made to %s. really close?" one. Yes, it should ask if undoable "Reverting 'imagename' will lose all changes including undo stack" "Revert" "Cancel" (two lines + two buttons, the important part is the buttons labels). GSR
Re: Widget display problems and a question...
On Tue, Oct 10, 2000 at 07:52:10AM +, thus said Brendan Byrd/SineSwiper: After using ldd on gimp and realizing that steps #1-8 were useless (though somewhat informative for the GTK installation procedure), I looked for an updated BlueSteel at gtk.themes.org. Nope. I've tried a few other themes that I already have and found that the following have that bug: BlueSteel, Marble3D, Pixmap. Others like Cheese and Stone surprised me because they didn't have the bug, yet they had a pixmap for the buttons/background. The Cheese theme is not using the pixmap _engine_ that is causing the problem to appear. It is just having a background pixmap for the real widgets, not replacing everything with pixmaps. There is the "light" version of BlueSteel that doesnt use pixmaps but just colors, try that instead. Pixmap themes are also very slow and eat more memory. Tuomas -- .--- [EMAIL PROTECTED] .|\,/| [EMAIL PROTECTED] -. + www.helixcode.com - ()-@@ , tigert.gimp.org + `- art director , `--')/ a gimp artist ---'
Re: Widget display problems and a question...
All this searching of linking and such is silly; this is a well-known bug in the pixmap-engine theme system, which is a dynamically loaded object that won't show up in "ldd". Look for old copies of libpixmap.so. This bug is very old; see http://www.mail-archive.com/gimp-developer%40scam.xcf.berkeley.edu/msg01619.html and http://www.mail-archive.com/gimp-developer%40scam.xcf.berkeley.edu/msg02239.html and http://www.mail-archive.com/gimp-developer%40scam.xcf.berkeley.edu/msg01430.html. You don't see the bug with the themes you mentioned because they don't use the pixmap-engine system. You're probably getting a confusion of replies since many developers are boring people who don't use beautiful themes to make their widgets look weird and therefore never saw this problem initially...:) Zach -- [EMAIL PROTECTED] Zachary Beane http://www.xach.com/
Re: silly display programming question
On Wed, Sep 06, 2000 at 06:18:38AM -0700, pixel fairy wrote: ive been using opengl for most graphics stuff, but now i want to write a simple app (gui for scarse, a scanner calibrater) and i think opengl is overkill here. whats the simplest method of displaying an image with some interface elements over it, in this case a loaded tiff (probably using tifflib) with lines (of inverse color perhaps) that can be moved. Use gtk and gdk-pixbuf. Gtk is an X (or Win32, or BeOS) toolkit, and gdk-pixbuf is a GNOME library (though it theoretically doesn't depend on GNOME) to load arbitary image formats. Ian
silly display programming question
ive been using opengl for most graphics stuff, but now i want to write a simple app (gui for scarse, a scanner calibrater) and i think opengl is overkill here. whats the simplest method of displaying an image with some interface elements over it, in this case a loaded tiff (probably using tifflib) with lines (of inverse color perhaps) that can be moved.
Re: perl script question
On Wed, Aug 30, 2000 at 05:16:48PM -0500, Michael J. Hammel wrote: Is there a way to open an image in Gimp Perl and run filters on it without opening a Canvas window? IIRC, you don't get a canvas window when you call image_new unless you deliberately create a new display (that's a seperate procedure). Note that I'm working from memory of general PDB workings as of two years ago and not because I've actually done this with perl, so you might want to gather some real evidence. ;) -- Kevin Turner [EMAIL PROTECTED] | OpenPGP encryption welcome here Plug-ins: They make GIMP do stuff. http://gimp-plug-ins.sourceforge.net/ This list is archived at http://marc.theaimsgroup.com/?l=gimp-developer To unsubscribe, mail [EMAIL PROTECTED]
Stupid Question : )
Hi Guys, I've got a GIMP precompiled binary tarball that is supposed to be installed in /opt Because I do not have root access to my machine I've installed it in /space/opt. Naturally it does not seem to work properly (can't find brushes and plugins etc). Is there anyway to modify post-install the prefix directory that gimp looks for scripts plugins etc... Thanks Anton -- Anton Enright - PhD. Student - Computational Genomics Group EMBL - European Bioinformatics Institute, Hinxton, Cambridge Phone :0044-1223-494452 Fax:0044-1223-494468 E-Mail: [EMAIL PROTECTED] Web: http://www.ebi.ac.uk/~enright/
Re: Stupid Question : )
Anton Enright wrote: I've got a GIMP precompiled binary tarball that is supposed to be installed in /opt Because I do not have root access to my machine I've installed it in /space/opt. [snip] Is there anyway to modify post-install the prefix directory that gimp looks for scripts plugins etc... Check for paths in the 'gimprc' file under the directory where you installed GIMP plus in the users area under the .gimp-1.1 directory. In the main gimprc file there is a path called 'prefix' which is the main one you need to modify. Changing the path should help but I do not guarantee that this will make it fully operational but its worth a shot. Alternatively, you could grab the source and compile it yourself. This would allow you to specify any install path you liked.
Re: Stupid Question : )
On Thu, Aug 03, 2000 at 10:41:03AM -0400, Kevin Cozens wrote: Anton Enright wrote: I've got a GIMP precompiled binary tarball that is supposed to be installed in /opt Because I do not have root access to my machine I've installed it in /space/opt. [snip] Is there anyway to modify post-install the prefix directory that gimp looks for scripts plugins etc... Check for paths in the 'gimprc' file under the directory where you installed GIMP plus in the users area under the .gimp-1.1 directory. In the main gimprc file there is a path called 'prefix' which is the main one you need to modify. Changing the path should help but I do not guarantee that this will make it fully operational but its worth a shot. Alternatively, you could grab the source and compile it yourself. This would allow you to specify any install path you liked. A handful of symlinks would probably fix it, too :) Tom -- -- Tom Rathborne [EMAIL PROTECTED] http://www.aceldama.com/~tomr/ -- "We promise according to our hopes, and perform according to our fears." -- -- Francois, Duc de la Rochefoucauld
question
Bonjour, quelcun pourrat il me dire comment faire pour lancer un script-fu en mode console, sans avoir a lancer ni le serveur X ni Gimp lui meme? sachant que beaucoup de scripts sont à lancer en meme temps. Merci. Hello, is there any one to say me how to make to launch a script-fu in text-mode, without having to launch neither the server X or Gimp? knowing that many scripts are to be launched in same time. Thank you. ___ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr
Re: Question about XCF format
From: Tor Lillqvist [EMAIL PROTECTED] Date: Sun, 30 Apr 2000 23:02:43 +0300 (FLE Daylight Time) I got now several emails from users with the wish to add XCF reading support in my viewer. I don't know if that is a good idea. XCF is really the GIMP's own private format for saving images between editing sessions, it is not intended for interoperability with other applications. Or what do you folks on gimp-developer think? The last thing the world needs is more undocumented, proprietary file formats. I realize that "proprietary" has a subtly different meaning from the closed source world, but it's the same idea. It does nobody any good if the file can't be read without firing up the Gimp.
Re: Question about XCF format
Date: Sun, 30 Apr 2000 23:21:35 +0200 From: Marc Lehmann [EMAIL PROTECTED] And, in the future, when the format *might* (or might not...) be extended so it is easily mmapable (large images) or aquires other similar features, the idea of "reading/writing xcf images form outside the gimp" might become totally unfeasible. Why? If the format's specified well enough, why shouldn't it be possible for it to be accessed? -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: Question about XCF format
On Sun, Apr 30, 2000 at 05:39:45PM -0400, Robert L Krawitz [EMAIL PROTECTED] wrote: the idea of "reading/writing xcf images form outside the gimp" might become totally unfeasible. Why? If the format's specified well enough the format is and will always be specified well enough.. why shouldn't it be possible for it to be accessed? Because it's senseless in most cases. If, on the other hand, the need arises anybody can add read (or write) support to his program(s). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Simple question about plug-ins
Hello all, I have a very simple question about some plug-ins. Why are some not included (as part of CVS or otherwise)? (The one that comes to mind is Guash). Is it because they are seen as unstable? I really like some of them and I have had no problem with then so far (Although that may change at one point ;-) Thanks for any info anyone can provide. Pierre P.S.: As usual, if this should not be on this list, do not hesitate to reply directly to me.
Question about make release
Hello all! I started building Gimp using the CVS repository a little while back (2-3 months). Just recently, I tried to build all the target specified in the Makefile. I tried the "make release" but it stops after a while looking for a program db2html. Does anybody know where I can find this? Thanks. Pierre P.S.: If it's a silly question, you can reply directly to me ;-)
stupid question and suggestion
Through some mechanism I have managed to set up my tool box to fill my whole screen. I'd like to back to the simple set of tools that occupy the right hand corner of my screen (approximately). This is very embarassing to someone who make biologicial drawing with the sphere brush and can actually write albeit flkaeely in scheme. Any suggestions would bne most helpful there is something simmple I must have over looked. I tried looking theu all turotitals and the like and have failed to find the fix. I have one bizarre suggestions and that is the lowly and forgotten flow chart. I find when I draw or do stuff in gimp, that silly as it seems that all my art tecniques work well if I flow chart them and I seldom forget a design trick I learned on was told. Is this something gneral or is it just me?? Have Fun, Sends Steve [EMAIL PROTECTED]
Re: stupid question and suggestion
On Sun, Jan 09, 2000 at 06:08:32AM -0800, Steve Kudlak [EMAIL PROTECTED] wrote: Through some mechanism I have managed to set up my tool box to fill my whole screen. I'd like to back to the simple set of tools that occupy brush and can actually write albeit flkaeely in scheme. Any suggestions would bne most helpful there is something Why don't you just make it smaller again? There should be nothing to prevent you... well... maybe if you window-manager is unfrtiendly enough, then you can try to: rm .gimp*/sessionrc -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: please...Answer me this question.
Ian Boreham said... | |The Wilberworks FAQ (http://www.wilberworks.com/faq.html) claims that its |name is Wilber, but that it is a Gimp. Unfortunately this does not clear up |its taxonomy in relation to canines and rodents. Since it's neither canine nor rodent (though rumors persist that it is both), but a Gimp, I think it clears it up nicely. -Miles, neither rodent nor canine his own self
Re: please...Answer me this question.
On Mon, Dec 20, 1999 at 05:45:57PM -0800, Won Ju Hee [EMAIL PROTECTED] wrote: Which GIMP's logo is fox or mouse. I think it is a Wilber ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: please...Answer me this question.
At 09:12 21/12/99 +0100, Marc Lehmann [EMAIL PROTECTED] wrote: On Mon, Dec 20, 1999 at 05:45:57PM -0800, Won Ju Hee [EMAIL PROTECTED] wrote: Which GIMP's logo is fox or mouse. I think it is a Wilber ;) The Wilberworks FAQ (http://www.wilberworks.com/faq.html) claims that its name is Wilber, but that it is a Gimp. Unfortunately this does not clear up its taxonomy in relation to canines and rodents. Ian
libgimpui dcgettext, a linker question
I just got a bug report that contained this: /usr/local/lib/libgimpui.so: undefined reference to `dcgettext__' Can a makefile guru tell me wether this is a bug with i18n on the target system, or ist libgimpui just not linked against -lintl (as it should)? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: libgimpui dcgettext, a linker question
On Sun, Nov 21, 1999 at 09:55:10PM +0100, Marc Lehmann wrote: /usr/local/lib/libgimpui.so: undefined reference to `dcgettext__' Can a makefile guru tell me wether this is a bug with i18n on the target system, or ist libgimpui just not linked against -lintl (as it should)? To fill you inn, Marc, I used --with-included-gettext. Doesn't that mean the gettext on the local system _shouldn't_ be used? (I use glibc 2.1.2, in case you need it.) /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/
Re: libgimpui dcgettext, a linker question
On Sun, Nov 21, 1999 at 09:47:56PM +, "Steinar H. Gunderson" [EMAIL PROTECTED] wrote: On Sun, Nov 21, 1999 at 09:55:10PM +0100, Marc Lehmann wrote: /usr/local/lib/libgimpui.so: undefined reference to `dcgettext__' Can a makefile guru tell me wether this is a bug with i18n on the target system, or ist libgimpui just not linked against -lintl (as it should)? To fill you inn, Marc, I used --with-included-gettext. Doesn't that mean the gettext on the local system _shouldn't_ be used? (I use glibc 2.1.2, in case you need it.) The reason I wondered about this part of the problem is that libgimpui should ot have unsatisfied external references. It is a common bug (gtk-enginges for example suffered from this) to NOT link shared libraries against any other libraries, i.e. gtk-enginges was not linked against gtk+, relying on the "fact" that the main application would eventually link against it. Maybe this is similar for libgimpui (maybe not ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: libgimpui dcgettext, a linker question
libintl is only distributed as a static library. You can't portably link static libraries into shared libraries. Isn't --with-included-gettext pretty useless (and very dangerous) then? At the very least we should --disable-shared when a user selects that option. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Gimp-Perl and Server Question
On Mon, Nov 15, 1999 at 03:29:39PM -0700, Greg Walters [EMAIL PROTECTED] wrote: How do you delete the image? I *know* that $image-delete sufficed to delete an image totally, but this was some months ago. That is what I essentially did using the gimp_image_new() and gimp_image_delete() subroutines. (ps: gimp-1.0 has various but rather small memory leaks so after millions of operations your perl-server and the gimp will grow by a few megabytes. This does not affect image deletion, however). This must be what I am seeing (as we are running gimp-1.0.4). I don't think so, as you would not see superflous layers! you must be hitting something larger. It *might* be possible that you would have to delete all layers first in 1.0 (but I can't really remember ;) in a cron (weekly or so) to kill Gimp and the Perl server and then restart them just to keep things under control. ... which is a sensible thing to do anyway. gimp was not really tested under this kind of conditions (not being a mere library). And, while I plugged all the memleaks I found in 1.0, 1.2 might just introduce new ones ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Gimp-Perl and Server Question
After a little testing, using my button creator, I did notice that The Gimp's memory usage did increase after each execution. I found during testing that if I temporarily displayed the new image and then deleted it that the Layers Channels Image list did not retain the image created. However, this did not stop the memory grabbing. I can't answer your main question, but I'd like to comment on the fact the LC dialogs image preview shows all images regardless if they have a display or not. This can be quite useful for debugging sometimes, but I think this behaviour should be changed. Do you agree?? Salut, Sven
Re: Gimp-Perl and Server Question
After a little testing, using my button creator, I did notice that The Gimp's memory usage did increase after each execution. I found during testing that if I temporarily displayed the new image and then deleted it that the Layers Channels Image list did not retain the image created. However, this did not stop the memory grabbing. I can't answer your main question, but I'd like to comment on the fact the LC dialogs image preview shows all images regardless if they have a display or not. This can be quite useful for debugging sometimes, but I think this behaviour should be changed. Do you agree?? Default behaviour, OK, always no. I want to know why Gimp eat RAM when testing scripts, and which name I should use to recover that RAM. Go to Script-Fu console and delete by hand the offenders. GSR
Re: Gimp-Perl and Server Question
On Mon, Nov 15, 1999 at 09:20:22AM -0700, Greg Walters [EMAIL PROTECTED] wrote: During the testing of my programs I noticed that the Layers Channels palette had every image created still listed in the Image: pull-down list. This got me to thinking, is this information being kept around even though the image is long gone? If so, does that mean the Gimp-Perl server's memory usage would grow in size? testing that if I temporarily displayed the new image and then deleted it that the Layers Channels Image list did not retain the image How do you delete the image? I *know* that $image-delete sufficed to delete an image totally, but this was some months ago. It is possible that some new bug was introduced, though. (ps: gimp-1.0 has various but rather small memory leaks so after millions of operations your perl-server and the gimp will grow by a few megabytes. This does not affect image deletion, however). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Gimp-Perl and Server Question
Sven Neumann wrote: After a little testing, using my button creator, I did notice that The Gimp's memory usage did increase after each execution. I found during testing that if I temporarily displayed the new image and then deleted it that the Layers Channels Image list did not retain the image created. However, this did not stop the memory grabbing. I can't answer your main question, but I'd like to comment on the fact the LC dialogs image preview shows all images regardless if they have a display or not. This can be quite useful for debugging sometimes, but I think this behaviour should be changed. Do you agree?? Yes, it was useful for debugging. I was able to see what the end result was and where I might have problems (layer creation and merging, etc.). Marc Lehmann wrote: How do you delete the image? I *know* that $image-delete sufficed to delete an image totally, but this was some months ago. That is what I essentially did using the gimp_image_new() and gimp_image_delete() subroutines. (ps: gimp-1.0 has various but rather small memory leaks so after millions of operations your perl-server and the gimp will grow by a few megabytes. This does not affect image deletion, however). This must be what I am seeing (as we are running gimp-1.0.4). We may put in a cron (weekly or so) to kill Gimp and the Perl server and then restart them just to keep things under control. Thanks for all your help. Greg Walters Webmaster Harrison School District
