Hello, I just installed gmic v1.8.0pre#010917 with Gimp 2.9.5 on Linux. Apart from the fact that nearly all my fav'ved filters show errors (so are unusable, including the added-to-favs Search filter), my personal section with adapted filters disappeared as well. I mean the entry that is created when I put the following lines in the hidden file .gimp.

#@gimp Photomat
...
#@gimp _

This is no fun as it was quite some work to make them. Double no fun because I wrote several articles on how to create your own gmic filters.

See https://paulsphotopalace.wordpress.com/ ... mp-part-i/

Is this a g'mic error or intended behaviour?

Regards, Paul.

Hello Paul.
You are right, there have been some important changes coming that introduce incompatibilities with the previous versions.
I'll take time to explain some important points about the next version 1.8.0 of G'MIC.

The big news is that the current G'MIC plug-in for GIMP is about to be replaced by another one, whose name could be "GRIP", as "G'MIC Roughly Into a Plug-in" :p
GRIP is a complete recoding of the current G'MIC plug-in, with the following properties :
- It is intended to be a "Universal G'MIC plug-in". Its code is mostly independent on the GIMP plug-in API, only a few lines of code allow to make the bridge between GRIP and GIMP. This means we intend to write the same kind of few lines to make the bridge between GRIP and other software hosts (Krita being the first on the list).
- GRIP is using Qt for its interface. The author of GRIP (Sébastien Fourey) is a colleague of mine, working at the same lab, and is mastering Qt enough to ensure we'll have a very nice interface for GRIP.
- GRIP manages its own preview widget, that is already better than the one provided by the GIMP widgets API (the one used in the current plug-in). For instance, you'll be able to resize it as you wish, etc..
- GRIP has a filter search engine included, so you just have to type a few letters of the filter name to make the matching filters appear in the current filter tree.
- GRIP remembers all the previous user settings so that when you relaunch it, even after some days, you'll get the same state of the user interface.
- And other improvements...

That being said, this also means we had to change some things in how the filters are defined in GRIP. For now, it uses essentially the same mechanism than before, except that mentions to 'gimp' have been removed. But more changes may be done in the future. The 1.8.0 release is not planed before a long time, to be honest. I regularly post some pre-versions as the development goes on, but only for testing purposes.

So right now, one easy solution would be to replace all the strings 'gimp_' by 'fx_' in your fave files (and .gmic files as well), and comments '#@gimp' becomes '#@gui'.
I guess these simple changes would work. The filters you define like this should then appear for all instances of the GRIP plug-in in the future (GIMP, Krita, ...).
The source code of GRIP is not available yet as it's still in alpha stage, but we'll try to release it as soon as possible. I've made the changes in the current GTK plug-in 'gmic_gimp' to reflect how GRIP will work though. Hence the changes you've noticed.

Just a pictorial view

Thanks James for always making things more clear than me
Also, a note about next plug-in version : in the future, installing two versions of the G'MIC plug-in for GIMP at the same time should be possible.

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; -:)

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 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.

Curious what GRIP will bring us!

Regards, Paul.

I'm assuming GRIP is what was announced as GAAP. Is that right, David? If so, then I wanna get a GRIP. lolol

As I understand it, GRIP is like a completely new plugin. My question then is does that mean G'MIC plugin will no longer be sustained? If so, hopefully redoing my customization won't be too much an issue.

Will this new Grip work with McGimp, and if so, will both the GMIC and Grip work, as the GMIC is natively included in McGimp.

David,

There is already nice free software, for astronomy, with the name GRIP:

http://www.grelf.net/
http://www.grelf.net/grip_intro.html
http://www.grelf.net/download_app.html



Is this a problem?

Latest proposal is "G'MIC Resources In a Plug-in", but feel free to propose new ideas



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.



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.



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.

I don't know, I hope the new version will replace the old plug-in.
If someone skilled enough is able to compile on Mac, then that should be OK

That's potentially a problem yes, we need to look at that more closely.
Thanks for the links !!

David, I edited my previous post, I added a link:

http://www.grelf.net/grip_intro.html

Here you can find the most info about GRIP

When will this be available?

I'll post new pre-release binaries for 1.8.0_pre today, with the ability to get G'MIC plug-in 1.7.9 and 1.8.0_pre at the same time.
The registration names of the plug-in make it easy for a script to know which version it invokes :

- Current stable version 1.7.9 still uses name 'plug-in-gmic', so that won't change anything for your scripts.
- Pre-release version 1.8.0 uses name 'plug-in-gmic180', so if you want to invoke this one in your script, that will need a change.

So, at least most of the existing scripts will continue to work with current stable version 1.7.9.

I say it again, but pre-release 1.8.0 is far from being the final version. And this will be a major release with a lot of new stuffs
(you can follow the changes here : https://discuss.pixls.us/t/on-the-road-to-gmic-1-8-0).
The release is not yet planed.

Hi David.
Thank You very much for the quick update Polish translation.
The number (plug-in-gmic180) for the new GMIC does not seem like a good option - because I think will change?
Is not it better to take something general for the name of the call (plug-in-gmic-all-in)?
Is the new version is expected to save (for the faves) different (selected) options Input/Output ?

Hi MareroQ,


Thanks to you !



What we've decided today is actually to change the version number of the next version to 2.0.0.
This will be a major release, so it seems natural to jump to a major version number.
Thus, the name of the call becomes (plug-in-gmic2), and this will be the case for all versions of the 2.x.y series.



That was not something we had in mind, but I've just asked Sébastien (the developer of the new plug-in) if this is possible,
and he told me he will do it. Thanks for the suggestion

No, finally 1.8.0 won't exist, it will be replaced by 2.0.0.
And no, it will not contain the older plug-in (but the binaries for 1.7.9 will still be available from the G'MIC website).