After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 66859 - Plug-in init_proc functionality isn't implemented
Plug-in init_proc functionality isn't implemented
Status: VERIFIED FIXED
Product: GIMP
Classification: Other
Component: Plugins
1.x
Other All
: Normal enhancement
: 2.0
Assigned To: GIMP Bugs
Daniel Egger
Depends on:
Blocks:
 
 
Reported: 2001-12-13 09:47 UTC by Tor Lillqvist
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch against gimp-1-2 (8.17 KB, patch)
2001-12-13 09:50 UTC, Tor Lillqvist
none Details | Review

Description Tor Lillqvist 2001-12-13 09:47:53 UTC
For a new (quite interesting) plug-in I am writing, I needed the
init_proc field in the GimpPlugInInfo struct to actually work. 

Until now this field has had no effect. Could this be regarded as a
bug? In that case a patch presumably could go into the gimp-1-2 branch
(but only after GIMP 1.2.3 has been released).

Or is it best to add this functionality only to HEAD?  (In that case,
I'll keep the functionality in my gimp-1-2 sources anyway, to have it
in the binary Windows GIMP releases.)

I have a patch (to gimp-1-2) for one way to add the init_proc
functionality. The situation is a bit more complicated than one might
first guess, as the plug-in needs to tell GIMP the first time it is
queried that in the future, GIMP should run it for the purpose of
running the init_proc each time GIMP starts. This info is kept in an
additional flag '(has-init)' in the plug-in-def list in pluginrc.

The init_proc is run by starting the plug-in with -init instead of
-query or -run.

In order not to have to add a new GP_* enum value, the plug-in informs
GIMP about having an init_proc by pretending to install a procedure
with a special marker name. Perhaps a bit ugly, but works, and
simplifies the diff.
Comment 1 Tor Lillqvist 2001-12-13 09:50:23 UTC
Created attachment 6214 [details] [review]
patch against gimp-1-2
Comment 2 Sven Neumann 2001-12-13 13:13:44 UTC
I don't like the idea of using a special marker name as a protocol
extension. Definitely not a solution for 1.3. I see however why you
don't want to add to the enum since this would require us to increase
the protocol version which we can't do for 1.2. I'll think about it
more and will propably implement it for 1.3 when cleaning up the 
plug-in code...  
Comment 3 Sven Neumann 2002-02-19 10:11:01 UTC
Implemented in 1.3 by Nathan Summers:

2002-02-12  Nathan Summers  <rock@gimp.org>

 * app/plug-in/plug-in-rc.c: implement a new pluginrc flag,
 "has-init", so that only plug-ins with init functions are
 initialized.

 * app/plug-in/plug-in.ch
 * libgimp/gimp.c
 * libgimpbase/gimpprotocol.ch: send a new gimpwire message,
 GP_HAS_INIT during the query stage if the plug-in needs to be
 initialized.  Only invoke the plug-in in init mode if the plug-in
 has an init function.  Incremented the interface age.

 (inspired by a patch by Tor Lillqvist available at 
 http://bugzilla.gnome.org/showattachment.cgi?attach_id=6214)


2002-02-11  Nathan Summers  <rock@gimp.org>

 * app/plug-in/plug-in.[ch]
 * libgimp/gimp.c: added support for the init function in plug-ins 
 (fixes bug #66859).
Comment 4 Raphaël Quinet 2003-06-20 17:48:01 UTC
A partial fix for Win32 (using some #ifdefs) is part of the stable
release 1.2.4.  See Tor's ChangeLog entry on 2003-02-11 for details.
Closing this bug.