GNOME Bugzilla – Bug 171831
Add Lua scipting capability
Last modified: 2018-05-24 11:29:47 UTC
Hello! I'm asking for adding Lua scripting ability to Gimp. Below is some detailed explanation for the request: I'm developer working in simulations/graphics field, and I'm using Gimp for many task, including some automatic processing of large quantities of image data. As API to Gimp I user Script-Fu, because it is portable between platforms (in opposite to Perl-fu) but much faster and easier than native C API. Also I love functional languages like Scheme, Gimp is the only one place where I use such kind of language, and it always pain to write Scheme because it is rarely used in real life, and have little similarities to more popular procedural and/or OO languages. As part of my job, I'm working with Lua language, which I use to add scripting capabilities to my applications, and it proven to be easy-to use both from point of view of script language integrator (me) and scripting capabilities users (sometimes also me). By introducing possibility to script in Lua, you can bring simplicity and ease a lot development of scripts, while not sacrificing portability of Script-Fu. The Lua itself is minimalistic embeddable procedural scripting language, written in pure ANSI C, which compiles and runs everywhere, and distributed as C library for embedding scripting Lua scripts into host C application. The syntax of Lua is simple and clean, and familiar to everyone with knowledge of any procedural programming language. The whole Lua interpretor and standard libraries is about ~350kb of C code, and can be merged into core Gimp source tree, without introducing additional external dependency. Comparing embedded Lua scripting to other options: Script-Fu - the main difference, is ease of use for most modern programmers. Both of them are 100% portable and (can be) embedded into Gimp without introducing external dependency. Both of them can happily coexist together. Perl-Fu/Python-Fu - Those are much more powerful languages than Script-Fu and Lua, but as consequence, they are large, not 100% portable and can not be distributed with core Gimp. If any additional info needed, feel free to contact me. Thanks, Pavel Antokoslky aka Zigmar
Are you looking for http://pippin.gimp.org/plug-ins/gluas/ ?
Hello! No. I'm familiar with "gluas" plugin. This plug-in allows playing with image data in terms of low-level (pixel-wise) API, for testing and visual debugging of image-processing alogithms. The plugin does not export Gimp API at all, nore allow integration of Lua scripts into Gimp (adding to menus, to procedural database, etc). I'm talking about integrating Lua as scripting language for core Gimp scripting, in the way Script-fu works now, so user can put script written eather in scheme or in lua to his .gimp/scripts folder and it will be automaticly loaded at startup. About licencing - Lua comes under very liberal MIT licence, which is compatible with GPL, and there should not be any legal issues for integrating Lua into Gimp.
Sure, feel free to add a Lua binding for GIMP. We don't have the resources to create new language bindings. We will however happily point our users to the Lua bindings when they exist.
If I will take the task of implementing Lua binding, is there any chance it could be integrated into core Gimp package? The reason I'm currently using Scheme for creating Gimp scripts, is portability, and it the only (although not most comfortable) way to ensure the plugin will run on every gimp installation on any platform. Until such binding will available native scripting, it almost useless, to me at least. I'm not fan of Lua language, just I know it's merits, and most valuable is the possibility merge the scripting engine completely into hosting application. For scripts I don't need to be portable and/or redistributable I could happily use existing Perl or Python binding.
There are currently plans to move the current scripting interfaces into standalone plug-ins. Script-Fu will eventually be replaced by Tiny-Fu during the transition, PyGIMP is supposed to be made available for Win32 soon, and GIMPPerl is separate. The idea is to have distributors bundle them with their GIMP distro or make them available a separate packages as well. If you want to create a Lua binding, you could probably use Tiny-Fu as an example.
Thanks. I've skipped through Timy-Fu code, and it seems like a good starting point. About PyGIMP, if I undertand you right, it is planned to be included into standart Windows and Unix distribution of Gimp, isn't it?
PyGIMP should be included by the distributors of GIMP (i.e. Debian, Redhat, GIMP-Win, Gimp.app, ...), but is supposed to be removed from the main source tree. It's more easy to handle if you don't have to build the whole GIMP just to enable another scripting interface.
So if Python binding will come with most distributions, I guess there will be no need for making Lua binding. But on other hands, as far as I saw, applications using Python scripting needing the Python package to be intalled on target machine. Is it will be a case with Gimp or it will include nessesary libraries in distribution? It usually no the problem on *nix, because most of them have already Python intalled, but it might be an issue on Windows machines, which typically does not have Python installed. In contrast, Lua binding can be distributed as single plug-in without external dependencies and with Lua interpretor statically linked into it, just like Tiny-Fu has TinyScheme interpretor built-in.
How the pygimp is packaged on Windows is completely up to whoever is doing the packaging. It can either depend on an existing runtime (which would make sense, since gimp on windows doesn't bundle gtk into its installer) or dist their own. I don't see how this is a big deal, people can just install whatever python runtime that's needed by the binaries they are installing.
Manish, I think you have missed the point of this enhancement request. It's perfectly ok with me to use Python as scripting issue, but my primary concern is portability. Believe me, most users won't bother searching and downloading additional package, until they absolutely have to. The users download GTK for windows, because they can not run Gimp without it, but they will not download Python just to be able to run few additional scripts. Even at my work, it could be very problematically to install additional package on every machine, and keep them up to date. That the reasons, why I use Scheme for writing scripts and Perl or Python - because the interpreter comes with every Gimp distribution and I can be quite that every Gimp user can use it. The only problem with Scheme scripts, is that they difficult to use for people having little experience with functional languages, and that is unfortunately majority of developers today, including me. And that where this request came from.
I was directly responding to your prior comment, not to the enhancement request. I feel this discussion is pretty much a moot point until a lua binding exists. Then packaging can be discussed.
There is a partial Lua binding somewhere, I think Øyvind Kolås mentioned it and has a tarball of it (no, I'm not talking about gluas).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/140.