Sven- I've been running my Gimp Perl script entirely as a single cgi communicating to Gimp through the perl-server without having registered any of the code. I think from your response that the portion of the script that sets the color, does the text rendering and pushes the gimpcontext needs to be executed within an individual Gimp procedure call which means I'll have to register at least that portion of it. Running it all as a cgi doesn't appear to "magically" make use of a script-only context, and so it was probably still using the user context. Let me know if I'm offbase on this. Thanks, Jared > -----Original Message----- > From: Sven Neumann [mailto:sven@xxxxxxxx] > Sent: Friday, January 21, 2005 12:15 PM > To: Jared Whiting > Cc: gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > Subject: Re: [Gimp-developer] GimpContext and Gimp Perl's > non-thread safe resources > > Hi, > > "Jared Whiting" <jwhiting@xxxxxxxxx> writes: > > > Is there anything that takes place behind the scenes that makes sure > > that each script is running in its own context? > > Scripts and plug-ins are by default run in the user context. Changing > this would have broken backward compatibility so we had to choose the > API where plug-ins and scripts have to push their own context if they > want to run in their own context. > > > Or does the call to gimp_text_fontname simply use the latest context > > added to the stack, allowing for something like script x switching > > to look at a context pushed by script y while in the middle of > > executing calls to gimp_text_fontname? > > The context stack is local to the current procedure. So if your script > is executed in it's own procedure call and pushes a context, then that > context is local to that script and can not be accessed by anyone > else. Basically my answer boils down to: I don't believe that your > scripts are misbehaving the way you described. > > > Sven > >
