On the road to 3.0

OK, I’m interested by your command if you succeed in reproducing the crash !
Right now, I don’t think I can do something, with only the few clues provided.

Comprehensible!

What about my question concerning some sort of debug thread with gmic intepreter in the terminal? Do you think that is possible?

No that is not possible.
G’MIC used to have an interactive terminal a few years ago, but this was really not helpful at all, and a nightmare to make it user-friendly : this kind of interface requires actually a lot of attention, and is not simple to set up.
I won’t do it again.

The newer math parser commands are great! I already found inrange very handy. Is there some shorter way to reference a centred kernel as a vector? As it stands, it often ends up being done using crop(...) with what could be seen as “boiler plate” code. It works fine but I always want it shorter :slight_smile:

Hi Andy, good to know you’re around :slight_smile:
To have it shorter, you can still use a macro:

  eval "
    patch(x,y,N) = (
     const _N1 = int(N/2);
     crop(x - _N1,y - _N1,N,N)
   );

   V = patch(30,30,5);
   print(V);
  "

I suppose that could go in a personal “math library” of sorts. Had to spend time learning other things in a hurry… until recently could only look longingly at gmic stuff :smiley:

Edit: the case I’m thinking of is mostly during fill, where the centre is already at x,y (just a very common scenario).

Recently, sample has been taking longer than usual to retrieve an image. Unsure whether it has to do with my Windows refresh. Looks like gmic is downloading to the %TEMP% directory, which I am clearing regularly.

There was some updates by @PDN_GMIC though I’m not sure if he had anything to do with this.

Command sample indeed download the sample images from the G’MIC server, and put them in a temporary path (%TEMP% on Windows). If you clean it, then G’MIC will download the images again, and this can take some time (not that the images are big, but the web hosting server is usually slow :slight_smile: ).

Would it be possible to direct the download to gmic.exe's directory? In fact, I would prefer user.gmic to be there as well. I guess that may be too much of an ask but I will ask anyway. :slight_smile:

I don’t think that’s a good idea. The folders to store the G’MIC resources are different for each users, and gmic.exe may be installed at the same place for all users.
Moreover, the folder where gmic.exe is located has chances to be read-only, meaning no files could be saved there (even by gmic.exe).

I consider afre wish very good and justified - especially for the portable version of Gimp.
Probably even more difficult to do - is it possible to use another solution: let the user specify the directory for saving resources and updates?

It’s actually already possible to change the path used for the G’MIC resources, by setting the environement variable GMIC_PATH.

I could add an option for the ‘cache’ directory too, maybe. With environment variable GMIC_CACHE_PATH.

1 Like

A very good solution in this regard has Samj


Just edit the Parametres_Gimp_Lang.ini file (GMIC_Filters_Folder=GMIC_Filters).
I would like this option in every version of Gimp(you don’t have to edit environment variables - which can be too difficult for some beginner users anyway).
Maybe this code will help with something:
http://www.aljacom.com/~gimp/GIMP_Lang_Version_1.04-2.7z
Save to

Honestly, I think environment variables are the best solution to deal with the path of the G’MIC resources or cache folders.

If you allow people changing the configuration folder on the fly, via the plug-in “Settings” dialog, I can imagine all the mess that it would make : indeed, the plug-in stores configuration and qt-related files in this resources folder, while running. If you change it while the plug-in runs, there are high chances the plug-in would crash or at least behaves in a very weird way
(it’s an idea a bit like replacing your hard drive while your computer is reading/writing files from it).

On the contrary, if you make it wait for the next run to enable the location of the new folders, then you’ll get at least two different folders for the G’MIC resources on your HD (the old one, and the new one), which would be very confusing and error-prone. Do the user settings should be copied in the new folder ? Or not ? The favorites ? etc. What do we do with the old folder ? If we allow that, be sure we’ll get plenty of users having problems locating where there favorite filters are stored!

Clearly, the best solution would be to be able to set the resource folder path before the plug-in is run for the first time. And to do this, there are not much better solutions than using environment variables. They have been invented specifically for that kind of usage : pass a piece of information to an application, even before launching it.
If you tell me that on Windows, environment variables are hard to set… Well… I’d say, it’s not a problem with G’MIC, it’s a problem with Windows. It’s just yet another problem with Windows, I’d say.

It isn’t hard (as I showed in another thread for another reason). My last statement is due to there being multiple options and not knowing which one to choose yet. I will give it a go if you decide to add

It’s already done actually in command path_cache, so with the latest filter updates, you should be able to give a try.

You can just check it works, like this:

$ export GMIC_CACHE_PATH="hi guys/"
$ gmic path_cache e '${GMIC_CACHE_PATH}'
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ hi guys/
[gmic]-0./ End G'MIC interpreter.

(done from a bash terminal).

My current output is

[gmic]-0./ 'X:gmic-2.9.0-cli-win64'

Perhaps I need to escape my backslash…


Okay, I added an extra backslash.

[gmic]-0./ ‘X:\gmic-2.9.0-cli-win64’

However, it still downloads to %temp%. I wonder if I have to reboot or upgrade G’MIC. Or, I am setting the environment variables wrong.