Asyncron PDB->PDB calls ?

[wolfgang hofer]

Hi,

Is there a possibility for a PlugIn
to run other PlugIns asyncron?

2 of my Plugins (the GAP Video/Navigator and
the Animated Preview in GAP Video/Move Path)
are currently calling the PlugIn animationplay
 
 return_vals =
 gimp_run_procedure ("plug_in_animationplay",
&nreturn_vals,
GIMP_PDB_INT32,GIMP_RUN_NONINTERACTIVE,
GIMP_PDB_IMAGE,l_new_image_id,
GIMP_PDB_DRAWABLE, -1,  /* dummy */
GIMP_PDB_END);
   "plug_in_animationplay"

This blocks the GUI Dialog Windows,
until the animation play is closed
(by the user).
In that case It would make sense
to run the plug_in_animationplay
without waiting until finished.

If there is no way to do asyncron calls now
we should think about to add them,
for example with the names:

  gimp_run_async_procedure
  gimp_run_async_procedure2

with the same parameters like the already
existing syncron versions.
But SUCCESS is returned immediate
after the requested plugin could be started.
gimp_run_async_procedure* does not
wait until the requested plugin has finished.


Note:
 I once tried to do a workaround
 by forking a playback process
 to call the plug_in_animationplay
 but this does not work !
 (when the animationplay terminates,
 the calling Plugin dies, 
 maybe when trying to call
 any gimp core function, while
 gimp thinks the plugin has already
 terminated)


Yours Wolfgang Hofer, <[EMAIL PROTECTED]>
(Author of GAP)



Get FREE Email/Voicemail with 15MB at Lycos Communications at http://comm.lycos.com

Re: Asyncron PDB->PDB calls ?

[Marc Lehmann]

On Fri, Nov 17, 2000 at 09:01:09AM +0100, wolfgang hofer <[EMAIL PROTECTED]> 
wrote:
> Is there a possibility for a PlugIn
> to run other PlugIns asyncron?

technically yes, but not using the current api (my discussion below, mind
you, focuses on the long-term solution not on any hacks that could be done
now to enable this fucntionality).

> If there is no way to do asyncron calls now
> we should think about to add them,

The PDB has a lot of other problems that should be addressed in one batch
(like the many ugly ALT functions) and not before 1.2, of course ;)

> But SUCCESS is returned immediate

And how would one get the results?

> after the requested plugin could be started.
> gimp_run_async_procedure* does not
> wait until the requested plugin has finished.

These functions would (with the current API) be just a hack (that does not
mean that they maybe should be implemented since the 1.2 design will not
likely survive in it's present form anyway), but for the long-term-future
we need a different solution.

BTW, has anybody thought about my proposal in favour of MCOP (fast &
multimedia-capable) rather than CORBA (not multimedia capable)?

>  I once tried to do a workaround
>  by forking a playback process
>  to call the plug_in_animationplay
>  but this does not work !

Did it crash? ;)

Well, that is an idea. With some kind of connection identifier it should
be easy to multiplex. In fact the Perl-Server does just this and you could
use that to make an synchroneous call - a quite more horrible hack, of
course ;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |

Asyncron PDB->PDB calls (2) ?

[wolfgang hofer]

Hi,

Is there a possibility for a PlugIn
to run other PlugIns asyncron?

2 of my Plugins (the GAP Video/Navigator and
the Animated Preview in GAP Video/Move Path)
are currently calling the PlugIn animationplay
 
 return_vals =
 gimp_run_procedure ("plug_in_animationplay",
&nreturn_vals,
GIMP_PDB_INT32,GIMP_RUN_NONINTERACTIVE,
GIMP_PDB_IMAGE,l_new_image_id,
GIMP_PDB_DRAWABLE, -1,  /* dummy */
GIMP_PDB_END);

This blocks the GUI Dialog Windows,
until the animation play is closed
(by the user).
In that case It would make sense
to run the plug_in_animationplay
without waiting until finished.

If there is no way to do asyncron calls now
we should think about to add them,
for example with the names:

  gimp_run_async_procedure
  gimp_run_async_procedure2

with the same parameters like the already
existing syncron versions.
But SUCCESS is returned immediate
after the requested plugin could be started.
gimp_run_async_procedure* does not
wait until the requested plugin has finished.


