Hi David,
I was looking into some of my old filters written using Gimp-G'MIC interface to see whether they could be updated to the new interface.
After having changed:
- the name of the interface itself (to pdb.plug_in_gmic_qt)
- the prefix of the gimp filters ((from gimp to fx)
one of my filters went to the normal end (no errors) but the result was not as I was expecting.
Going thru the source I discovered that I was using the "blend(standard)" filter and I discovered also that the various blend options have been increased (at least from when I originally wrote my filter), which is per se an excellent fact, but now the integer number used to specify which one to use has been changed: I had 42 for "vivid light", and this one is now "50". I was lucky I had a comment in my filter specifying I was using "vivid light" so I could change the number easily.

Now comes my question to you:
- because the extension of possibilities is always positive, but
- the incompatibility with written existing filters is always negative (and sometimes also difficult to discover)
may I suggest you to introduce tables of "equivalences" between a constant and a number, so in the specific case it could be possible to use something like "BLEND_VIVID_LIGHT" instead of the number 50 ?
I'm obviously referring to all the various options in the various filters.

Note that this possibility was available even in the old old Assembler Language, very close to the machine Language, thus is not a new invention by me.

If you worry about having those tables always included in each release, you may think about external tables loadable by the users who do like to use them (maybe the filter can mention its use by a kind of "include" stmt).

What do you think about?

Hello dinasset.
I think I'll tell you what I had already told in the past, but there it is :

G'MIC commands starting with '-fx_...' are intended to be filters defined for the GIMP/Krita plug-in, an due to the update mechanism, they are intended to be updated from time to time. There are no ways we can guarantee that a call to a command like '-fx...' will work in the future. If it was the case, then that would mean no filters can evolve anymore in the plug-in.

So, my strong advice (which I already told here and here) is : Never use calls to G'MIC commands starting with '-fx...' in your own scripts if you want to ensure the stability of your script over time. These commands are changing over time, they don't define a stable API by nature!
I mean, most of the other G'MIC commands have a stable and reliable API, so why not using those instead ?

If you want to blend two images together, why not using the command -blend instead ? This commands takes as an argument the blending mode, not as a number, but as a string, e.g. -blend[0,1] vividlight.
So, please use the command '-blend' (the natural way of blending images in G'MIC) and not the command '-fx_blend' (the command name used in the plug-in) and you won't get troubles anymore.

The issue is that maybe you try to design scripts without really knowing how the G'MIC syntax work : you apply a G'MIC filter on an image, and copy/paste the used G'MIC command (output as the layer name for instance) in your script. This works of course, but this shouldn't the way to do it properly.
I mean, in the sense that this technique will certainly work for a short amount of time, so it is good when you want for example to batch a lot of files right now, but this can be only seen as a short time way of doing it. If you really want to write permanent scripts, that's not the way of doing, as you may have noticed with all the issues you got doing like that

To sum up : commands starting as '-fx...' are volatile by nature, you should avoid using them as much as possible in your own scripts.
In a few cases, it may be not possible, but in that case, prepare yourself to have to update your scripts in case the filter command you use is updated.

Your answer (as you says) tells me again what I already know, my question was much more specific:
- why can't G'MIC make use of EQU tables to look up for translating a constant (you may define some specific initial character(s) to identify it) into a number?
It' s a so old technique, in many programming languages, even those 40 years old...
Is this so disturbing? I'm sure one of your students could implement this feature very quickly and easily.
Just my opinion.

I know how correspondence tables are working, don't be rude.
In that specific case anyway, no need for correspondence tables, as the command `-blend` you want to use does not take a number as a parameter, but a plain string describing the blending mode.
Try $ gmic -h blend, or go to : http://gmic.eu/reference.shtml#blend to see how this command works.

I didn't want to be rude, I know you know how EQU tables work, the fact is clearly that you refuse to use them. And I'm not talking specifically for the blend, this was only the initiating step. I'm talking of every options list.
There is a river between our mentalities, and unfortunately no bridge...

I use such tables when they are necessary.
For instance in command `-fx_blend` there is such a table used, to assign to an input number (the entry number) the selected blending mode, to be used as an argument for command `-blend`. Look on how this is done, and I'm sure you could then use a similar trick to write it in the other way if you think this is necessary.

See: https://raw.githubusercontent.com/dtsch ... tdlib.gmic (search for string 'fx_blend :').

Sorry if I bothered you, David.
It wasn't my intention.
My "question" was not a critique, nor a request to simplify my work.
I do not write filters embedding G'MIC since a while, as you know.
I'm an old (very old) man and simply I couldn't resist to write that suggestion.
Yes, it was simply a "pure" suggestion, aiming to improve some aspects of your "creature".
Usability.
User friendliness.
Compatibility.
Aspects of software development.
Not the least ones.
I understand you are still too deeply involved in writing new wonderful features.
Hence, you don't care for the moment of something outside the "internals".
Maybe one day, when you will be only the "manager" of the development group,
you could reconsider also those aspects.
Who knows. Spes ultima dea.
In closing this thread I only hope you don't remain of the idea of a critique.
Ciao, amico mio (if I'm allowed to call you as such).
Hope to get a better "ABS" for my mind...

(G'MIC is not particularly my creature, just to say..)
Apart from that:

Usability : We made tremendous efforts these last years to improve the usability of the plug-in, particularly with the new Qt-based version, the filter search engine, the resizable preview widget and so on...

User friendliness : This is somehow a vague term, but again, I think we haven't sacrificed anything in this domain.

Compatibility : I want you to realize that the API of most G'MIC commands have not changed for a while. I think you used G'MIC as it shouldn't be used, and so you got lot of troubles (I mean, using volatile commands by nature instead of stable ones, then complaining these commands do not work as before).

Contrary to what you suggest, we did a lot to 'please' our users. I personally don't use the plug-in at all, but only the command line interface for my work, so believe me, all the time I spent on improving/testing the plug-in and adding new filters (that I don't use at all) was mainly done for the users, not for me.