I've lately been thinking the possibility of writing a plugin in Vala. I'm just wondering if anyone knows of any resources, tutorials or such that could help with that? Has anyone done this before, and if so I'd like to look at the source for an example?

No, it is not possible. The scripting language must be closely adapted to gimp, so that the procedural database can be accessed by the script. Otherwise, functions and procedures from gimp cannot be run by the script.
I have never heard from a try to adapt Vala to gimp.

I'm not talking about writing a script, I'm talking about writing a real gimp plugin. Vala is a compiled language, not a scripting language.

Furthermore, Vala compiles to C and uses the same GObject type system that Gimp uses, so it should be totally possible to write plugins for Gimp with it.

You are not likely to get any support for this. There was a long discussion about this 2 years ago. It died then.

Well, maybe it's time to start that discussion again. It should technically already be totally possible, since it is possible to write GIMP plugins in C, and Vala compiles to C. And Vala is built around GObject, which Gimp also uses. I know there was even some talk withing the Gimp devs about porting some plugins to Vala some time ago. So it's not like this is a totally far-out idea.

It should be possible, but maybe not entirely in vala code. You might have to write a mini interface of some kind in C. But "you" is the word to emphasise...

You are correct in characterizing what you want to do as writing a plug-in; however, it should be noted that the distinction between a script and a plug-in has nothing to do with whether the code is compiled. Plug-ins execute "outside" of GIMP and interface with GIMP functions through the PDB and libgimp. Scripts are written in Scheme and interpreted by GIMP's built-in Script-fu interpreter. A filter written in Python is still a plug-in; even though its code may be interpreted, it is interpreted "outside" of GIMP.

GIMP's plug-in/PDB functionality does not use the GObject type system; to write plug-ins in Vala, when calling PDB/libgimp functions, you will need to convert your GObject parameters to their corresponding PDB arguments (and conversely for the return values). Your task is simplified by the fact that there is a great deal of similarity between the two types, but the data objects are not the same.

To write a plug-in in VALA, you would need to implement at least the following functionality:

Create a C GimpPlugInInfo struct that contains pointers to four "callback" procedures: INIT, QUIT, QUERY, and RUN. 'RUN' is typically the only one that is actually needed (the rest can be NULLs).

Define your four callbacks, or at least the ones you are using (e.g., just RUN). The first three procedures don't accept any parameters, while RUN is expected to handle the following arguments: name, number_of_parameters, list_of_parameters, number_of_return_values, and a list_of_return_values. See libgimp/gimp.h for more details.

Call the C function 'gimp_main()', passing it the GimpPlugInfo struct you created, as well as argc and argv. (NOTE: because Microsoft requires some additional information for setting up the "gimp_main" process, this approach will not work on Windows. I don't quite know how this would be accomplished in Vala but you could look at the MAIN macro in libgimp/gimp.h to see how it is done in C). This gimp_main() function is effectively an "event loop" that waits for messages from GIMP and executes the corresponding callback function (INIT, QUIT, QUERY, RUN) when received; in a manner similar to how gtk_main or GMainloop work for graphics/glib programming.

In addition to the above, you will need a binding to the 'gimp_install_procedure()' C function, so you can install your plug-in. This function takes a set of arguments similar to the ones passed to your RUN callback, but with additional arguments for the help blurb, author, copyright, data. menu placement, and menu constraints. Again, see libgimp/gimp.h for further details.

Finally, you will need to implement 'gimp_run_procedure()' in Vala (i.e., create a binding to the C function) so that you can invoke the RUN callbacks of other PDB functions. The arguments passed to 'gimp_run_procedure()' need to match the parameters expected by the PDB procedure you are calling.

That is the gist of how you'd write a GIMP plug-in in Vala (or any other language). However, you will likely want to create some Vala-specific helper functions or else your code would need to be written similar to the following (which is a simple call to create a new image):



That is obviously not how you'd want to write a plug-in!

The task of going through the PDB and autogenerating Vala templates for each of the procedures is conceptually trivial (you'd need a binding to 'gimp_procedural_db-query()') but it is something you'd only want to be done once -- you wouldn't want every Vala plug-in written to declare all the possible data types and generate all of the PDB procedure templates. Therefore you'd write a Vala extension to GIMP, just as people have written extensions for Python, Perl, and various other languages.

Should you decide to tackle this problem, the above will hopefully prove helpful in getting you started. It is obviously not an impossible task, but it is also not something you're likely to finish in a weekend.

Also, I might suggest an alternative that is a bit larger in scope, but in the long run should prove of greater benefit to the GIMP project as a whole. That would be to convert the entire GIMP PDB/plug-in interface to use DBUS instead -- or at least write a DBUS wrapper for libgimp/PDB. I believe that if this were done than your Vala interface would become almost trivial because DBUS does use the same GObject system for data and facilitates procedure calls between processes. Just a thought.

Now that's a conversation stopper
Thanks for all the info though, hopefully somebody takes it on!

Whoa, that's some heavy text indeed... may be I'll look into it, but might be some of that stuff is a bit beyond my skill (coding is just a hobby for me, I'm not a professional or anything)... not that that's ever stopped me from attempting to do stuff before, but anyway...

Thanks saul, that's very helpful. At least now I know where to start and what it takes. It might actually be easier to just go for C, at least when it comes to writing a single plugin. I might do that so that I get more familiar with how the plugin system works (some of it is already familiar to me from python).

Also, I wasn't aware that GIMP didn't use GObject. For some reason I just sort of assumed that it did, since it uses GTK and GTK uses GObject... well, to me it would make sense to use the same type system in GIMP, but then I'm not a GIMP dev and they probably know better.

GIMP does use the GObject system (heavily), however, it does not use it for the plug-in interface. The plug-in system was implemented about five years before the GObject system. The GObject system was based upon the GTKobject system, which was created by the GIMP developers.

GIMP's plug-in system was very innovative at the time (~1996) and while object type systems were fairly common in other languages, GTKobject (~1999) was one of the first generalized object systems of its kind for C. The GObject system was first introduction around 2002 (so I think the GIMP developers should be forgiven for not using back in 1996 ).

Yeah, that makes sense.