Change:
<ins> # Krita {#sec-krita} ## Python plugins {#krita-python-plugins} "pykrita" plugins should be installed following [Krita's manual](https://docs.krita.org/en/user_manual/python_scripting/install_custom_python_plugin.html). This generally involves extracting the extension to `~/.local/share/krita/pykrita/`. ## Binary plugins {#krita-binary-plugins} Binary plugins are Dynamically Linked Libraries to be loaded by Krita. _Note: You most likely won't need to deal with binary plugins, all known plugins are bundled and enabled by default._ ### Installing binary plugins {#krita-install-binary-plugins} You can choose what plugins are added to Krita by overriding the `binaryPlugins` attribute. If you want to add plugins instead of replacing, you can read the list of previous plugins via `pkgs.krita.binaryPlugins`: ```nix (pkgs.krita.override (old: { binaryPlugins = old.binaryPlugins ++ [ your-plugin ]; })) ``` ### Example structure of a binary plugin {#krita-binary-plugin-structure} ``` /nix/store/00000000000000000000000000000000-krita-plugin-example-1.2.3 └── lib └── kritaplugins └── krita_example.so ``` </ins>

Discussion:
Krita 5 complains that it cannot find the G'Mic plugin. Steps to reproduce the behavior: Krita and the G'Mic plugin by adding and to in Krita a new image the menu item Filter→Start G'MIC-Qt will complain, via a modal dialog, that it cannot load the plugin. the menu item Settings→Configure Krita… should be a "G’Mic plugin" section in the left-hand sidebar, but there is not. For there to be a Krita setting to specify the path to the G'Mic plugin. The explains the correct behaviour.
Starting from the package won't work with Krita. Krita team forked and Krita will only work with that fork: It would take some effort to implement the build process mentioned in the README since cmake and make need to be invoked multiple times. (Probably need to manually write the whole and )
Is it possible to maintain a separate krita-gmic package like arch linux does?
It is possible but making it a separate package probably wouldn't make it easier to implement. We just need someone to implement the build process I linked above in nix (sorry I don't have time to do it)
Making some minor changes to you can build the krita plugin: I've not yet been able to have krita load the plugin though. I've tried creating a symlinkJoin'ed version with the plugin, that does not work :confused: Krita is not logging enough information about where it tried to load the plugin for me to be able to deduce what is going wrong.
Do you think the Krita fork of gmic-qt should be integrated in the definition at ? I was originally afraid modifying it now would not be worth it because the two versions might deviate too much from one another.
If you want to remove the original gmic-qt and change it to krita's fork, I believe it will conflict with the previous one, and I would therefore vote against it If you want to keep the fork along with the original, it's fine! You can use overrideAttrs magic in order to reuse the previous expression. Look at as an example for inspiration.
Option 1 is terrible, I'd never ask for that :smiley:.

I was asking if krita's gmic-qt should be included as a "variant" in , effectively does the same as option 2 <details<summaryLike this</summary</detailsI think it's best to keep it as a completely separate package, because both packages will never have matching versions.
So close! I got the "Q'MIC-qt for Krita" window to open by manipulating : ! Unfortunately it segfaults the moment I try to use any of the filters: Progress at