As the topic’s name suggests - neither repo version nor krita-git from aur have GMIC bundled. I haven’t built from sources manually to know how to trigger building/installing an “integrated” version. I know it is a job for a packager and he is already informed, but I’m leaving a note here because it can happen that someone searches for the problem in Forums too.
1 Like
Please try to use the AppImage from Krita’s homepage, not your repository.
Michelist
Already tried it, it works. It’s just that I hate Appimages… I’m talking here about the “regular” method.
The problem with the “regular method” is that the providers of these offers often do not include the specially patched Qt packages and other things do not work because they have overlooked something, as you can see with you, because they seem to be careless when creating the packages, in the AppImage, on the other hand, you have everything you need “on board”.
So this “regular method” is not always the wisest.
But this is only my opinion, I am not a Linux expert.
Michelist
1 Like
The regular method is to just install g’mic from their repo. While there is a g’mic integration in krita, both are independent programs, you can even use g’mic without Krita installed. From a package maintainer perspective it makes sense to not bundle them (perhaps list it as optional dependency like some packages do with plug-ins and stuff).
1 Like
This is now a problem for most rolling release distros. I have seen this with Opensuse and Arch and one more. Here is the bug report for Arch - FS#73132 : [krita] G'Mic doesn't start
The issue is that Krita now integrates Gmic as an internal plugin. The GMIC package is patched to make it an internal plugin in krita. The Source code for the fork is hosted with KDE. The packagers of distro have not found a way to build this or sometime may not be willing to integrate it since they will think this is duplication on Krita side.
Some distro packagers have reached out and hopefully there will be some solutions. For now use the appimage please.
I see. Didn’t know Krita has its own g’mic now. I wonder why that is.
You can read the details about it here → 424514 Plugin-ification of GMic (!581) · Merge requests · Graphics / Krita · GitLab and here → Add Krita plugin by amyspark · Pull Request #102 · c-koi/gmic-qt · GitHub
1 Like
If anyone knows how to include the patched GMic into a Krita 5 build, I’m all ears. I can’t find the “recipe” needed to create the AppImage for hints on how to do it.
G’mic is included in Krita 5, the AppImage can be downloaded from Krita’s homepage. You have to mark it as executable in its properties, and then you can use it like any other software.
Michelist
The AppImage works just as advertised, but I’m running a custom version of Krita 5 that has many modifications to C++ source code that I use for my workflow. I’d just like to know how to build the AppImage myself so I can include my custom code and bring back GMic support.
@gumdrops: Then it would be best to ask this question in “Develop >> Developer Questions”, there you will gain more attention for such a problem, at least in my eyes.
Michelist
Add: @raghukamath can you cut this out of this topic and move it to Developer Questions, or should @gumdrops better start a completely new topic for this?
New topic is fine
1 Like
Appimage is the worst choice, it’s much slower and cause many performance and theming problems, why did you decided to break integration with external gmic plugin ? if you decided to integrate it internally at least provide a general linux binary with gmic totally compiled and embedded inside it. I don’t know any popular app which had great success with Appimage or Snap or Flatpak.
Because it used shared memory to communicate with the host application, because it was originally designed to work as a GIMP plugin, and GIMP plugins do that.
However, as an approach shared memory is broken on several other platforms, so we had to find a different solution. Now we have a forked gmic-qt plugin, because the gmic-qt maintainers don’t want to accept our changes up-stream, and that is the reason linux distributions have trouble building the plugin.
And, no appimage is not the worst choice on Linux: it contains fixes for many of Krita’s depedencies that you don’t get with distribution packages. And as for appimages… They work great for us, great for godot, great for a lot of super-popular packages.
3 Likes
Yes you have the choice to use the binary distributed by your distro. It is a valid request. We do not package Krita for any distribution. The packaging is done by the distribution. This is not a bug we can fix. Please file a bug report to your distribution to package Krita with GMIC. If they have an issue they can come talk to the devs about the issue or tell us the difficulties. If there is no communication from the packagers this problem won’t be solved.
3 Likes
I use Manjaro and the Arch package maintainer stated in the link provided above that the problem is coming from you that decided to accept only your internal gmic tool, and for arch based distro appimages are really slow and are not preferred, the external gmic package can be still provided if you open the door for it.
Well the issue is that we tried to upstream this change as stated in the other given link but the upstream GMIC doesn’t want that. The arch packager can talk to us. The issue with this change is that packagers don’t know the full story or the changes that are done. They on the looks of it (I may be wrong and will be happy to be wrong) dismissing this as we forked the project and they don’t want to package it.
This change builds gmic inside Krita as in compiles with krita there is no need for another package. Our source is also open they can package it and solve this issue somehow.
I’m 100% certain that appimages are super slow, do a simple comparison of any app released as appimage and you will feel the slowness in its launch and performance.
All the code and the changed we did to GMIC is out in the open and is licensed under free software. We also tried t upstream this, there is also valid reason for this change. You can ask the packagers to package it, if they don’t want to what we can do. It is not like we will go on to package for all the distribution. Also the point of this change was to solve problem arising from external gmic so providing external gmic is like undoing the fix.
Again it is not like we are blocking anything. We would also like to solve this issue and for that to happen packagers need to communicate. In the past week I tried to talk to some other packagers and have highlighted how gmic is broken but they brushed it off. Exactly like the link in the arch tracker.