Note:
 I once tried to do a workaround
 by forking a playback process
 to call the plug_in_animationplay
 but this does not work !
 (when the animationplay terminates,
 the calling Plugin dies, 
 maybe when trying to call
 any gimp core function, while
 gimp thinks the plugin has already
 terminated)


Yours Wolfgang Hofer, <[EMAIL PROTECTED]>
(Author of GAP)

PS: I have already sent this message 
on: 2000.Nov.17
to: [EMAIL PROTECTED]
but it did not appear in the gimp-developer
mailing list archive until now.
Maybe a 2nd try will make it to the list ?


Get FREE Email/Voicemail with 15MB at Lycos Communications at http://comm.lycos.com

PDB

[Fethi BELGHAOUTI]

hi to all,
how can i do to know of which package depond my
procedure (or all of the PDB) ?

i ask this question, because when i execute some
script in two differents PCs i have some errors in one
of this PCs. And i think that's because there is not
the same PDB !
am i right ?

thank you.
Fethi, simply.

___
Do You Yahoo!?
Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr

Rotation command in PDB

[Michael Lee]

The current gimp_rotate procedure does not allow for rotation around an
arbitrary point even though its code is quite capable of it.  It just selects
the center of the image and uses that as the rotation origin.  I added a
gimp_rotate_around_point procedure and use it in all the scripts I'm
writing.  With the new procedure, you only need to select the region you wish
to rotate (just like the interactive rotate tool in the toolbox).  Below I've
included the source code additions I made to tools_cmds.c (I don't know how to
use diff and patch yet).  All I really did was copy the original rotate_invoker
and add X and Y center point parameters to it.  Obviously, the two procedures
could be written to reuse the same invoker code.


-Michael




/*
--Added declaration
*/

static ProcRecord rotate_around_point_proc;




/*
--Added register function call
*/

void
register_tools_procs (void)
{
  ...
  
  procedural_db_register (&rotate_around_point_proc);
  
  ...
}




/*
--Added new invoker
--It just gets its center point from the arguments and sets
--the return arguments to reference the correct PDB proc
*/

static Argument *
rotate_around_point_invoker (Argument *args)
{
  gboolean success = TRUE;
  Argument *return_args;
  GimpDrawable *drawable;
  gboolean interpolation;
  gdouble angle;
  GimpImage *gimage;
  TileManager *float_tiles, *new_tiles;
  gboolean new_layer;
  double cx, cy;
  GimpMatrix3 matrix;

  drawable = gimp_drawable_get_ID (args[0].value.pdb_int);
  if (drawable == NULL)
success = FALSE;

  interpolation = args[1].value.pdb_int ? TRUE : FALSE;

  angle = args[2].value.pdb_float;

  if (success)
{
  gimage = drawable_gimage (GIMP_DRAWABLE (drawable));

  /* Start a transform undo group */
  undo_push_group_start (gimage, TRANSFORM_CORE_UNDO);

  /* Cut/Copy from the specified drawable */
  float_tiles = transform_core_cut (gimage, drawable, &new_layer);

  /* get the center from the arguments passed in */
  cx = args[3].value.pdb_int;
  cy = args[4].value.pdb_int;

#if 0
  cx = float_tiles->x + float_tiles->width / 2.0;
  cy = float_tiles->y + float_tiles->height / 2.0;
#endif

  /* Assemble the transformation matrix */
  gimp_matrix3_identity  (matrix);
  gimp_matrix3_translate (matrix, -cx, -cy);
  gimp_matrix3_rotate(matrix, angle);
  gimp_matrix3_translate (matrix, +cx, +cy);

  /* Rotate the buffer */
  new_tiles = rotate_tool_rotate (gimage, drawable, NULL, angle,
  float_tiles, interpolation, matrix);

  /* Free the cut/copied buffer */
  tile_manager_destroy (float_tiles);

  if (new_tiles)
success = transform_core_paste (gimage, drawable, new_tiles, new_layer);
  else
success = FALSE;

  /* Push the undo group end */
  undo_push_group_end (gimage);
}

  return_args = procedural_db_return_args (&rotate_around_point_proc, success);

  if (success)
return_args[1].value.pdb_int = drawable_ID (GIMP_DRAWABLE (drawable));

  return return_args;
}




/*
--It gets its own input arguments
--Note: I reused the output argments since they are identical.
*/

