I don't know too much details about actually writing a GEGL plugin but I think the main reason for interest is ease of use.
if GEGL plugin involves having to compile then I think that's why people are hesitant at least it is for me.
I am guessing it's written in C? If so if there's a way to make a plugin in C that accepts dynamic chains in some format that and expose that to Python Fu.
Then Python Fu can call that and it could chain it dynamically then I guess there would be way more interest.
I don't know just my take on it.

I showed a Gimp dev your message and he told me it is possible to pass python stuff to GEGL, but didn't explain how. Remember I make all my GEGL plugins not by "coding in C via knowing the math of pixels" but just chaining GEGL nodes and GEGL composers in a designated area I dub "the playground".

This is "the playground" template where GEGL nodes and GEGL composers are orchestrated. It involves no math or no advance programming skills.

I asked GPT and it said that we can compile the GEGL plugin into an .so file and put that in the plug-in folder
and that once that's successful it's registered in the pdb.
Then python fu can call it.
It's the compiling something in c that is proper format that I am unsure about.
But if that's done. Then it's a matter how we want to design the communication from python fu to that registered pdb call.

wow, the AI was correct on that. MySys2 is how you compile my plugins on Windows. I'm sorry they are much harder on Windows. On Linux they compile so much easier. Also it is likely chatCPT got that information directly from me and my post scattered throughout the internet.

I asked ChatGPT about dynamic c code execution and it said that it's slightly slower due to overhead in having to compile the code at run time. but its advantage is it can be dynamic. That was what I aiming to get at. It mentioned LLVM (Low Level Virtual Machine).
What I really wanted was some way for me to just change code on the fly without having recompile.
So even if a C plugin can accept this dynamic code from python which is also C code then it'll be a good interface for playing more because then Python can be changed without having to recompile that C plugin ever again. But ChatGPT also mentioned about security risks exposed because python can pass bad intent code... well that was expected. But I mean python code can already do harm on its own since it's runs code on your computer. But if python can change what kind of C code it passes into this C plug-in then we have something that's sort of like C scripting since it can be changed without recompiling the C plugin...

Chat GPT Gave me all this just in case anyone wants to venture into compiling a C plug-in that executes dynamic code:
1. Install LLVM:
Ensure that you have LLVM installed on your system. The steps for installation depend on your operating system.

2. Write a C Program:
c
Copy code
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <llvm-c/Core.h>
#include <llvm-c/ExecutionEngine.h>
#include <llvm-c/Target.h>

int main() {
// The C code to execute
const char* cCode = "int add(int a, int b) { return a + b; }";

// Initialize LLVM
LLVMInitializeNativeTarget();
LLVMInitializeNativeAsmPrinter();

// Create an LLVM module and JIT engine
LLVMModuleRef mod = LLVMModuleCreateWithName("dynamic_module");
LLVMExecutionEngineRef engine;

char *error = NULL;
if (LLVMCreateExecutionEngineForModule(&engine, mod, &error) != 0) {
fprintf(stderr, "Could not create execution engine: %s\n", error);
LLVMDisposeMessage(error);
exit(1);
}

// Generate a simple function with the provided C code
LLVMValueRef mainFunc = LLVMParseBitcode(mod, (const uint8_t *)cCode, strlen(cCode), NULL, NULL);

// Execute the function (if it exists)
if (mainFunc != NULL) {
LLVMGenericValueRef result = LLVMRunFunction(engine, mainFunc, 0, NULL);
printf("Result: %lld\n", LLVMGenericValueToInt(result, 0));
} else {
fprintf(stderr, "Failed to parse C code\n");
}

// Clean up LLVM resources
LLVMDisposeModule(mod);
LLVMDisposeExecutionEngine(engine);

return 0;
}
3. Compile and Run:
Compile the program and run it. Ensure that the LLVM libraries are linked during compilation.

bash
Copy code
gcc -o dynamic_execution dynamic_execution.c -lLLVM
./dynamic_execution
This example dynamically executes the C code int add(int a, int b) { return a + b; }. Note that this is a simple example, and you would need more sophisticated error handling and validation for real-world scenarios.

Keep in mind that dynamically executing arbitrary C code poses security risks, and it's crucial to validate and sanitize input thoroughly to prevent code injection attacks. Also, ensure that you have proper error handling in place for various stages of the dynamic code generation and execution process.

Gimp nor GEGL can't read GEGL .c files. Only binaries are accessible. In the future I hope they can read .c files instead of binaries only, as that is the spirit of FOSS

But isn't .GEGL files in c and compired using C? so if you make it dynamic and just include dynamic code as specified then compile it then when it runs it reads the dynamic code? Not sure.

Update:
does C have eval function like python
ChatGPT
No, C does not have an eval function like Python.

In Python, eval() is a built-in function that takes a string and executes it as Python code. This can be very powerful but also potentially dangerous, especially if the input is not sanitized properly, as it allows arbitrary code execution.

C, being a compiled language, doesn't have such an eval function because it doesn't interpret strings as code at runtime like Python does. C code is compiled into machine code before execution, so there's no direct equivalent to eval in C.

However, C can achieve similar functionality using techniques like dynamic loading of shared libraries or embedding interpreters like Lua or Python into C programs. These techniques allow you to execute code dynamically at runtime, but they are more complex and less commonly used than eval in Python. Additionally, they come with their own set of security considerations.

I don't think its possible because Gimp's core libraries for GEGL use binaries too to load native GEGL filters. I sent your message to a gimp dev to see what he says. I too hope in the future it is possible to run GEGL plugins through .c files instead of binaries, as that is more transparent and in the spirit of open source but right now in this part of history it is likely not possible.

In the mean time while we wait for the day that GEGL can read .c files, we should occupy more important things like studying GEGL node chaining in Gimp's GEGL graph and making very simple basic GEGL plugins based on the graphs we find.

said Gimp dev responded

C files do indeed need to be compiled, and a compiler is a major piece of code. There are C interpreters, but they run very slowly (probably between 10 and a thousand times more slowly than compiled C for image processing) and aren't really designed for this sort of use.

GEGL plug-ins are indeed shared libraries (.so files, or .dll) that are loaded dynamically.

So yeah... it looks like it could be done but it would be 10 to 10000 times slower. I don't even know how to do it btw.

Last week I made a new discovery on making GEGL plugins, and apparently someone from GNOME knew this trick back in 2013. Despite any public documentation of it.

I looked at the source code of GEGL's Gaussian Blur filter, something I had done long before.
During my previous look at gegl:gaussian-blur 's code I knew it was based on two gegl:gblur-1d being set horizontal and vertical. The stuff about gaussian blur is irrelevant to my discovery.

However just a few weeks ago I realized the nodes in the .c file were only listed once instead of twice. I didn't know this was possible. So in my latest filter that applies on a layer mask. I took note of gaussian-blur's .c file and made it where the code in my new filter only list nodes once instead of twice.

Example of required GEGL nodes being listed once (new discovery)



Example of GEGL nodes being listed twice. (The way I've been doing things)




What is the major difference?


is put in front of every filter instead of a list like


This means it is EVEN EASIER to make a GEGL plugin.