G'mic doesn't work, it shows no picture or stops completely after choosing a filter. I use krita with Windows 7 64 bit on a Sony Vaio with intel i5 and Nvidia Geforce graphic card.
Which qmic-qt plugin did you install? The one for Gimp doesn't work with Krita, of course. You need to get the krita one from http://gmic.eu/files/prerelease/
It's not working for me, either. I used krita-3.2.0-beta.1-x64.zip, gmic_krita_qt_win64.zip, and Windows 7 x64. I don't know if it's the same thing happening here, but I had a similar issue in Linux that seemed like it was caused by the plug-in and Krita being built with different versions of Qt. In that instance, I believe the text "Could not attach to shared memory area" and "(shmget): doesn't exist" would also be printed to the terminal (I can get the exact message, if you'd like). In Windows, I don't see a similar error message, but I do see "gmic-qt: empty answer!" and "gmic-qt: Got the wrong answer!" The plug-in was built using Qt 5.8.0, while Krita was built with Qt 5.6.1. I attached a log from DebugView where I open G'MIC, select the "Black & white" filter, press okay, then close Krita.
Created attachment 106744 [details] DebugView output
That actually shouldn't matter... If it turns out that the plugin and krita need to be built with the same version of Qt, we've got a big problem!
I've asked about that on the qt-interest mailing list.
(In reply to Boudewijn Rempt from comment #1) > Which qmic-qt plugin did you install? The one for Gimp doesn't work with > Krita, of course. You need to get the krita one from > http://gmic.eu/files/prerelease/ I installed the right one: gmic_krita_qt-win64.zip
(In reply to Boudewijn Rempt from comment #4) > That actually shouldn't matter... If it turns out that the plugin and krita > need to be built with the same version of Qt, we've got a big problem! They can be built against any version, so long as at runtime they load the same libQt5Core.
Okay... So that basically means "it won't ever work" -- I guess I'll have to rewrite and just toss all the bytes over the socket then.
Why do you have two Qt5Core in the same system in the first place? BTW, the change affects Unix only, not Windows. Actually, only the SystemV implementation of system semaphores, not the POSIX one.
Created attachment 106771 [details] QSharedMemory error messages from Linux Krita/qt-gmic My likely configuration was Krita with Qt 5.9.0 and gmic-qt with Qt 5.6.2 (Kubuntu 16.04.2, Qt built from source). I'm attaching the terminal output that I saved at the time. The issue I encountered involved QSharedMemory, which is used for passing image data back and forth. While that is a problem in itself, I don't think it's relevant to this particular bug report. Here, G'MIC is able to send commands to Krita, but the reverse isn't working; which makes me suspect something is wrong with the socket instead.
(In reply to Nicholas LaPointe from comment #10) > My likely configuration was Krita with Qt 5.9.0 and gmic-qt with Qt 5.6.2 > (Kubuntu 16.04.2, Qt built from source). I'm attaching the terminal output > that I saved at the time. Why do you have two Qt? > The issue I encountered involved QSharedMemory, which is used for passing > image data back and forth. It won't work with two Qt. Sorry, this is an unfixable problem.
(In reply to Thiago Macieira from comment #11) > > The issue I encountered involved QSharedMemory, which is used for passing > > image data back and forth. > It won't work with two Qt. Sorry, this is an unfixable problem. Right, I was saying that for the purpose of contrasting my problem and what I think might be this bug report's problem. QSharedMemory is used for passing image data while QLocalSocket is used for passing commands, and it seems like the command part is giving trouble in Windows. (I wrote about my problem here because it seemed like it could be related at first glance.) > Why do you have two Qt? If I'm not mistaken, Krita targets 5.6 as a minimum, but doesn't have a maximum. Because of that, I have a few versions of Qt installed in the /opt directory to verify that Krita works as expected when using different versions of Qt. I stumbled upon the QSharedMemory incompatibility because I didn't rebuild gmic-qt after rebuilding Krita using Qt 5.9. My own situation is different from what your earlier question was about: (In reply to Thiago Macieira from comment #9) > Why do you have two Qt5Core in the same system in the first place? The Windows version of Krita and the Windows version of the third-party plug-in gmic-qt are each bundled with Qt. We'd like the plug-in to run correctly regardless of which versions of Qt are being used. For my problem, I think we'll just have to not use QSharedMemory; for this bug report's problem, I can't say for sure if differing Qt versions are what's at fault (I don't have a development environment set up in Windows to verify).
(In reply to Nicholas LaPointe from comment #12) > (In reply to Thiago Macieira from comment #11) > > > The issue I encountered involved QSharedMemory, which is used for passing > > > image data back and forth. > > It won't work with two Qt. Sorry, this is an unfixable problem. > Right, I was saying that for the purpose of contrasting my problem and what > I think might be this bug report's problem. QSharedMemory is used for > passing image data while QLocalSocket is used for passing commands, and it > seems like the command part is giving trouble in Windows. On Linux, I recommend using memfd + file descriptor passing to pass the data. That avoids the usual issues with creating and attaching to the shared memory segment. > The Windows version of Krita and the Windows version of the third-party > plug-in gmic-qt are each bundled with Qt. s/plug-in/other process/. Got how it happened, but you should find a way to use the same Qt DLLs, to avoid the unnecessary memory consumption.
For the record: On Thursday, 20 July 2017 01:18:20 PDT Boudewijn Rempt wrote: > I just got this bug report: https://bugs.kde.org/show_bug.cgi?id=382491 , > which suggests that QSharedMemory only works if both applications were > built with the same version of Qt. Is that correct? I cannot find anything > about that in http://doc.qt.io/qt-5/qsharedmemory.html You can find it in the changelog, in the "Impotant Behavior Changes" section. http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.9.0#n35 - [QTBUG-60771] Reverted a change that caused Qt 5.6 through 5.8 not to connect to QSystemSemaphore and QSharedMemory created by running applications using Qt earlier than 5.6. Unfortunately, this means that Qt 5.9 will not connect to 5.6-5.8. Also, this is on Windows, where we ship one product, and the gmic team ships another product. Which is only called a plugin-because it used to be gimp-specific, where all plugins are in a separate process.
(In reply to Boudewijn Rempt from comment #14) > For the record: > > On Thursday, 20 July 2017 01:18:20 PDT Boudewijn Rempt wrote: > > I just got this bug report: https://bugs.kde.org/show_bug.cgi?id=382491 , > > which suggests that QSharedMemory only works if both applications were > > built with the same version of Qt. Is that correct? I cannot find anything > > about that in http://doc.qt.io/qt-5/qsharedmemory.html > > You can find it in the changelog, in the "Impotant Behavior Changes" section. > http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.9.0#n35 > > - [QTBUG-60771] Reverted a change that caused Qt 5.6 through 5.8 not to > connect to QSystemSemaphore and QSharedMemory created by running > applications using Qt earlier than 5.6. Unfortunately, this means that Qt > 5.9 will not connect to 5.6-5.8. This appears to affect only Linux and Mac, so let's not mix the two issues here. Considering the Windows situation, the timestamps between Krita sending a message and gmic-qt responding "gmic-qt: empty answer!" or "gmic-qt: Got the wrong answer!" are 2 seconds apart, which just so happens to match the timeout specified: https://github.com/c-koi/gmic-qt/blob/8e4511256c0b420f33252356d4741034044423ae/src/host_krita.cpp#L105 This could indicate that the QLocalSocket isn't flushing normally.
Git commit cc105d5cf1eaa69432e240ac1f30c18bb72a0b27 by Alvin Wong. Committed on 21/07/2017 at 13:27. Pushed by alvinwong into branch 'krita/3.2'. Flush QLocalSocket in QMic plugin M +2 -0 plugins/extensions/qmic/QMic.cpp https://commits.kde.org/krita/cc105d5cf1eaa69432e240ac1f30c18bb72a0b27
Git commit ec23492455fb32a1cbc5ba1da43e57826d086062 by Alvin Wong. Committed on 21/07/2017 at 13:26. Pushed by alvinwong into branch 'master'. Flush QLocalSocket in QMic plugin M +2 -0 plugins/extensions/qmic/QMic.cpp https://commits.kde.org/krita/ec23492455fb32a1cbc5ba1da43e57826d086062
I think that in the end, I will have to give up on the idea of having david tschumperly and sebastian maintain the gmic-qt plugin and have it compatible with krita. We'll have to just regularly pull their code, and I'll have to directly implement the interface in krita :-( If QSharedMemory cannot work with either party built with a different version of Qt, we're never going to make this work.
(In reply to Boudewijn Rempt from comment #18) > If QSharedMemory cannot work with either party built with a different > version of Qt, we're never going to make this work. Again, it's not a matter of build, but run. Since there's binary compatibility, you'd want to run with the same .so, to avoid having additional memory use.