static ProcArg rotate_around_point_inargs[] =
{
  {
PDB_DRAWABLE,
"drawable",
"The affected drawable"
  },
  {
PDB_INT32,
"interpolation",
"Whether to use interpolation"
  },
  {
PDB_FLOAT,
"angle",
"The angle of rotation (radians)"
  },
  {
PDB_INT32,
"x",
"the x coordinate of the point"
  },
  {
PDB_INT32,
"y",
"the y coordinate of the point"
  }
};




/*
--Added the procedure info
*/

static ProcRecord rotate_around_point_proc =
{
  "gimp_rotate_around_point",
  "Rotate the specified drawable about a point through the specified angle.",
  "This tool rotates the specified drawable if no selection exists. If a selection 
exists, the portion of the drawable which lies under the selection is cut from the 
drawable and made into a floating selection which is then rotated by the specified 
amount. The interpolation parameter can be set to TRUE to indicate that either linear 
or cubic interpolation should be used to smooth the resulting rotated drawable. The 
return value is the ID of the rotated drawable. If there was no selection, this will 
be equal to the drawable ID supplied as input. Otherwise, this will be the newly 
created and rotated drawable.",
  "Spencer Kimball & Peter Mattis",
  "Spencer Kimball & Peter Mattis",
  "1995-1996",
  PDB_INTERNAL,
  5,
  rotate_around_point_inargs,
  1,
  rotate_outargs,
  { { rotate_around_point_invoker } }
};

exemple of the PDB

[Fethi BELGHAOUTI]

hi to all,
can you tell me where can i find, exemple of the most
procedures of Perl-Gimp ?

Thank's to all.
Fethin simply.

___
Do You Yahoo!?
Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr

Re: Rotation command in PDB

[David Hodson]

Michael Lee wrote:

> The current gimp_rotate procedure does not allow for rotation around an
> arbitrary point even though its code is quite capable of it.  It just selects
> the center of the image and uses that as the rotation origin.  I added a
> gimp_rotate_around_point procedure and use it in all the scripts I'm
> writing.

Currently, the PDB provides either basic rotate, scale, or shear, or
a full-blown perspective. Instead of just augmenting rotation, why not
provide a 2D transform, with rotate, scale, and shift in a single op?

Although it's a little redundant, I've found the following parameters
useful to describe 2d transforms:

  centre of transform
  x and y scale
  rotation angle
  destination point for centre

plus interpolation on/off.

(Do the PDB versions expand the drawable to fit? Do we need another
flag for this?)

This is not really a new feature (freeze-wise), but would be very
useful. I can probably do it if no one else has the time, and if
the powers-that-be don't object.

-- 
David Hodson  --  [EMAIL PROTECTED]  --  this night wounds time

Re: Rotation command in PDB

[Steinar H. Gunderson]

On Sun, Apr 23, 2000 at 12:57:57PM +1000, David Hodson wrote:
>Instead of just augmenting rotation, why not
>provide a 2D transform, with rotate, scale, and shift in a single op?

Hmmm... That wouldn't be too stupid... Isn't this where all the nice
matrix multiplication maths comes in and helps us speed-wise? Or is it
only cost-effective for 3D points?

/* Steinar */
-- 
Homepage: http://members.xoom.com/sneeze/

Re: Rotation command in PDB

[David Hodson]

OK, here's my first cut at a PDB general 2d transform. It provides
rotation, scaling (with separate x and y factors), and translation.
General enough to be useful, but still easier to use than a full
perspective operation.

Sorry, not in patch format; but it all goes in tool_cmds.c,
declaration and registration near the top, everything else pasted
at the end of the file.

-- 
David Hodson  --  [EMAIL PROTECTED]  --  this night wounds time



/*
--Added declaration
*/

static ProcRecord transform_2d_proc;


/*
--Added register function call
*/

void
register_tools_procs (void)
{
  ...
  
  procedural_db_register (&transform_2d_proc);
  
  ...
}




/*
--Added new invoker
--zoom and rotate about point (source_x, source_y)
--then move (source_x, source_y) to (dest_x, dest_y)
*/

