Re: pnm plugin
On Tue, May 02, 2000 at 06:04:41PM -0700, Kevin Turner [EMAIL PROTECTED] wrote: (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: Hmm... I just took some gif, converted to grayscale and saved it... the resulting file was a ppm. I'll look into this. In fact, any tool reading ppm will accept pgm or pbm as well, and automatically promote them. Definitely _not_. so this is, presumably, at least true for all the standard netpbm tools. Which comes very short of "any tool". ImageMagick for example will refuse to load a pgm image when you want to load a ppm file. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: 1.1.21 crashing trying to save a .jpg
On Wed, May 03, 2000 at 12:59:18AM -0500, Jon Winters wrote: Tonight I opened an image, did a re-size, then went to "save as" a .jpg. When I move the "Quality" slider Gimp crashes. :-\ What quality was this at? libjpeg is a bit unstable, especially when using non-baseline JPEGs at low quality :-) /* Steinar */
Re: 1.1.21 crashing trying to save a .jpg
On 03 May, 2000 - Steinar H. Gunderson sent me these 0.3K bytes:
On Wed, May 03, 2000 at 12:59:18AM -0500, Jon Winters wrote:
Tonight I opened an image, did a re-size, then went to "save as" a
.jpg. When I move the "Quality" slider Gimp crashes. :-\
What quality was this at? libjpeg is a bit unstable, especially when using
non-baseline JPEGs at low quality :-)
I think the preview thingie messes up the undo stack.. Haven't really
looked into it (been awaybusy) tho...
/Tomas
--
Tomas Ögren, [EMAIL PROTECTED], http://www.ing.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,ing,acc}.umu.se
Re: Perl-Fu plug-ins in 1.1.21
On Wed, 3 May 2000, Marc Lehmann [EMAIL PROTECTED] wrote:
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.
Well, for some reason it didn't, that's why I reported the bug.
I extracted gimp-1.1.21.tar.gz in a new directory and built everything
from there. Then I removed everything from the previous installation
of the Gimp in ${prefix}/lib/gimp and ${prefix}/share/gimp and I did a
"make install".
That's why I am surprised to get this problem: I double-checked that I
had no old files in the plug-ins directory before reporting this
strange bug. The only files that are in the plug-in-path came from a
fresh install of 1.1.21. I also re-did a "make" and "make install" in
the source tree to be sure that I was not dreaming. :-)
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 ;)
I could give you a username and password, but that would not help you
because the firewall blocks everything. :-) Even I cannot log in from
home. But if you want to come and say hello, I can give you my work
address and a roadmap of the area. ;-)
Err... Seriously, do you or anybody on this list have any idea of
what could be causing this strange problem? Can anyone report a
successful or unsuccessful installation of 1.1.21 with Perl enabled?
My setup is:
Solaris 2.6
perl5.005_03
PDL-2.003
Parse-RecDescent-1.70
Gtk-Perl-0.6123
glib-1.2.7
gtk+-1.2.7
gimp-1.1.21
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.
Unfortunately, this is not what happened. As I said, all the plug-ins
and scripts came from the new 1.1.21 package. I just checked a second
time by deleting my ~/.gimp-1.1/pluginrc and the Perl-Fu scripts
register again before the C plug-ins. This appears to be new,
although I do not know when this behavior was introduced because the
previous version (1.1.20) had another problem with the Perl-Fu scripts
and they crashed before registering.
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.
The same arguments apply to Script-Fu as well, however there is still
a separate menu hierarchy for these scripts. But maybe a separate
menu hierarchy is not the best solution...
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).
I don't know if it makes sense, but I would like to have some kind of
indication before 1.2 is released. I was hoping that some people on
this list could reply with good suggestions...
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...
I know, but the final release of 1.2 is just around the corner now and
several things have changed since the last time these things were
discussed.
Also, I have the feeling that many people (not you, of course) do not
care too much about the Perl-Fu scripts and do not even test them. I
am sure that I am not the only one who is worried about the overall
consistency of the user interface, but I am surprised by the lack of
comments about Perl-Fu... Where are the "many eyeballs" that ensure
that "all bugs are shallow"?
-Raphael
Re: 1.1.21 crashing trying to save a .jpg
On Wed, 3 May 2000, Steinar H. Gunderson wrote: On Wed, May 03, 2000 at 12:59:18AM -0500, Jon Winters wrote: Tonight I opened an image, did a re-size, then went to "save as" a .jpg. When I move the "Quality" slider Gimp crashes. :-\ What quality was this at? libjpeg is a bit unstable, especially when using non-baseline JPEGs at low quality :-) Hmmm... good question. The image was a picture of some Lucha Libre dudes. I don't know what the quality was set to. The slider popped up set to 75, I slid it over to 50 and when I released the mouse button gimp went POOF. I didn't think to test it with other images. I'll do this tonight when I get home. Thanks! -- Jon Winters http://www.obscurasite.com/ "Everybody loves the GIMP!" http://www.gimp.org/
Installing a pre-built pluginrc in the users' .gimp directory [patch]
I frequenty install the latest version of the Gimp on several
multi-user systems (Solaris and Linux). One thing that is frequently
reported by new users is that it takes a long time to start the Gimp
for the first time. I explain that it has to query all plug-ins once,
which is slow because of the heavily loaded NFS server and network,
but it is faster on subsequent runs.
This morning, I realized that it does not have to be that slow: a
pre-built pluginrc file could be installed each user's directory and
the first run will be much faster (the difference is not so big on a
single-user system, but it is significant when every executable has to
be fetched from the NFS server and run locally). Even if some
plug-ins are updated or removed later, the consistency checks that are
already done on the pluginrc should ensure that everything is OK.
Included below are two simple patches that could solve this problem.
The first one is an addition to the user_install script: if there is a
pluginrc file in the ${prefix}/share/gimp/1.1 directory, then copy it
to the user's private .gimp-1.1 directory. If no pluginrc file has
been installed there, then do nothing (some administrators may not
want to run the next step explained below). The installation dialog
already explains what the pluginrc file is used for, so there is
nothing to add there.
The second one is an addition to the Makefile (Makefile.am): a new
target "make install-pluginrc" can be used after "make install". It
will run the Gimp in batch mode and exit immediately, so that a
pluginrc file is created in the administrator's home directory. This
file is then copied into the gimpdatadir in the same way as the other
files.
I added a separate rule instead of extending the "make install" target
because some administrators may not want to start the Gimp from a
priviledged account. In this case, they can start it from another
account and copy the file manually, or simply ignore this step (which
is why the user_install script tests if the pluginrc file has been
created or not).
Does this make sense? If yes, then I could re-submit this patch to
ftp://ftp.gimp.org/incoming/, together with some updated instructions
in the INSTALL file.
-Raphael
--- user_install~ Wed Mar 15 00:18:04 2000
+++ user_installWed May 3 16:07:17 2000
@@ -22,6 +22,11 @@
echo "cp $1/gtkrc $2/gtkrc"
cp $1/gtkrc $2/gtkrc
+if test -r $1/pluginrc; then
+ echo "cp $1/pluginrc $2/pluginrc"
+ cp $1/pluginrc $2/pluginrc
+fi
+
echo "mkdir $2/brushes"
mkdir $2/brushes
echo "mkdir $2/generated_brushes"
--- Makefile.am~Mon Apr 24 20:55:08 2000
+++ Makefile.am Wed May 3 16:46:16 2000
@@ -145,6 +145,20 @@
uninstall-local:
rm -f $(DESTDIR)$(bindir)/gimp-config
+install-pluginrc:
+ @if test -x $(DESTDIR)$(bindir)/gimp; then \
+ echo " Starting gimp in batch mode to create/update pluginrc"; \
+ $(DESTDIR)$(bindir)/gimp --batch '(gimp-quit 0)'; \
+ p=pluginrc; \
+ file=$(HOME)/$(gimpdir)/$$p; \
+ if test -f $$file; then \
+ echo " $(INSTALL_DATA) $$file $(DESTDIR)$(gimpdatadir)/$$p"; \
+ $(INSTALL_DATA) $$file $(DESTDIR)$(gimpdatadir)/$$p; \
+ fi; \
+ else \
+ echo "Please run 'make install' first."; \
+ fi
+
.PHONY: files populate checkin release
files:
Re: 1.1.21 crashing trying to save a .jpg
On Wed, May 03, 2000 at 08:42:43AM -0500, Jon Winters wrote: I don't know what the quality was set to. The slider popped up set to 75, I slid it over to 50 and when I released the mouse button gimp went POOF. Well, then it isn't the libjpeg bug I saw when I was developing the preview, at least -- it usually kicks in on about .02 or .03 :-) Is this thing reproducible? With another image? /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/
