parse_gui command broken?

I am currently in the process of revamping and updating the OpenFX plugin integration for G’MIC and I thought maybe it makes sense to use the output of the new “parse_gui” command to make parsing the command and parameters easier, e.g. when provided in JSON format.
But testing with the latest 2.9.2 binaries under Windows, I can’t get the command to work. From the sources I see that “param_gui” can be called with two parameters, the first one the filters to match (with the default “*” matching all filters) and the second one the desired output module (e.g. “json”, “list”, “print”, etc.)
But the command seems to use the first parameter as both filter and output mode it seems, so I can’t get any way to output for example the filter list in JSON format. This should be done with this command I think: "gmic parse_gui ,json" but all I get is this:
[gmic]-0./ Start G’MIC interpreter.
[gmic]-0./ Parse ‘#@gui’ filters '
’ and output in ‘json’ mode.

Parsing done!
[gmic]-0./parse_gui/ Input file ‘parse_gui_’ at position 0
[gmic]-0./parse_gui/ *** Error *** Unknown command or filename 'parse_gui_
’; did you mean ‘parse_gui’?

Calling it as “gmic parse_gui blur,jason” results in this:
[gmic]-0./ Start G’MIC interpreter.
[gmic]-0./ Parse ‘#@gui’ filters ‘blur’ and output in ‘json’ mode.
[gmic] *** Error in ./parse_gui/ *** Command ‘parse_gui’: Invalid output mode ‘blur’.
Judging by the last line, “blur” is also taken as the output mode?
Can anyone advise?

I checked the JSON output that is provided by GMIC online here:
It does not contain the preview_commands and the hidden/disabled status of the parameters, can this be added?

Yes, sorry, but the order of arguments of command parse_gui have been switched recently, so now, the output mode is the first parameter : parse_gui json is OK.

Yes probably. The JSON output mode has been requested by @myselfhimself, and the preview_commands were not a useful information for him.

Unfortunately, switching parameters won’t work, that is the first I tried. It seems it still uses the first parameter as the search string and also as the output mode. Look here:
gmic parse_gui json
[gmic]-0./ Start G’MIC interpreter.
[gmic]-0./ Parse ‘#@gui’ filters ‘json’ and output in ‘*’ mode.
[gmic]-0./ End G’MIC interpreter.

My fault, I forgot to switch the arguments in the description. I’ll fix the description.
Anyway, apart from that, it seems to work for me, with

$ gmic parse_gui json ot output.json

Oh, weird, it runs correctly now in the latest 2.9.2 binaries, but not with the gmic.exe I compiled myself with Visual Studio. :frowning:

strange as parse_gui is implemented in G’MIC language as @David_Tschumperle had told me… maybe your lib uses a different home cache path than your executable, where the gmic files are kept and their upgrades downloaded side by side ?

I am sorry for having omitted that. Anything that is nice for building other UIs anywhere would be good in the JSON.
Not sure what preview_commands are, but they or other type of trackable example, could be used for non-regression testing of filters… Though this is a bit brainfuck, especially for community filters…

I am not using a lib, but directly compiling the gmic.exe executable. I put it with a different name next to the official gmic.exe from the latest binary release, so I don’t think they use different datasets, it is more likely something went wrong when compiling my version.

1 Like

Ah, I was using the latest 2.9.3 sources - when reverting back to the stable 2.9.2 sources, it will now parser correctly, phew!

1 Like

That’s not good news. It means a change between 2.9.2 and 2.93 changes the (correct) behavior of parse_gui into something wrong ?

It was not just parse_gui, a lot of other things were broken on my binary when I compiled the 2.9.3 sources, like “gmic help” not displaying anything at all. “gmic demos” worked normally though. No idea what was different, but I’ll stick to 2.9.2 for now.

One more question to @David_Tschumperle:
Will the filter list in JSON format be part of each release or at least made available online?
I stumble upon this page:
There it claims that the JSON list will always be available under:
(or the appropriate version), but this URL gives a 404?

The correct URL is :, where XXX is the version number with 3 digits. This file is update every hour.

So, current one is:

Great, thanks!
Since I am on the 2.9.2 sources at the moment, I assume I should only use the update292.json, right? As the interal G’MIC updater will also look up only update292.gmic, since that is the version number it was compiled with.
I have extended the libcgmic library with a function to return the G’MIC version it was compiled with so this information is available to the caller/host and it can load the right JSON file.

Yes, actually the JSON file is duplicated and uploaded for each version number that remains compatible with the latest version. Currently, version 2.9.0, 2.9.1, 2.9.2 and 2.9.3_pre are compatible so they all have the same JSON file (but with different URLs).

OK then I will update my Gist

So happy that someone visits this Gist :slight_smile: !!

so actually the gmic_version “2.9.0” key value has the meaning of last-compatible version for commands exposed in this json?
if so should not we rename it to gmic_version_min or so?

I am a bit confused with the update process/file itself.
If I run gmic parse_gui on a vanilla G’MIC 2.9.2 installation, the parser runs, but I get no results. I first have to run “gmic update” to actually download the update292.gmic file, then the parse_gui command works as expected.
I always thought the updatexyz.gmic files were for commands that have been introduced after a binary release x.y.z, but that is apparently not the case?
Even older commands like “fx_gb_cfx” will only work after running the update first. Can anyone please enlighten me here?
Isn’t the most current standard G’MIC library included with each G’MIC binary build?

No, it’s actually the version number of G’MIC that produced the json file. It’s not that useful, I admit.

1 Like