GEGL Plug-Ins for GIMP. Part Three: Writing C Plug-Ins

This is the third in a series of articles about GEGL plug-ins for the GIMP image editor. See also part one and part two for more about GEGL plug-ins and using them from inside GIMP.

You don’t need to know C to use this article, or be a programmer.

Note: you can also use GEGL plug-ins outside of GIMP, e.g. in the gegl command-line program and maybe even in GNOME-Photos, unless you use GIMP-specific features such as calling other GEGL operations that GIMP provides.

Why do it?

GEGL Plug-ins are super easy to use in GIMP with on-canvas preview, and you can even save and load settings. They are in the C programming language and are nice and fast, sometimes taking advantage of your graphics card or multi-threading.

Although you can write scripts for GIMP in Python, Schema, JavaScript, Lua, and maybe more languages, those scripts don’t get a preview at all, or just get a tiny one in a  pop-up window.

GEGL plug-ins can also be used as part of more complex GEGL graphs, like building blocks.

How hard is it?

Someone who hasn’t written any C before and isn’t a programmer can translate the GEGL Chain syntax shown in part two into C, with a little practice. You may need help from a C programmer if you get errors or get stuck. This article mentions some of the common errors, though.

Allow about an hour to turn a GEGL chain into a C plug-in the first time, and about another hour to get it to compile if you haven't done that before.

vi and emacs

Years ago as an undergraduate I spent a holiday working for a CAD/CAM software firm and used emacs there. The alternative was an ancient line editor on PR1MOS... so I got pretty used to emacs.

When I got back to University I was for a while a convert. It meant using the department's VAX in the evening, because emacs was banned in busy hours (it used to many system resources).

One day I was with some friends and happened on an insight that a block of C code should be in a loop. I logged in but, not wanting to keep people waiting, used vi to edit the code. There was already an if statement and I just needed to indent the block, so withot thinking I used the vi command >% to do that.

Afterwards I reflected. I had never indented a block using >% before. The reason I knew the command was not that I'd memorized thousands of weird keystrokes in case I ever needed them. It was because > is the vi command to indent by one tab stop, and % means from here to the matching bracket. I knew both of those separately and could do, for example, >L to indent every line from the current one to the bottom of the screen, or >1G to indent from here back to the start of a file, and I knew y% to yank (copy) from here to matching bracket, d% to delete, so >% just came naturally. It's a language, verb noun.

If I’d needed to do the same thing in emacs I'd have probably researched whether there was a command for it - not impossible but this was James Gosling’s emacs in 1983 or so, and it was still relatively minimal. When there wasn't, I'd have written a LISP function, documented it, added it to my personal library, bound it to a key, and, by this time, would have entirely forgotten why I wanted it.

For me, the simple clear language means I don’t need to think about editing, I can just do it. But maybe it’s more like the “Unix Philosophy” of having distinct commands that one can combine, rather than a few giant applications that don’t interact with each other, the dominant design pattern at the time.

It’s not about one being better than another, because people are individuals and different tools have different strengths and weaknesses for different people. You do have to learn a language with vi, and understand that it’s a language rather than just a set of weird and arbitrary commands, so the initial learning curve is much steeper than for, say, Windows Notepad. For me it was well worth it.