paulmat wrote:
Hello David,
Your instructions worked, so my filters are working again, thanks! And James, thanks as well for your help.
Okay, so GRIP means actually G'MIC Rest In Peace; -:)
Latest proposal is "G'MIC Resources In a Plug-in", but feel free to propose new ideas
Quote:
One thing I hope for with the new approach is that a certain filter keeps stable over time. I combined a couple of filters into a single 'new' one and even before this upgrade to 1.8.0_pre quite some functionality was broken over time, including with some fav'ved filters. I guess that comes from slightly different filter names or some added options or whatever.
What I usually say is that a G'MIC filter should avoid invoking a command that corresponds to another filter in the plug-in (so, previously commands starting with '-gimp_', and now by '-fx_'). That is because the filter update mechanism has been made specifically to make those filters evolve over time, so the risk of having a signature or functionality changes for these commands is quite high.
My point of view on this, is that one cannot ask to have the possibility to update/correct filters, add new features without re-installation, and so on... and at the same time, asking for a stability of the plug-in filters API. These two requests are exactly the opposite one from the other. Dinasset had exactly the same kind of issues, and I understand this can be discouraging, but just don't use '-gimp_*' and '-fx_*' commands, and you won't have this issue. All the other G'MIC commands have usually a quite stable API, so it's really better to use them instead, when possible.
If it's not possible, then I'd suggest you copy/paste the version of a '-fx_*' command at current time T somewhere, rename it, and use it in your own .gmic file, so you ensure you will keep a stable API for this particular command.
I can't keep a track of all filter changes over time, and preserve old commands. If I do so, the size of the update file that the user has to download would simply explode, as changes are done quite regularly. I think that the updates for the plug-in filters must benefit for the regular user of the plug-in first. People who use those filters in their own scripts don't have priority, particularly because they can do things cleanly and backup sources of a particular filter if necessary.
A clean filter for the plug-in would be then a filter that does not invoke another filter of the plug-in.
That's how I think it should be.
Quote:
What makes me think that constructing your own filters might basically be a waste of time. For the moment it is better to use the filters as they are and 'fav' them for quick access, as long as that works. I will take the articles I wrote about this subject offline and will rewrite them (that is with the correct gmic code) later on, when v1.8 is generalized.
I don't think this is a waste of time. If you take care of a few things, there are no reasons why this shouldn't work for a long time.
Quote:
Curious what GRIP will bring us!
Regards, Paul.
I'm curious too, and I have great expectations
In any case, I've coded something today to allow the use of versions 1.8.0_pre and 1.7.9 of the G'MIC plug-in for GIMP, at the same time.
This should help providing a compatibility between the different versions. We already don't update 1.7.9 filter definitions anymore, so you can
consider that the 1.7.9 plug-in API is stable now
Cheers,
David.