1.1.21 crashing trying to save a .jpg
I spoke too soon when I reported that 1.1.21 is workin' ok. Tonight I opened an image, did a re-size, then went to "save as" a .jpg. When I move the "Quality" slider Gimp crashes. :-\ Is it my system or the Gimp? Thanks -- Jon Winters http://www.obscurasite.com/jon/ "Everybody Loves The GIMP!" http://www.gimp.org/
Re: pnm plugin
On Wed, May 03, 2000 at 02:27:09AM +0200, Marc Lehmann wrote: > ppm saving works. But I am unable to create pgm or pbm files with the gimp > (pbm is known for some time, but gimp definitely writes a ppm file for > greyscale images). Nope, my routine Export tests for Gimp show PPM and PGMs being created as appropriate. You're right that Gimp won't generate PBMs, but I don't think it's an ideal tool for that job anyway. IMHO pnm.c would ideally notice if you said "foo.pgm" for an RGB image, and ask Export to recommend greyscale... but that's a lot of work for a very small gain. So I don't prioritize doing that. > However, saving a grayscale image resulted into a ppm file (with a pgm > suffix). Doesn't here. If you can't figure out what's wrong, try sending me (private mail is fine) an XCF which you think should produce a PGM, and I'll see what it does here. > I think the pnm plug-in should be able to save greyscale as pgm, I don't > care for pbm files. Does in my last check out of Gimp, probably a few days old but hardly out-of-date in PNM plug-in terms. Nick.
Re: pnm plugin
On Wed, May 03, 2000 at 02:27:09AM +0200, Marc Lehmann wrote: > ppm saving works. But I am unable to create pgm or pbm files with the gimp > (pbm is known for some time, but gimp definitely writes a ppm file for > greyscale images). that's not what "file" thinks about the attached files: pudding.pgm: PGM image text pudding2.pgm: PGM "rawbits" image data various "pgm*" tools accept them as well. Those were created from gimp 1.1.19, and lxr reports no substantial changes to plug-ins/common/pnm.c in the last month. > On Tue, May 02, 2000 at 02:55:46PM -0700, Kevin [...] wrote: > > In fact, any tool reading ppm will accept pgm or pbm as well, and > > automatically promote them. > > Definitely _not_. >From ppmtopgm(1): man> Note that although there is a pgmtoppm program, it is not necessary man> for simple conversions from pgm to ppm, because any ppm program can man> read pgm (and pbm) files automagically. so this is, presumably, at least true for all the standard netpbm tools. -- 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] pudding.pgm pudding2.pgm
Re: Perl-Fu plug-ins in 1.1.21
On Tue, May 02, 2000 at 08:15:44PM +0200, Raphael Quinet <[EMAIL PROTECTED]> wrote: > I tried to use the Perl-Fu scripts in 1.1.21 and I saw that all of > them abort with the following error displayed on the console: > > ** ERROR (recursed) **: could not find handler for message: 65536 > aborting... This happens to any plug-in that doesn't get recompiled when a protocol bump occurs. Recompiling the perl plug-in would fix that. > Marc, I suppose that you are aware of this and that you can fix it? If you give me a log-in on your machine I could fix it ;) > being mixed with the C plug-ins. Now it seems to be the contrary: the > Perl-Fu scripts are listed first in each menu, followed by the usual C > plug-ins. This is very distracting. Hmm... I wonder how the order in the menus is being worked out by the Gimp? Registration order? Alphabetical? Being able to control the sort order in some sensible way is highly desirable indeed, but will definitely not happen in 1.2 (IMHO it's very difficult). What happened in your case might have been that all the C-plug-ins (that were reinstalled) registered below the existing plug-ins and the perl-plug-ins (which you haven't reinstalled) moved to the top. > a menu is mapped to a C or Perl plug-in. They behave slightly > differently (e.g. undo is not always supported, there is a delay of a > couple of seconds before the plug-in starts) This describe the behaviour of a subclass of all perl scripts. _Some_ C plug-ins behave the same, btw, as well. If you look at earlier discussions of this and related points you'll see that a seperate menu hierarchy hardly makes sense. OTOH, I'd be all for some visible indication in the menus itself (although I am not 100% of wether that makes sense ;) It does not have any drawbacks, however). > for a vote or anything like that, but I would like to hear some > opinions... (no flames please) This has been discussed many times on this list already... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: pnm plugin
On Tue, May 02, 2000 at 02:55:46PM -0700, Kevin Turner <[EMAIL PROTECTED]> wrote: > B) I just tried it. It works fine. Even if you do want to consider it ppm saving works. But I am unable to create pgm or pbm files with the gimp (pbm is known for some time, but gimp definitely writes a ppm file for greyscale images). > In fact, any tool reading ppm will accept pgm or pbm as well, and > automatically promote them. Definitely _not_. > Another two seconds of testing shows that gimp does indeed accept pgm > and ppm as extensions when saving files. However, saving a grayscale image resulted into a ppm file (with a pgm suffix). I think the pnm plug-in should be able to save greyscale as pgm, I don't care for pbm files. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: pnm plugin
On Tue, May 02, 2000 at 01:47:29PM +0200, DrMartin.Weber wrote: > The pnm plugin can read the pnm, ppm, pbm and pgm format, but it cannot save to > ppm, pbm and pgm. Short version: -- A) It's not a bug. B) I just tried it. It works fine. Even if you do want to consider it a bug, it's just not there. (Unless someone broke the pnm filter between .19 and .21, which seems highly improbable). C) What are you smoking? =) Long version: - Here is my understanding of the pnmutils file formats: pbm == Portable BitMap (black and white) pgm == Portable GrayMap ppm == Portable PixMap (color) pnm == Portable aNy Map (any of the above) A pnm tool can take any of pbm, pgm, or ppm as input. In fact, any tool reading ppm will accept pgm or pbm as well, and automatically promote them. It may also be acceptable to use the name "pnm" for any file that contains pbm, pgm, or ppm data. (?) One would assume that a pnm tool's output would depend on the content, e.g. a GREYSCALE image would be saved as PGM, a RGB image would be saved as PPM. And in fact, about two seconds worth of testing with gimp 1.1.19 demonstrates that this is in fact how it works. Another two seconds of testing shows that gimp does indeed accept pgm and ppm as extensions when saving files. If you need to lower the bit depth, standard pnmutils include ppmquant: for reducing the number of colors, possibly converting a truecolor ppm into an indexed one ppmtopgm: color => gray pgmtopbm: gray => bitmap -- 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] Cold-hearted orb that rules the night Removes the colors from our sight Red is gray, and yellow white But we decide which is right And which is a quantization error. -- ppmtopgm(1)
Re: Perl-Fu plug-ins in 1.1.21
>While we are on it, could someone please check that all Perl scripts >register menu names with trailing dots if, and only if, they open a >dialog. Not a Perl script, but the About... menu entry shouldn't have the ellipsis, according to most GUI standards, since in this case opening a dialog is an end itself, not an intermediate step before the operation is performed.
Re: Perl-Fu plug-ins in 1.1.21
Hi, > But I also noticed that something else has changed in the Perl-Fu > scripts: in the previous versions that I tried (under Solaris), these > scripts were always registered at the bottom of the menus, instead of > being mixed with the C plug-ins. Now it seems to be the contrary: the > Perl-Fu scripts are listed first in each menu, followed by the usual C > plug-ins. This is very distracting. > > Would it be possible to avoid this? I would prefer to have the > Perl-Fu scripts separated from the C plug-ins. Either by adding a > separator in the menus, by adding a little mark next to their names, > or by creating a separate Perl-Fu menu similar to the Script-Fu menu. While we are on it, could someone please check that all Perl scripts register menu names with trailing dots if, and only if, they open a dialog. Salut, Sven
Re: successful install
On Tue, 2 May 2000, Jon Winters wrote: > > Just a quick note... I was able to install 1.1.21 without any problems. > Seems to be working nicely. I guess I should have mentioned... System: fresh redhat 6.2 Updates: glib, gtk+ and associated devels from helixcode I also updated a few perl modules when I installed 1.1.20. Thanks again and keep up the great work! Props to all gimp developers! -- Jon Winters http://www.obscurasite.com/ "Everybody loves the GIMP!" http://www.gimp.org/
successful install
Just a quick note... I was able to install 1.1.21 without any problems. Seems to be working nicely. Thanks! -- Jon Winters http://www.obscurasite.com/ "Everybody loves the GIMP!" http://www.gimp.org/
Perl-Fu plug-ins in 1.1.21
I tried to use the Perl-Fu scripts in 1.1.21 and I saw that all of them abort with the following error displayed on the console: ** ERROR (recursed) **: could not find handler for message: 65536 aborting... And this message is displayed in a pop-up box: [/path/to/script]: the gimp is using a newer version of the plug-in protocol than this plug-in. Marc, I suppose that you are aware of this and that you can fix it? I suppose that this was a consequence of the recent changes in the wire protocol. Hi Mitch! ;-) But I also noticed that something else has changed in the Perl-Fu scripts: in the previous versions that I tried (under Solaris), these scripts were always registered at the bottom of the menus, instead of being mixed with the C plug-ins. Now it seems to be the contrary: the Perl-Fu scripts are listed first in each menu, followed by the usual C plug-ins. This is very distracting. Would it be possible to avoid this? I would prefer to have the Perl-Fu scripts separated from the C plug-ins. Either by adding a separator in the menus, by adding a little mark next to their names, or by creating a separate Perl-Fu menu similar to the Script-Fu menu. I am asking for this on the list because I expect that many developers have different opinions about the placement of Perl-Fu scripts (or Python-Fu). I think that the Perl-Fu scripts "feel" different from the C plug-ins and it would be nice to know beforehand if an entry in a menu is mapped to a C or Perl plug-in. They behave slightly differently (e.g. undo is not always supported, there is a delay of a couple of seconds before the plug-in starts) and their parameters dialog have a different layout compared to most C plug-ins. I suppose that some of these differences (e.g. the Gimp-Perl logo in the dialogs) were introduced on purpose to make these scripts stand out from the others, but then why should they be mixed? I'm not asking for a vote or anything like that, but I would like to hear some opinions... (no flames please) -Raphael
Re: Gimp 1.1.21 build fails under Solaris because of Linuxisms
Raphael Quinet wrote: > > Oops! I forgot the second part of my patch. The problem with SA_NOMASK is > also present in app/main.c: Raphael, no need to oops... :) I'm about to commit this. It seems I made Gimp unworkable for all systems except Linux... argh, 1 day before a release. will be fixed in 5 minutes. --Mitch
Re: Gimp 1.1.21 build fails under Solaris because of Linuxisms
Oops! I forgot the second part of my patch. The problem with SA_NOMASK is also present in app/main.c: --- app/main.c~ Mon May 1 19:43:09 2000 +++ app/main.c Tue May 2 17:49:05 2000 @@ -334,15 +334,15 @@ /* Handle some signals */ - gimp_signal_private (SIGHUP, on_signal, SA_RESETHAND | SA_NOMASK); - gimp_signal_private (SIGINT, on_signal, SA_RESETHAND | SA_NOMASK); - gimp_signal_private (SIGQUIT, on_signal, SA_RESETHAND | SA_NOMASK); - gimp_signal_private (SIGABRT, on_signal, SA_RESETHAND | SA_NOMASK); - gimp_signal_private (SIGBUS, on_signal, SA_RESETHAND | SA_NOMASK); - gimp_signal_private (SIGSEGV, on_signal, SA_RESETHAND | SA_NOMASK); - gimp_signal_private (SIGPIPE, on_signal, SA_RESETHAND | SA_NOMASK); - gimp_signal_private (SIGTERM, on_signal, SA_RESETHAND | SA_NOMASK); - gimp_signal_private (SIGFPE, on_signal, SA_RESETHAND | SA_NOMASK); + gimp_signal_private (SIGHUP, on_signal, SA_RESETHAND | SA_NODEFER); + gimp_signal_private (SIGINT, on_signal, SA_RESETHAND | SA_NODEFER); + gimp_signal_private (SIGQUIT, on_signal, SA_RESETHAND | SA_NODEFER); + gimp_signal_private (SIGABRT, on_signal, SA_RESETHAND | SA_NODEFER); + gimp_signal_private (SIGBUS, on_signal, SA_RESETHAND | SA_NODEFER); + gimp_signal_private (SIGSEGV, on_signal, SA_RESETHAND | SA_NODEFER); + gimp_signal_private (SIGPIPE, on_signal, SA_RESETHAND | SA_NODEFER); + gimp_signal_private (SIGTERM, on_signal, SA_RESETHAND | SA_NODEFER); + gimp_signal_private (SIGFPE, on_signal, SA_RESETHAND | SA_NODEFER); #ifndef __EMX__ /* OS/2 may not support SA_NOCLDSTOP -GRO */
Re: Gimp now requires Glib 1.2.7?
On Tue, 2 May 2000, Pierre Rochefort <[EMAIL PROTECTED]> wrote: > I got the sources out of CVS and tried to compile. I have Glib 1.2.6 > installed and it used to work fine (up until this morning). Has the > requirement changed in regards to Glib? Yes. The current version of the Gimp requires glib-1.2.7 and gtk+-1.2.7. It is very likely that the final release will require gtk+-1.2.8 (not released yet) because some dnd bugs have been fixed recently in gtk. -Raphael
Gimp 1.1.21 build fails under Solaris because of Linuxisms
I just downloaded 1.1.21 and I tried to compile it under Solaris. The build breaks early while compiling libgimp, with the following error: gimp.c: In function `gimp_main': gimp.c:202: `SA_NOMASK' undeclared (first use in this function) gimp.c:202: (Each undeclared identifier is reported only once gimp.c:202: for each function it appears in.) make[2]: *** [gimp.lo] Error 1 make[2]: Leaving directory `/Local/build/gimp-1.1.21/libgimp' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/Local/build/gimp-1.1.21' make: *** [all-recursive-am] Error 2 Fortunately, I have access to a Linux box from which I could see what this mysterious SA_NOMASK was supposed to be. A comment in the file /usr/include/asm/signal.h says: [...] * SA_ONESHOT and SA_NOMASK are the historical Linux names for the Single * Unix names RESETHAND and NODEFER respectively. */ The file libgimp/gimp.c uses the correct SA_RESETHAND together with the obsolete SA_NOMASK instead of SA_NODEFER. Because of this, I suppose that it is impossible to compile the Gimp on any UNIX-like system except for Linux. The patch, appended below, is trivial: simply replace all occurences of SA_NOMASK with the correct symbol SA_NODEFER. This solves the problem under Solaris, at least. But maybe it would not be more appropriate to add some #ifdef HAVE_SA_xxx in the code, together with some extra tests in configure.in. Note: I am reporting this to the list because I am not sure if the Gnome bug tracker and Xach's bug report form are working or not. On Friday, I tried to report a bug (about drawing straight lines in different views of the same image) but I did not get the usual e-mail confirmation and my bug report was probably lost. Can anyone confirm that the form and the bug tracker are working? -Raphael - --- libgimp/gimp.c~ Mon May 1 19:43:17 2000 +++ libgimp/gimp.c Tue May 2 17:14:12 2000 @@ -199,21 +199,21 @@ * has been built with MSVC, and the user has MSVC installed. */ gimp_signal_private (SIGHUP, gimp_plugin_signalhandler, - SA_RESETHAND | SA_NOMASK); + SA_RESETHAND | SA_NODEFER); gimp_signal_private (SIGINT, gimp_plugin_signalhandler, - SA_RESETHAND | SA_NOMASK); + SA_RESETHAND | SA_NODEFER); gimp_signal_private (SIGQUIT, gimp_plugin_signalhandler, - SA_RESETHAND | SA_NOMASK); + SA_RESETHAND | SA_NODEFER); gimp_signal_private (SIGBUS, gimp_plugin_signalhandler, - SA_RESETHAND | SA_NOMASK); + SA_RESETHAND | SA_NODEFER); gimp_signal_private (SIGSEGV, gimp_plugin_signalhandler, - SA_RESETHAND | SA_NOMASK); + SA_RESETHAND | SA_NODEFER); gimp_signal_private (SIGPIPE, gimp_plugin_signalhandler, - SA_RESETHAND | SA_NOMASK); + SA_RESETHAND | SA_NODEFER); gimp_signal_private (SIGTERM, gimp_plugin_signalhandler, - SA_RESETHAND | SA_NOMASK); + SA_RESETHAND | SA_NODEFER); gimp_signal_private (SIGFPE, gimp_plugin_signalhandler, - SA_RESETHAND | SA_NOMASK); + SA_RESETHAND | SA_NODEFER); #endif #ifndef G_OS_WIN32
Gimp now requires Glib 1.2.7?
Hello all! I got the sources out of CVS and tried to compile. I have Glib 1.2.6 installed and it used to work fine (up until this morning). Has the requirement changed in regards to Glib? Thanks. Pierre = It said "Needs Windows 95 or better". So I installed Linux... =
location of glibconfig.h, why?
why does glibconfig.h go in $prefix/lib/glib/include while glib.h goes in $prefix/include? gimp dont seem to know where it is. i ran into this after deleting the gtk slackware packages and reinstalling. glib-config --cflags works fine, but ./configure on the gimp tree does not. (it fails while building) __ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/
