Hello,
I installed Gimp 1.04 with NetFu and it works great. But I didn't manage
to work Gimp 1.2.0 with Net-Fu.
Is it possible to run Net-Fu with Gimp 1.2.x ?
Nicolay Mausz
On Tue, Dec 05, 2000 at 08:54:44PM +0100, "Thomas S. Iversen" <[EMAIL PROTECTED]>
wrote:
> ... and on a related note, I can't seem
> to get Gimp->file_png_save($img,-1,) to work
> or file_gif_save()
maybe because -1 is not a valid drawable. Use a layer here (e.g.
"($img->layers
On Tue, Dec 05, 2000 at 08:54:44PM +0100, "Thomas S. Iversen" <[EMAIL PROTECTED]>
wrote:
> I have converted a script-fu script to perl-fu, but are having some
> problems. While I get nearly the same pictures, the original have
> transparency around the button while my
Hello there
I have converted a script-fu script to perl-fu, but are having some
problems. While I get nearly the same pictures, the original have
transparency around the button while my perlified version doesn't.
I thought it could have something to do with the save routine
In the ori
pt, which makes me think that this
thread should be titled "perl-fu problem". The fact that the splash
says script-fu when gimp hangs most probably means nothing but the
fact that the script-fu extension has been properly started, but
gimp hangs during initialization of the first plug-in,
On Wednesday, 25 Oct 2000, Jeff Sheffield wrote:
> the splash screen hangs with the subtitle
> Plug-ins
> and the path
> /opt/gimp/gimp-1.1.28/lib/gimp/1.1/plug-ins/script-fu
>
> another interesting thing that happens is.
> when I ctrl-C the app I get the fol
th the subtitle
Plug-ins
and the path
/opt/gimp/gimp-1.1.28/lib/gimp/1.1/plug-ins/script-fu
another interesting thing that happens is.
when I ctrl-C the app I get the following strange output
-
[jsheffie@kelly bin]$ ./gimp
^[[A./gimp terminated: Interrupt
/opt/gimp/gimp-1.1.28/l
On Tue, Oct 24, 2000 at 07:07:27PM -0500, thus said Jeff Sheffield:
> Ok i have Linux Mandrake 7.1
>
> I build the gimp 1.1.28
> everything built and made fine
> when I start running the program
> the status screen comes up and starts loading
> it hangs while trying t
Ok i have Linux Mandrake 7.1
I build the gimp 1.1.28
everything built and made fine
when I start running the program
the status screen comes up and starts loading
it hangs while trying to load the "script-fu"
stuff. nothing goes to STRERR
i also downloaded (last night) the c
> old-photo return the newly created layer/image/whatever, but AFAIK
> script-fu is unable to return anything to the caller (scirpt-fu was never
> designed to be called from the outside, obviously).
This would be better, but it still doesn't account for what I see happen -
which is t
to bear this
> out. Again, I could be misinterpreting the results, though I'm fairly
> certain I'm not.
You must, since if this were true we could expect a lot more breakage, but to
the contrary it's only script-fu. Also, the API for plug-ins looks like this:
function r
y, as you,
> Marc and presumably others expect.
This is the current state: remember that it is only script-fu that makes
problems, and script-fu could *never* be called properly form other
plug-ins, so I guess the problem really is script-fu. Especially since all
other plug-ins work fine
On Sunday, 10 Sep 2000, Michael J. Hammel wrote:
> Thus spoke Marc Lehmann
> > Not in the current architecture. The caller is blocked until the called
> > plug-in has finished.
>
> That would be the preferred design, but my tests don't seem to bear this
> out. Again, I could be misinterpreting
Thus spoke Marc Lehmann
> Not in the current architecture. The caller is blocked until the called
> plug-in has finished.
That would be the preferred design, but my tests don't seem to bear this
out. Again, I could be misinterpreting the results, though I'm fairly
certain I'm not.
> However, ar
On Sun, Sep 10, 2000 at 02:56:07PM -0500, "Michael J. Hammel"
<[EMAIL PROTECTED]> wrote:
> plug-ins from another plug-in. Since the plug-ins run as separate
> processes, the calling plug-in continues running after each call to another
> plug-in.
Not in the current architecture. The caller is bl
> Highly interesting indeed. Now, what gimp-perl does (when you pass in a
> drawable instead of both image and drawable) is this:
>
> if (sv_derived_from (sv, PKG_DRAWABLE))
> arg->data.d_image = gimp_drawable_image_id(unbless(sv, PKG_DRAWABLE,
>croak_str));
>
> i.e. it calls gimp
On Sun, Sep 10, 2000 at 01:23:31PM -0500, "Michael J. Hammel"
<[EMAIL PROTECTED]> wrote:
Hmm, a serialization issue is unlikely, since all the other plug-ins seem
to work, and script-fu never could be called reliably. If this, however,
is indeed the case than this change is pr
Thus spoke Marc Lehmann
> Thanks for the reply ;) I posted it to gimp-developer because i seems this
> is a generic gimp bug and hope somebody else can add more.
It does sound like a problem with how Script-Fu (and maybe plug-ins in
general) are serialized.
> > Looks like the i
the second one causes a change to the
> drawable id's for the image (which starts with a single layer when
> old_photo gets to it).
If the script-fu-drop-sahdow does change the darwable id (creates a new
one and deleted the old one) then your code is buggy: you simply mustn't
call gimp
ithout the quotes (those are supposed to
> be STRINGS according to the PDB)
Which shouldn't matter, either (all the same for perl).
> gets resized) but immediately after making a selection around the current
> layer Gimp crashes.
gimp or script-fu? script-fu could never be called via t
I'm trying to call the Drop Shadow filter from a Gimp Perl script. I've
tried it a number of different ways and it crashes each time. I think the
right format is:
$drawable->script_fu_drop_shadow("8", "8", "15", [0, 0, 0], "0", 1);
which should be exactly the same as using the defaults when yo
First, let me say thanks to all people who gave me feedback
and sent me bug reports the last days. This helps alot (and
keeps me on working ;-)
Now for the news:
I've just released Script-Fu "Burn-In" V1.9 for Gimp 1.0.X.
You can now use your own background-layer and create
f
layers on separate layers, but not to find the
function to write to a text file..
For the moment, this is a script fu, but I don't know scheme... So, I
would prefer C, but I didn't find any example of C plugin doing this kind
of stuff...
Any help would be welcom...
Mandor
[EMAIL PROTECTED]
Hi all,
I've done a script-fu in scheme, which works well in the
console, but
not so well when runing it.
The script is simply apply a (plug-in-gauss-rle 1 image drawable
5 1 1)
followed by (gimp-brightness-contrast image drawable -90 123) on an
animation.
S
On Wed, May 31, 2000 at 03:48:14PM +0530, Gunjan Kapoor <[EMAIL PROTECTED]> wrote:
> colour for the entire image. Is that possible with Perl-fu. e.g: specify
> white as the transparent colour.
What do you want to do? Do you want to replace white by transparency? This
is easy (not onl
Hi,
Could someone help me out with this. I need to specify a transparent
colour for the entire image. Is that possible with Perl-fu. e.g: specify
white as the transparent colour.
Additionally, I need to make the background transparent for a
programmatically generated image. The image contains
ubt it. But the usual order in directorirs comes close indeed.
This expalins why perl plug-ins were grouped together.
> more or less unpredictable, I have checked in some code today that orders
> the plug-ins and script-fu scripts alphabetically according to their
> translated menu-en
Hi,
myself wrote:
> I have however noticed that perl i18n is totally broken at the moment (at
> least on my box) and I couldn't figure out why. This was broken before my
> changes and I have double-checked that the gimp-perl text-domain gets
> passed to menus_create_item...() correctly. Later I
today that orders
the plug-ins and script-fu scripts alphabetically according to their
translated menu-entries.
I have however noticed that perl i18n is totally broken at the moment (at
least on my box) and I couldn't figure out why. This was broken before my
changes and I have double-chec
On Fri, May 05, 2000 at 01:22:48PM +0200, Sven Neumann <[EMAIL PROTECTED]>
wrote:
> entries? Sort them according to their original name (easy) or according
> to the translated one? I fear that the latter will be difficult and it
> would lead to different menu orders depending on what language y
not know wether gimp cares at all about menu-order (ot might be
that app/menus.c does something), I shouldn't comment anyway ;)
> > a seperate menu hierarchy hardly makes sense.
>
> The same arguments apply to Script-Fu as well, however there is still
> a separate menu hierarchy
Hi,
Raphael wrote:
> 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 see
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 err
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
>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 a
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
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
> BTW, the display of the cursor coordinates doesn't work well when using
> pixmap themes. With Theme Engines (including the default theme) it works
> OK. Does anybody knows what is the source of this problem and how to fix it?
Upgrading gtk-engines to version >= 0.10 should fix this problem.
S
Hi!
Not long ago I wrote a patch to expose the functionality of the gradient
editor to Script-Fu and Gimp::Fu scripts. The patch is available on my
homepage (URL below).
My question is if anybody commited this patch into the main development
gimp source. If not, one should do it, because I&#
(#7732). I will
> send a copy of the bug report to you by private e-mail.
I just changed it so it doesn't wrap at all.
[snip]
>
> Well, I still think that I understood the situation quite well. ;-)
> The difference between you and me is mostly a matter of opinion. I
> cons
gs in the scripts, but my message was not intended as
> > a bug report..
>
> I saw that, and I think this was very unfortunate :(
OK. I should have spent a bit more time to make a complete bug report
out of my message, instead of simply including the output from the
crashes as an example.
ur reasoning (which was based on "facts" which were
wrong), I came to the conclusion that you lack a good enough understanding of
the situation.
Even when we all know now your real intentions now, I don't see what not
telling you about my conclusions would have helped: You posted
On Mon, Mar 13, 2000 at 05:47:37PM +0100, Uwe Koloska <[EMAIL PROTECTED]>
wrote:
> What about making an extra package with all perl-modules required to run Gimp
Making packages is very much a distribution-only thing. So far, the most
what gimp does is support making a single source tarball, and
e the
GIMP disappears.
2. In script-fu (I'm wearing a white belt)
(gimp-layer-delete some-Layer)
(gimp-displays-flush)
evaluating these lines crashes the GIMP (1.1.18) immediately.
with regards.
FUJITA Yuji
[EMAIL PROTECTED]
http://www.wl.me.titech.ac.jp/~yuji/yuji-pubkey.asc
Dear developers.
I thank all of you for quick reply to my questions.
"fu" is from "kung-fu", which I never come to think of it. But now I
see very well that a master of "something-fu" can wear a black belt.
> http://film.gimp.org/
Thank you also for let me
Raphael Quinet said...
|
|On Tue, 14 Mar 2000, FUJITA Yuji <[EMAIL PROTECTED]> wrote:
|> 1. Does anyone know what "fu" is ?
|
|I think that it was a pun on "kung-fu". Not sure, though.
It was.
-Miles
On Tue, 14 Mar 2000, FUJITA Yuji <[EMAIL PROTECTED]> wrote:
> 1. Does anyone know what "fu" is ?
> I mean "script-fu", "perl-fu" or some kind of these names.
I think that it was a pun on "kung-fu". Not sure, though.
> 2. What is
Hi, dear developers.
I have two questions, maybe one of them is trifling.
1. Does anyone know what "fu" is ?
I mean "script-fu", "perl-fu" or some kind of these names.
2. What is the biggest barriar to support 16bit depth in the GIMP ?
I'm jus
Raphael wrote on Mon, 13 Mär 2000:
>
>As an end-user, I prefer a stable application that may have less
>features than another that has more features but that crashes or
>complains that my system is not correctly configured.
>
Hey, this is, why the most of us don't use Windoze, I think ;-)))
>Bac
use
> configure found out that one of them does not run on this system?
Please, read my message again. This is _not_ what I suggested and I
think that Sven and the others understood my message correctly.
Although an easy solution to the problems with Perl-Fu scripts could
be to disable all of t
Hi,
> I do not mind if some people (like Raphael) make suggestions based on a wrong
> understanding of the situation. I am, however, astonished that even people
> like Sven, who _does_ _know_ _better_ takes it so lightly:
>
> On Wed, Mar 08, 2000 at 06:29:18PM +0100, Sven Neumann <[EMAIL PROTECT
FWIW I agree with Raphael, installing "scripts" which actually just
blow up when run is pointless, if it can't at least manage to register
itself with Gimp's PDB we shouldn't install it.
Similarly, even if they did have "sensible defaults" the GUI scripts
are not functional enough to be installe
Marc Lehmann wrote:
>
> Disabling all perl-plug-ins because somebody didn't want to check the
> facts is, for me, a very big decision that should not be made lightly.
I would be pleased if there were a message after ./configure that
said...
Some errors occured during ./configure. If you woul
-ins because somebody didn't want to check the
facts is, for me, a very big decision that should not be made lightly.
On Wed, Mar 08, 2000 at 01:07:52PM +0100, Raphael Quinet <[EMAIL PROTECTED]> wrote:
> of all Perl-Fu scripts if any of the required modules (Gtk, PDL,
No script will
Hi,
> Why can't those scripts just _not_register_themselves_ if the required
> modules are not available? gimpmagick does this and the only problem
> is that it has to be re-probed every time the GIMP starts. The only
> reason I can think of to not install these scripts is to avoid the
> delay at
Raphael Quinet wrote:
> This has been suggested before, but I would like to bring it up
> again... I think that it would be better to disable the installation
> of all Perl-Fu scripts if any of the required modules (Gtk, PDL,
> Data::Dumper, Parse::RecDescent) are not detected by t
Hi,
> This has been suggested before, but I would like to bring it up
> again... I think that it would be better to disable the installation
> of all Perl-Fu scripts if any of the required modules (Gtk, PDL,
> Data::Dumper, Parse::RecDescent) are not detected by the configure
>
nding
on the network and server load) with a default installation of 1.1.18.
This is much too slow, but fortunately this is a one-time thing and
after that everything runs smoothly.
After the first run, the Gimp starts in about 10 seconds (5 of these
are taken by Script-Fu). If more scripts would b
On Wed, Mar 08, 2000 at 05:40:44PM +0100, Raphael Quinet wrote:
> On Wed, 8 Mar 2000, Seth Burgess <[EMAIL PROTECTED]> wrote:
> > As far as PDL and Gtk goes, I'm in agreement that it shouldn't
> > install those scripts with those dependencies uless those packages
> > are detected. gimptool should
On Wed, Mar 08, 2000 at 01:07:52PM +0100, Raphael Quinet wrote:
> This has been suggested before, but I would like to bring it up
> again... I think that it would be better to disable the installation
> of all Perl-Fu scripts if any of the required modules (Gtk, PDL,
> Data::D
On Wed, 8 Mar 2000, Seth Burgess <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 08, 2000 at 01:07:52PM +0100, Raphael Quinet wrote:
> > This has been suggested before, but I would like to bring it up
> > again... I think that it would be better to disable the installation
> >
This has been suggested before, but I would like to bring it up
again... I think that it would be better to disable the installation
of all Perl-Fu scripts if any of the required modules (Gtk, PDL,
Data::Dumper, Parse::RecDescent) are not detected by the configure
script or, more exactly, by
[This should go to [EMAIL PROTECTED], but this complained about
a missing Package-header. Can't the tracking System handle Mime-Mails?]
Package: gimp
Version: CVS from 19.2.2000
2 Python scripts fail to start with a nonstandard python installation
since the path to /usr/bin/python is hardcode
Sorry, busy ending exams, now processing postponed things:
> A3) Add a new parameter to the dialog box so that the color has to
> be specified explicitely.
>Almost everybody supports A3) so I will implement that.
Everybody + 1.
> B3) Add a "flatten image?" option to all scripts, defaults
On Thu, 17 Feb 2000, Sven Neumann wrote:
> The idea to have another menu entry is IMHO a good one and better then
> adding a new preferences option. But please do not use a script or
> another weird hack that changes the fg/bg for the fill, then restores
> it later. Better add a fill_type par
On Thursday, 17 Feb 2000, Raphael Quinet wrote:
> My 0.02 Euro: I would like to change the Edit->Fill behaviour globally
> and at the same time provide a three-lines script (or code in the
> core) that would register itself as "Edit->Fill with BG" and would
> swap the colors, call gimp-edit-fill
I received several replies to my opinion poll, by private e-mail or
on this list. Here is a summary of what I got so far:
About changing the scripts that call gimp-edit-fill without setting
the colors first (thus taking the current color in use):
A1) No change to the scripts (they would then u
> My 0.02 Euro: I would like to change the Edit->Fill behaviour globally
> and at the same time provide a three-lines script (or code in the
> core) that would register itself as "Edit->Fill with BG" and would
> swap the colors, call gimp-edit-fill and restore the colors again. So
> those who pre
On Wed, 16 Feb 2000, Glyph Lefkowitz <[EMAIL PROTECTED]> wrote:
> Why are you bothering to change this behavior (edit/fill) when it makes
> sense to 1/2 of the people who use GIMP, it's a historical precedent in
> terms of the UI, and it's a huge amount of work to get to function
> correctly? Are
> > Cleaning up the scripts and providing a more consistent set of parameters
> > looks like a very important job to me and I'm glad that Raphael wants to
> > take it. I'm not yet convinced that changing the Edit->Fill behaviour is
> > really useful. Probably we should keep the current behaviour a
On Wed, 16 Feb 2000, Sven Neumann wrote:
> Glyph Lefkowitz send this message privately, but I'd like to move
> the discussion back onto the list. I hope that OK with him...
Yep, it's fine with me...
[snip personal complaining]
> Cleaning up the scripts and providing a more consistent set of p
Glyph Lefkowitz send this message privately, but I'd like to move
the discussion back onto the list. I hope that OK with him...
> Why are you bothering to change this behavior (edit/fill) when it makes
> sense to 1/2 of the people who use GIMP, it's a historical precedent in
> terms of the UI, an
On Wed, 16 Feb 2000, Sven Neumann <[EMAIL PROTECTED]> wrote:
[...]
> > B2) Add a "flatten image?" option in all scripts, with the default
> > value set to TRUE.
> > B3) Add a "flatten image?" option in all scripts, with the default
> > value set to FALSE.
> > B4) Remove all calls to gimp-i
Raphael Quinet wrote:
>
> There are several ways to fix these scripts, and I would like to get
> your opinions about this:
>
>
> A3) Add a new parameter ("background color") to the script so that it
> uses the value specified in the dialog box instead of using the
> current colors.
>
who
> am I to decide what the default text should be? Each author has
> the right to decide what is best.
> C2) Change all logo scripts to use "The Gimp" as the default text (or
> only "GIMP" for those such as "Alien Glow" that look better in all
>
Yesterday evening, I started to edit the Script-Fu scripts so that
they fill with the foreground color instead of the background color.
There are 215 calls to gimp-edit-fill in the scripts delivered with
Gimp 1.1.17, and most of them are preceded by a call to
gimp-palette-set-background, which
I prepared a version of my Gradient-Fu patch that is compatible with
version 1.1.x of the GIMP. As a reminder, Gradient-Fu adds PDB procedures
that can manipulate gradients, so scripts and plug-ins can create and
modify gradients.
The patch can be downloaded from my homepage at the following
Is script-fu still maintained? Many people complain that script-fu can't
be called via the pdb (** WARNING **: unexpected proc return message
received (should not happen)).
This has been the case since 1.0. It worked for a very short time, but
most of the time it was broken in different
Parameters passed to gtk_init is not initialized and lead
to crash.
Related to gimp versions: 1.1.11, 1.1.12;
- ptr
diff -r gimp-1.1.12/plug-ins/script-fu/script-fu-scripts.c
gimp-1.1.12.old/plug-ins/script-fu/script-fu-scripts.c
1078a1079,1080
> gchar **argv;
> gin
On Fri, 22 Oct 99 19:33:20, Asbjoern Pettersen wrote:
>>
>>I 'cvs update'd again, recompiled, and everything works fine now. I can
>>even run plugins which use fonts! However, clicking twice on the font
>>button will still crash script-fu, although selecti
On Fri, 22 Oct 1999 12:14:29 -0400 (EDT), Glyph Lefkowitz wrote:
>You are correct.
>
>I 'cvs update'd again, recompiled, and everything works fine now. I can
>even run plugins which use fonts! However, clicking twice on the font
>button will still crash script-fu, alth
You are correct.
I 'cvs update'd again, recompiled, and everything works fine now. I can
even run plugins which use fonts! However, clicking twice on the font
button will still crash script-fu, although selecting a font and running
the script will not crash until the script i
ot;
>>
>> As of tonight's CVS update, ever single script-fu script is doing this
>> when I attempt to execute any of them.
>>
>
>You haven't correctly recompiled and installed the CVS version. Lots of PDB
>calls have changed and it seems you are running new sc
Hi,
>
> "ERROR: unbound variable (errobj gimp-image-undo-disable)
>
> If this happens while running a logo script,
> you might not have the font it wants installed on your system"
>
> As of tonight's CVS update, ever single script-fu script is doing thi
"ERROR: unbound variable (errobj gimp-image-undo-disable)
If this happens while running a logo script,
you might not have the font it wants installed on your system"
As of tonight's CVS update, ever single script-fu script is doing this
when I attempt to execute any of them.
Hi all,
I encountered some problems when I tried to update my script-fu script to
run on gimp 1.1.10.
In the former script I used "(gimp-convert-indexed image TRUE 256)" to
convert an image from rgb-mode to indexed. To do the same thing with gimp
1.1.10 I tried:
(gimp-convert-index
Hi all!
I discovered a strange behaviour of Script-Fu:
When I start GIMP from Bash, let script-fu render a logo (doesn't
matter which one) Script-fu segfault at his try to close the parameter
window of the script.
When I start it from enlightenment it manages to close the windo
87 matches
Mail list logo