static Argument *
transform_2d_invoker (Argument *args)
{
  gboolean success = TRUE;
  Argument *return_args;
  GimpDrawable *drawable;
  gboolean interpolation;
  gdouble source_x, source_y;
  gdouble angle;
  gdouble scale_x, scale_y;
  gdouble dest_x, dest_y;
  GimpImage *gimage;
  TileManager *float_tiles, *new_tiles;
  Layer* layer;
  gboolean new_layer;
  GimpMatrix matrix;

  drawable = gimp_drawable_get_ID (args[0].value.pdb_int);
  if (drawable == NULL)
success = FALSE;

  if (success)
{
  gimage = drawable_gimage (GIMP_DRAWABLE (drawable));

  /* Start a transform undo group */
  undo_push_group_start (gimage, TRANSFORM_CORE_UNDO);

  /* Cut/Copy from the specified drawable */
  float_tiles = transform_core_cut (gimage, drawable, &new_layer);

  interpolation = args[1].value.pdb_int ? TRUE : FALSE;

  /* transform centre */
  source_x = args[2].value.pdb_float;
  source_y = args[3].value.pdb_float;

  /* transform scale */
  scale_x = args[4].value.pdb_float;
  scale_y = args[5].value.pdb_float;

  /* angle (radians) */
  angle = args[6].value.pdb_float;

  /* transform destination */
  dest_x = args[7].value.pdb_float;
  dest_y = args[8].value.pdb_float;

  /* Assemble the transformation matrix */
  gimp_matrix_identity  (matrix);
  gimp_matrix_translate (matrix, -source_x, -source_y);
  gimp_matrix_scale (matrix, scale_x, scale_y);
  gimp_matrix_rotate(matrix, angle);
  gimp_matrix_translate (matrix, dest_x, dest_y);

  /* Transform the buffer */
  new_tiles = transform_core_do (gimage, drawable, float_tiles,
  interpolation, matrix, NULL, NULL);

  /* Free the cut/copied buffer */
  tile_manager_destroy (float_tiles);

  if (new_tiles)
{
  layer = transform_core_paste (gimage, drawable, new_tiles, new_layer);
  success = layer != NULL;
}
  else
success = FALSE;

  /* Push the undo group end */
  undo_push_group_end (gimage);
}

  return_args = procedural_db_return_args (&transform_2d_proc, success);

  if (success)
return_args[1].value.pdb_int = drawable_ID (GIMP_DRAWABLE (drawable));

  return return_args;
}




/*
--It gets its own input arguments
*/

static ProcArg transform_2d_inargs[] =
{
  {
PDB_DRAWABLE,
"drawable",
"The affected drawable"
  },
  {
PDB_INT32,
"interpolation",
"Whether to use interpolation"
  },
  {
PDB_FLOAT,
"source_x",
"X coordinate of the transform centre"
  },
  {
PDB_FLOAT,
"source_y",
"Y coordinate of the transform centre"
  },
  {
PDB_FLOAT,
"x_scale",
"Amount to scale in x"
  },
  {
PDB_FLOAT,
"y_scale",
"Amount to scale in y"
  },
  {
PDB_FLOAT,
"angle",
"The angle of rotation (radians)"
  },
  {
PDB_FLOAT,
"dest_x",
"X coordinate of where the centre goes"
  },
  {
PDB_FLOAT,
"dest_y",
"Y coordinate of where the centre goes"
  }
};


static ProcArg transform_2d_outargs[] =
{
  {
PDB_DRAWABLE,
"drawable",
"The transformed drawable"
  }
};



/*
--Added the procedure info
*/

