Re: [Gimp-developer] "quit" signal for plugins
On Thu, Feb 5, 2009 at 3:12 PM, Sven Neumann wrote: > > I think it would make sense to call the quit method in all running > plug-ins when the core is quit. So a patch that does this would be much > appreciated. We need to somehow deal with the problem of hanging > plug-ins though. > > > Sven > I can code up a patch if we can figure out how to prevent stalling. My approach would be to fork and call the quit method in the child, then if the child doesn't return in two seconds, pop up a dialog informing the user that a plug in is not responding and give them the option to terminate it. I don't know how the GIMP deals with threading though, so I'm not sure that that is appropriate in this case. Someone earlier mentioned a non-blocking wait, does the GIMP have some system in place for doing that? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] "quit" signal for plugins
Thank you for the link to that thread, it was very informative. I have yet to find any sort of workaround. I tried trapping all the TERM type signals but no luck there. Is doing a non blocking wait still under discussion? Actually, for my purposes it doesn't matter whether the wait is blocking, because I just need to run a gedit style "Save changes?" dialog. Or, if I only had a second, just save some sort of backup. It seems like several different plugins could take advantage of that because they make temporary images. (or would this still be only on plugin quit and not gimp quit?) Thanks again for your continued assistance, -Soren Berg On Tue, Feb 3, 2009 at 12:47 PM, Sven Neumann wrote: > > I very much doubt that any real-world plug-in is actually using the quit > function. I tried to use it once in a patch attached to > http://bugzilla.gnome.org/show_bug.cgi?id=8141#c7 > > > Sven > > > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] "quit" signal for plugins
I have been thinking about this and it does seem to be a somewhat thorny issue. One possible solution would be to call the quit functions of the plugins but have a timeout set so that you could pop up a dialog if they did not quit after a second or two asking if the user wanted to terminate the plugin. But this seems messy. Another thought: If a plugin has a quit function that hangs or takes a long time, won't that affect the gimp when the quit function is normally called (on closing of plugin)? If so, the gimp is already exposed to the problem of poorly written plugins, and it might as well call the quit functions of active plugins when it exits. Or does the gimp have some way of protecting against this issue that wouldn't work if it was closing? Thank you for your assistance, -Soren Berg On Sun, Feb 1, 2009 at 12:49 PM, Sven Neumann wrote: > > I am not entirely sure how plug-ins are quit by the core when the GIMP > core exits. It would probably make sense to make sure that the plug-in's > quit function is called. On the other hand we don't want the application > to hang there waiting for plug-ins to quit. If you want to investigate > this further, we could try to help you to fix this issue. > > > Sven > > > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] "quit" signal for plugins
I have been developing a plugin that involves users editing files and I need
to be able to prompt them to save when the gimp closes.
I have tried using the quit signal in pluginInfo:
GimpPlugInInfo PLUG_IN_INFO =
{
NULL,
quit,
query,
run
};
This only seems to be called, however, when the plugin closes and not the
gimp.
(It is a GTK plugin with it's own window like script-fu, I get the signal
when I close the plugin window, but if the user closes the gimp I have no
way to clean up.)
Is this a bug or is my understanding of what this callback is supposed to do
flawed?
Is there another way to do what I am trying to accomplish?
Thank you for your time,
Soren Berg
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu/tinyscheme: using scheme_call?
On 7/10/07, Kevin Cozens <[EMAIL PROTECTED]> wrote: > Have you also looked at init_procedures() and marshall_proc_db_call() in the > scheme_wrapper.c file? You will find other examples of defining Scheme > routines that will call C when invoked and which require parameters. Our current setup uses init_procedures to load our functions, and is based on what we found there. Many of the functions listed there do an excellent job of parsing arguments passed from Scheme, but the only Script-Fu/Tiny-Fu way we've been able to find to make calls back to the Scheme interpreter is using the ts_interpret_string function, which calls tinyscheme's scheme_load_string and requires that you know the string name of the procedure you're trying to call. > That is about all I can suggest for the moment without knowing the specifics > of the situtation where you feel you have to use scheme_call. We're currently working on a function called from the Script-Fu/Tiny-Fu console like (pixel-map drawable function) that maps said function (which takes an argument for each channel in the drawable and returns a list of new values for each channel) to every pixel in a drawable. When writing a foreign function that parses a Scheme argument list, we haven't found a way to get back a string procedure name from an argument of type T_CLOSURE, which is a problem since all user-defined Scheme procedures have this type, so we can't use scheme_load_string. Also, tinyscheme already has scheme_call, a function that works well enough to return values we can parse and takes arguments in the same format Scheme passes them to foreign functions (i.e. "pointer"s to Scheme functions of type T_CLOSURE and "pointer"s to argument lists). Even if we were to find a way to get a string name for a procedure and build string calls like "(function r g b)" to pass to scheme_load_string, it seems like a step backward to do so having received the parameters in the first place in a format closer to tinyscheme's evaluation cycle. The problem with scheme_call is that it doesn't play well inside foreign functions. Any foreign function, as far as we can tell, that calls scheme_call will proceed normally and return. However, the function's return value isn't picked up by tinyscheme, so something like (+ 1 (foreign-func-with-scheme_call 2)) won't return anything. This behavior is specific to foreign functiosn that call scheme_call, so something like (+ 1 (foreign-func-without-scheme_call 2)) will generally work. We'll try to contact the tinyscheme people about this. Thanks, Ted and Emily ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu/tinyscheme: using scheme_call?
Thanks for the reply! > Interesting attempt, but Script-Fu was never meant to be used for direct > pixel manipulation. May I ask why you aren't using one of the GIMP > bindings, like for example Python, that provides support for this level > of pixel access? We're working for the Grinnell College Computer Science department; The professors here teach introductory CS in Scheme and have been trying to use Script-Fu as a lab environment. Because the PDB fuctions gimp-drawable-get/set-pixel are all they've had access to for building higher-order image manipulation procedures, any image larger than about 100x100 took several minutes to process. One of our tasks for the summer has been to make Script-Fu faster, so its use in the classroom won't be painful for students. Thanks, Ted and Emily ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu/tinyscheme: using scheme_call?
Thanks for the reply, Kevin. > While using the foreign function interface of TinyScheme might work, for what > you are trying to do it is not the best approach. You should really look at > implementing it as a TinyScheme extension. Take a look at the re and tsx > extensions for TinyScheme to see how extensions work. Thanks for mentioning this; we hadn't looked at it previously. Making an extension is definitely what we'd like to do once our code is in a state worth sharing. However, even if we were to build this in an extension, from looking at re and ftx, it seems like we'd still need mk_foreign_func'ed functions, at least one of which would still need to use scheme_call. Do you know of another way to assign arguments to and evaluate a closure passed to a foreign function from tinyscheme? Do you know if Jonathan Shapiro/Dimitrios Souflis are still actively maintaining tinyscheme? > I plan on enabling the loading of extensions at run-time at some point. The > main reason it hasn't been turned on yet is that I do not know whether the > code that loads extensions is portable to other operating systems. Looking forward to it! Thanks! Ted Cooper and Emily Jacobson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Script-Fu/tinyscheme: using scheme_call?
Attempting to map a Scheme function in Script-Fu/Tiny-Fu to an entire
image using the PDB functions gimp-drawable-get-pixel and
gimp-drawable-set-pixel is painfully slow, so we've been trying to
build a mk_foreign_func'ed function to attach to tinyscheme that
updates images in a tile-aware way.
As far as we can tell, the most straightforward methods tinyscheme
provides for Scheme command evaluation from C are a) using the
scheme_load_string function to parse a string of Scheme code, and b)
passing Scheme function and argument pointers to scheme_call.
mk_foreign_func'ed functions receive parameters in the latter format,
so parsing them and building a command string to pass back seems
clunky. scheme_call, on the other hand, quickly evaluates a closure
passed with arguments and stores the result in sc->value, and we have
had success mapping Scheme functions to large images.
However, mk_foreign_func'ed functions that call scheme_call don't
return correctly, so Scheme code that contains calls to these
functions breaks; we're having trouble figuring out why. scheme_call
isn't included in scheme.h, so it's probably not even intended for
external use. We haven't been able to find any documentation for
scheme_call so we don't know whether we're using it correctly or not.
We've been using scheme_call like
scheme_call(,
,
NIL))>)
Is this the correct way to call scheme_call? Including this call to
scheme_call in any mk_foreign_func'ed function causes tinyscheme to
fail to process the function's return, i.e., it causes
(func-with-scheme_call foo), (+ 1 (func-with-scheme_call foo) ), etc.
to not evaluate to anything. When we remove scheme_call calls, our
functions do not have this problem.
We've been trying to learn how Eval_Cycle in scheme.c works to figure
out why this is happening, but it's not going very well. We're hoping
someone out there knows tinyscheme well enough to tell us what we're
doing wrong. Below is a program we've been using for testing that
shows how we're calling scheme_call, how calls with/without it behave,
etc. This won't compile against the GIMP's tinyscheme without adding
a scheme_call prototype to scheme.h, etc.; if you want specifics,
we'll gladly provide them.
We're students, and we've tried to avoid making any egregious errors
in tone/content or etiquette, but if any of this seems weird please
attribute it to our inexperience and tell us why.
Thanks,
Ted Cooper and Emily Jacobson
#include "scheme-private.h"
#include "scheme.h"
pointer twomath(scheme *sc, pointer args);
pointer twomath(scheme *sc, pointer args){
long result;
pointer a, b;
pointer func;
a = sc->vptr->pair_car(args);
args = sc->vptr->pair_cdr(args);
b = sc->vptr->pair_car(args);
args = sc->vptr->pair_cdr(args);
func = sc->vptr->pair_car(args);
printf(" twomath: (pre-scheme_call) sc->vptr->ivalue(sc->value):
%ld\n",sc->vptr->ivalue(sc-
>value));
scheme_call(sc, func, cons(sc, a, cons(sc, b, sc->NIL)));
result = sc->vptr->ivalue(sc->value);
printf(" twomath: (post-scheme_call) sc->vptr->ivalue(sc->value):
%ld\n", result);
printf(" twomath: scheme_call sets sc->value to the correct value,
but when we try to return a copy...");
/*return sc->value;*/
return sc->vptr->mk_integer(sc,result);
}
int main(){
scheme *sc;
FILE *init_scm;
sc = scheme_init_new();;
init_scm = fopen("init.scm","r");
scheme_load_file(sc, init_scm);
fclose(init_scm);
scheme_set_output_port_file(sc, stdout);
sc->print_flag=1; /* necessary? */
sc->print_output=1;
printf("regular functions return, produce output, and set sc->value
to some crazy huge number:\n");
printf(" (pre-scheme_load_string), sc->vptr->ivalue(sc->value):
%ld\n", sc->vptr->ivalue(sc->value));
printf(" (- 4 4)\n");
scheme_load_string(sc, "(- 4 4)");
printf("output above, and (post-scheme_load_string),
sc->vptr->ivalue(sc->value): %ld <- DIFFERENT CRAZY HUGE NUMBER\n",
sc->vptr->ivalue(sc->value));
printf(" (+ 32 (- 4 5))\n");
scheme_load_string(sc, "(+ 32 (- 4 5))");
printf("output above, and (post-scheme_load_string),
sc->vptr->ivalue(sc->value): %ld <- THE SAME CRAZY HUGE NUMBER\n",
sc->vptr->ivalue(sc->value));
printf("defined foreign function twomath, takes two integers and a
function\n");
sc->vptr->scheme_define(
sc,
sc->global_env,
sc->vptr->mk_symbol(sc,"twomath"),
sc->vptr->mk_foreign_func(sc, twomath));
printf(" (twomath 1 2 +)\n");
scheme_load_string(sc, "(twomath 1 2 +)");
printf("\nit returns no output, and putting it in another function
call...\n");
printf(" (+ 1 (twomath 1 2 +))\n");
scheme_load_string(sc, "(+ 1 (twomath 1 2 +))");
printf("\nstill returns no output, and sc->vptr->ivalue(sc->value):
%ld = the value set in twomath (it hasn't been updated to some crazy
huge number, since + couldn't evaluate without two parameters). Next,
let's run a command that will evaluate to see what happens to
sc->value\n",sc->vptr->ivalu
