This is just a proof of concept,
It only has 4 recordable actions right now.
- change foreground color
- fill layer
- gaussian blur
- set active layer

You can combine any combinations of these actions (which you still can't do much) but it's just to show that this is extendable to cover many of callable functions so that you can record these actions.

1) You would run "01 New Recording" and specify a filename to save to.
2) Then run a series of of combinations of the 4 available functions. They would save to file specified in 1)
3) Then you can run "02 Run Recording" and select the filename you have entered in 1) and it would run all steps performed in step 2) (like replaying a recording)

color-coded diagram to show what options you have/can do with the predefined recordable actions.


download script from here --> Proof of concept recordable actions

Sorry, but IMHO your POC doesn't prove much.

1) You are not recording arbitrary Gimp actions, you are recording calls to your scripts.
2) To have any kind of useful coverage you will have to write hundreds of functions
3) And even then you'll always miss some (your user's pet script/plugin...) and this will make you script unusable to record his/her usual workflows (would you take a freeway that stops in the middle of the desert before you reach your destination?).

Writing code for every single action isn't a sustainable model. What you can try to do is use what programmers call "introspection", ie some technique through which the code looks at itself and figures out how to use some other parts. In your case, this would be writing code that grabs the PDB and pluginrc file, and uses them to determine the parameters to the calls and automatically/dynamically create your actions around these. And then write a usable UI to select among all these functions and feed the parameters.

But then your users will just be writing code without knowing it, instead of typing in lines of Python, they would be
clicking away...

it was just a concept for people to not have to learn how to write scripts.
To really record actions I would have to have access to the history which i don't think gimp provides.

what you're describing sounds way above my head

I would be happy with a gui approach, ofnuts. Beats typing lines of code. lol

Yes, I understand that... But you won't get far if you have to "manually" write every action. You have to generate them automatically, first on your computer, and then if possible on you user's computer (to take in account scripts and plugin that are only found there).

I don't think i am able to generate an automated way that is friendly at the same time.
I don't think i am able to but if i was able to
It would just be a graphical way generate code and the user would still have to refer to documentation for pdb.calls parameters.

Like most people, you think the programmer's work is typing (cryptic, in your eyes) code. Since the invention of the computers people have tried to remove the programmers (Cobol, RPG, Visual-whatever...). And it's still a flourishing corporation because their added value is elsewhere. A programmer is someone who seeks and finds logic in the mayhem, and transforms a fuzzy and hairy problem into something simple and clearly defined. And this is true whether the final product is typed in(*) using a programming language or built using a very graphical UI. The people who can use the GUI thikng efficiently are the same that can write "typed in" code. Or looking at it from the other end, if you can use the GUI app efficiently, the only thing that prevents you from writing good code is shyness.

(*) in practice programmers don't type much code, the average programmer produces 100 lines of working code per day. This is roughly the same amount of text than in a page of a company memo (but it usually requires a lot more thinking).

I strong agree with shyness. It's that damn shyness that prevents many people from doing many things that they don't do, programming-wise and other fields-wise. damn you shyness (Shake fist at sky).

Use to like programming my HP28S (RPN) in college. Created all kinds of programs on it including a fully functional (though extremely slow) Hebbian neural net character identifier (did my senior design project on neural networks; this had nothing to do with the project I was on; just was personally challenged to try it; lol) as well as square root test prime number extractor (used recursion which made it really quick relatively speaking) and perpetual calendar. Just lost the desire to program when I actually became an EE (hated fortran and didn't really care too much for assembler either).