static ProcRecord transform_2d_proc =
{
  "gimp_transform_2d",
  "Transform the specified drawable in 2d",
  "This tool transforms the specified drawable if no selection exists. If a selection
exists, the portion of the drawable which lies under the selection is cut from the
drawable and made into a floating selection which is then transformed. The 
interpolation
parameter can be set to TRUE to indicate that either linear or cubic interpolation
should be used to smooth the resulting drawable. The transformation is done by scaling
the image by the x and y scale factors about the point (source_x, source_y), then
rotating around the same point, then translating that point to the new position
(dest_x, dest_y). The return 

Re: Rotation command in PDB

[Sven Neumann]

Hi,

> OK, here's my first cut at a PDB general 2d transform. It provides
> rotation, scaling (with separate x and y factors), and translation.
> General enough to be useful, but still easier to use than a full
> perspective operation.
> 
> Sorry, not in patch format; but it all goes in tool_cmds.c,
> declaration and registration near the top, everything else pasted
> at the end of the file.

Actually no code at all goes directly into tool_cmds.c nor in any
file that ends on _cmds.c. Those are all autogenerated using pdbgen
from files you'll find in the tools/pdbgen/pdb directory. The 
proposed code looks good however and I'll look into committing it 
today.


Salut, Sven

Re: Startup - duplicate PDB messages? - 1.1.15

[Marc Lehmann]

On Sat, Jan 15, 2000 at 06:21:35PM -0500, Glenn PM <[EMAIL PROTECTED]> wrote:
> > Did you remove your old gimp installation? The error messages below
> > are probably caused by left-over plug-ins in your $PREFIX/lib/plug-ins
> 
> Yes I did.

I still think this is the only way you could get these messages. Maybe "make
uninstall" did not work for some reason? The mos tprobable fix, then, is to

rm `gimptool --prefix`/lib/gimp/1.1/plug-ins/*.pl

> this version. After I finished it the first time ( a real long time too
> on my 133), I got lots of errors since the 1.1.15 version was referring
> to the last build I made which was 1.1.12

Not good... do you have a message or something?

> strange that I'm getting these PDB messages now. Since nothing appears
> wrong, I'll just ignore them.

Most probably nothing is wrong. But I guess your startup time is
unnecessarily long.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |

Re: Startup - duplicate PDB messages? - 1.1.15

[Glenn PM]

Hi,

"Garry R. Osgood" wrote:
> 
> Marc Lehmann wrote:
> 

> > I still think this is the only way you could get these messages. Maybe "make
> > uninstall" did not work for some reason? The mos tprobable fix, then, is to
> >
> > rm `gimptool --prefix`/lib/gimp/1.1/plug-ins/*.pl

This did the trick. It starts MUCH faster now :-)

> 
> 
> 
> Glenn also reported: "I also did a make uninstall on the old version
> after
> I got a good make on the new..."
> 
> Was "make uninstall" invoked on Makefiles generated by the 1.1.15
> package?
> These are not likely to be symmetrical with those generated by 1.1.12,
> and, I
> don't believe, can be expected to clean up after what Makefiles
> generated
> under 1.1.12 produced.
 
I did the "make uninstall" on the 1.1.12 Makefile. I had all of the
1.1.12 files in a separate directory from the 1.1.15

I did this:

cd /packages/gimp-1.1.15
./configure; make

Looked good so,

cd /packages/gimp-1.1.12
make uninstall
cd /packages/gimp-1.1.15
make install-strip

When I started it up the first time it was looking for the
libgimp-1.1.so.12. I then,
rm -f /packages/gimp-1.1.12
cd /packages/gimp-1.1.15
make uninstall; make clean; ./configure; make; make install-strip



Glenn
--

NLS-Problems passing GIMP_PDB_FLOAT PDB parameters

[wolfgang hofer]

Hi,

I am currently writing on a GIMP plug-in to extract
frames and audio from MPEG videos.
The plugin's GUI is made with GLADE,
and the libmpeg3 (1.2.2) is used as MPEG-decoder.

while testing i had some Problems with passing
FLOAT parameters between my plugin and the GIMP.


- The opacity Parameter is passed from my plugin
  to the gimp_layer_new Procedure 
  with Value 100.0

  .. but is recieved in the GIMP main Application
  with Value 1.0

- The Problem is related to NLS (the LANG Environment Variable)  
  (when I do unset LANG, everything is OK)

- My PlugIn has a GUI that was created by GLADE.
  the main Routine, generated by GLADE 
  starts with:
  
gtk_set_locale ();
gtk_init (&argc, &argv);

  Without gtk_set_locale(), passing of FLOAT Parameters
  works just fine, even if LANG=german set.
  Well this is a solution for my plugin, but ...

I guess that NLS specific print representation of float numbers
can cause those troubles in the PDB Interface.

  US Decimalpoint 100.0
  German Decimalkomma 100,0

Maybe this hint could be useful for other (PlugIn)Developers too.

Should I report this as Bug of the GIMP PDB-Interface ?


Yours Wolfgang Hofer, <[EMAIL PROTECTED]> 
(Author of GAP)

--

PS:

Here are some additional notes about my system:

 I am using using GIMP 1.2.1
 -bash gimpixII:[gui_tst] >gtk-config --version
 1.2.8
 -bash gimpixII:[gui_tst] >uname -a
 Linux gimpixII 2.2.16 #1 Mon Jan 1 20:47:09 CET 2001 i686 unknown


I added some printf statements to my_plugin and to
my local copy of:
  gimp-1.2.1/libgimp/gimp.c
  gimp-1.2.1/libgimp/gimplayer.c
  gimp-1.2.1/libgimp/gimplayer_pdb.c

  gimp-1.2.1/app/layer.c
  gimp-1.2.1/app/layer_cmds.c
  gimp-1.2.1/app/plug_in.c
to TRACE relevant procedures and parameter values
related to this problem, And here is the result:

--
-bash gimpixII:[gui_tst] >env | grep LANG
LANG=german
-bash gimpixII:[gui_tst] >gimp

MY_PLUGIN: before call to gimp_layer_new

LIBGIMP: gimp_layer_new: opacity = 100,00

LIBGIMP: _gimp_layer_new: image_ID = 12
LIBGIMP: _gimp_layer_new: width = 320
LIBGIMP: _gimp_layer_new: height = 240
LIBGIMP: _gimp_layer_new: type = 0
LIBGIMP: _gimp_layer_new: name = my_layer
LIBGIMP: _gimp_layer_new: opacity = 100,00
LIBGIMP: _gimp_layer_new: mode = 0
LIBGIMP: gimp_run_procedure GIMP_PDB_FLOAT: arg[5]  par: 100,00

APP: plug_in_params_to_args arg[5]  par: 1.00 arg:1.00
APP: layer_new_invoker: opacity_arg = 1.00
APP: layer_new_invoker: opacity = 2
APP: layer_new: int opacitiy = 2

MY_PLUGIN: after call to gimp_layer_new
MY_PLUGIN: gimp_layer_get_opacity 1: 7,00

--


Get your small business started at Lycos Small Business at 
http://www.lycos.com/business/mail.html

[Fwd: Re: Startup - duplicate PDB messages? - 1.1.15]

[Garry R. Osgood]

Marc Lehmann wrote:

> On Sat, Jan 15, 2000 at 06:21:35PM -0500, Glenn PM <[EMAIL PROTECTED]> wrote:
> > > Did you remove your old gimp installation? The error messages below
> > > are probably caused by left-over plug-ins in your $PREFIX/lib/plug-ins
> >
> > Yes I did.
>
> I still think this is the only way you could get these messages. Maybe "make
> uninstall" did not work for some reason? The mos tprobable fix, then, is to
>
> rm `gimptool --prefix`/lib/gimp/1.1/plug-ins/*.pl
> gimp_image_base_type_with_alpha (gimage)



Glenn also reported: "I also did a make uninstall on the old version
after
I got a good make on the new..."

Was "make uninstall" invoked on Makefiles generated by the 1.1.15
package?
These are not likely to be symmetrical with those generated by 1.1.12,
and, I
don't believe, can be expected to clean up after what Makefiles
generated 
under 1.1.12 produced.

Be good, be well

Garry Osgood

Re: NLS-Problems passing GIMP_PDB_FLOAT PDB parameters

[Nick Lamb]

On Mon, Feb 12, 2001 at 07:21:07AM +0100, wolfgang hofer wrote:
> I guess that NLS specific print representation of float numbers
> can cause those troubles in the PDB Interface.

Yes, if you used the Gimp's API as described you would not have had this
problem. It deliberately disables i18n functionality related to floats

Some future version of Gimp should re-write the pipe to use fixed point,
or to otherwise get around this annoying limitation so that Gimp
plug-ins can be fully i18n. Not today though.

Nick.

Re: NLS-Problems passing GIMP_PDB_FLOAT PDB parameters

[Sven Neumann]

Hi,

"wolfgang hofer" <[EMAIL PROTECTED]> writes:

> - The Problem is related to NLS (the LANG Environment Variable)  
>   (when I do unset LANG, everything is OK)

If you had used the macros gimp provides for initializing I18N, you 
wouldn't have had this problem. Your code should look like this:

  gtk_set_locale(); 
  setlocale (LC_NUMERIC, "C");

Actually I would suggest you copy code from libgimp/gimpintl.h and
adapt it your needs.

> Should I report this as Bug of the GIMP PDB-Interface ?

No, it's a bug in your code.


Salut, Sven