On digiKam-7.2.0-beta2-20201219T112949-MacOS-x86-64 on Catalina 10.15.7. The Export menu does not export any images. STEPS TO REPRODUCE 1. Open Image Editor with image 2. Optionally edit the image. 3. Click Export Menu 4. user is prompted for save as folder, filename and filetype [defaults to heic which is annoying, but topic of another bug]. Change to JPEG or TIF. 5. Click Save 6. Expect the file to be saved, but it is not saved. I tried this on Ubuntu and it worked fine, it seems to be Mac specific.
The last used file type is actually saved and reused. Saving via File-> Export has no problem here under Linux. Please post the output from the terminal as described here: https://www.digikam.org/contribute/ Maik
As requested, See Below. It doesn't matter what format I pick. 2020-12-19 12:52:08.393815-0500 digikam[8488:1121748] [digikam.dimg.jpeg] End Of Image ( 1 ) 2020-12-19 12:52:55.275563-0500 digikam[8488:1119892] [digikam.general] startSavingAs called 2020-12-19 12:53:20.779100-0500 digikam[8488:1119892] modalSession has been exited prematurely - check for a reentrant call to endModalSession: 2020-12-19 12:53:20.779318-0500 digikam[8488:1119892] [digikam.general] File Save Dialog rejected
In principle "File Save Dialog rejected" means you clicked on cancel in the dialog. Strange... Maik
Could it be that you pressed Enter and the deafault button under MacOS is Cancel? Maik
I have two buttons, Cancel and Save. Both give the same result. Save is the default.
Git commit 9367c813dcb5101fce13addecdbe8b0dfe64eecd by Maik Qualmann. Committed on 20/12/2020 at 12:16. Pushed by mqualmann into branch 'master'. add result code to debug output M +1 -1 core/utilities/imageeditor/editor/editorwindow.cpp https://invent.kde.org/graphics/digikam/commit/9367c813dcb5101fce13addecdbe8b0dfe64eecd
Maik, For info, this morning i restarted a whole Macports install to support debug symbols through dSYM for MacOS. If all compile fine new PKG will be available this evening (with Macports, recompiling all from scratch is always a big adventure). Gilles
Gilles, do we want to publish digiKam-7.2.0-Beta2 by the weekend if there are no further problems with the MacOS package or postpone it until January? Maik
Hi Maik, yes this is the plan. I'm on holiday this next Wednesday. I will working on while this week end. Gilles
Maik, debug an non debug PKG for MacOS are now properly built. Look the sizes : /digikam/digiKam-7.2.0-beta2-20201221T204730-MacOS-x86-64.pkg has a size of 263.9 MB (276743879 bytes) /digikam/digiKam-7.2.0-beta2-20201221T205556-MacOS-x86-64-debug.pkg has a size of 470.6 MB (493496017 bytes) There is no specific change for non debug version compared to previous PKG, but now debug version includes plenty of .dSYM directories with debug symbols for all components of digikam (executable, share libs, plugins). This will allow to capture suitable gdb backtrace if crash occurs. Geoff, new PKGs are available at usual place, including last changes from Maik: https://files.kde.org/digikam/ Gilles
I've tried the new debug version and can no longer open images in the Image Editor. digiKam-7.2.0-beta2-20201221T205556-MacOS-x86-64-debug I now get an error Cannot load .... when trying to load a photo in the Image Editor 2020-12-21 19:22:24.644512-0500 digikam[13800:1640774] [digikam.geoiface] ---- 2020-12-21 19:22:24.657588-0500 digikam[13800:1643155] [digikam.dimg] "/Volumes/MyBook_3TB/Pictures/import/Temp-Share/20150607_IMG_0685.jpeg" : Unknown image format !!! 2020-12-21 19:22:24.657629-0500 digikam[13800:1643155] [digikam.general] Cannot load image for "/Volumes/MyBook_3TB/Pictures/import/Temp-Share/20150607_IMG_0685.jpeg" 2020-12-21 19:22:24.694557-0500 digikam[13800:1640774] [digikam.general] d->image is NULL 2020-12-21 19:22:24.706155-0500 digikam[13800:1640774] [digikam.general] d->image is NULL 2020-12-21 19:22:24.706319-0500 digikam[13800:1640774] [digikam.general] d->image is NULL
there was something not working with the new debug version. I removed the whole digikam directory and then re-installed the non-debug version and it is now working like it was yesterday. Images can load, but cannot export like original report.
The debug version probably doesn't contain any DImg plugins, Gilles will take a look at it. The debug version is not necessary for this problem, please repeat Comment 2 and post the output. Maik
Maik, All DImg plugins are installed in PKG (debug and not debug). See the list of files prepared before packaging: bash-3.2$ pwd /Users/gilles/Devel/7.x/project/bundles/macports/opt/digikam/libexec/qt5/plugins/digikam/dimg bash-3.2$ ls -al total 1648 drwxr-xr-x 11 root wheel 352 22 déc 07:47 . drwxr-xr-x 7 root wheel 224 21 déc 18:16 .. -rwxr-xr-x 1 root wheel 115032 22 déc 07:47 DImg_HEIF_Plugin.so -rwxr-xr-x 1 root wheel 97456 22 déc 07:47 DImg_ImageMagick_Plugin.so -rwxr-xr-x 1 root wheel 94952 22 déc 07:47 DImg_JPEG2000_Plugin.so -rwxr-xr-x 1 root wheel 93672 22 déc 07:47 DImg_JPEG_Plugin.so -rwxr-xr-x 1 root wheel 77040 22 déc 07:47 DImg_PGF_Plugin.so -rwxr-xr-x 1 root wheel 96464 22 déc 07:47 DImg_PNG_Plugin.so -rwxr-xr-x 1 root wheel 76552 22 déc 07:47 DImg_QImage_Plugin.so -rwxr-xr-x 1 root wheel 79008 22 déc 07:47 DImg_RAW_Plugin.so -rwxr-xr-x 1 root wheel 96904 22 déc 07:47 DImg_TIFF_Plugin.so If plugins was not here in PKG, images cannot be loaded in editor. Gilles
We need the complete debug output from the start to see if the plugins were found and loaded. Because the message "Unknown image format !!!" means that no plugin can and will load JPEG. I suspect that the DImg plugins were not loaded because they are not binary compatible. Maik
Maik, I do not think it's a binary compatibility issue with plugins. In "debug" PKG, we have "dSYM" sub-directories including extra debug symbols hosted in a dedicated binary file. all binary targets have a dSYM extension. Typically, when digiKam is built, digikam, showfoto, libdigikam*.*, and all plugins are compiled with these dSYM extensions. Debug directories are located at the same place than binary files. The pending Q is: in a bundle, where i need to move these dSYM directories? I respected the same place used while compiling: each dSYM is near the binary. Perhaps it need to be different, but i don't yet found a suitable doc explaining that. So for me the PKG debug problem can be due to a wrong place to host dSYM directories. Gilles
Maik, before to release 7.2.0-beta2 officially, i would to solve the PKG binary relocation under MacOS. This will make digiKam as a standard MAC application which can be installed in a external disk for ex, and not only in /Applications. Remember that digiKam is 100% installed in hardcoded /opt/digikam, with symlinks done in /Applications/digikam. To uninstall digiKam from Mac you need to remove both directories for a Terminal session. The normal way is to just move the digiKam folder (bundle) from MacOS Applications launcher to the trash and that all. The relocation of binaries work mostly on my computer. I hope to finalize quickly... Gilles
Here is the updated output. Looks the same as last time. 2020-12-22 10:00:17.217393-0500 digikam[3282:123620] [digikam.general] startSavingAs called 2020-12-22 10:00:36.147731-0500 digikam[3282:123620] modalSession has been exited prematurely - check for a reentrant call to endModalSession: 2020-12-22 10:00:36.147983-0500 digikam[3282:123620] [digikam.general] File Save Dialog rejected 0
The file dialog returned "rejected == 0". Do you use the native file dialog? In digiKam setup under Miscellaneous-> Appearance please switch to the simpler Qt file dialog. Maik
Yes. the native dialog was checked. I unchecked it and it now exports correctly. I don’t remember checking that, but maybe I did? Problem solved. Thanks, Geoff
Hmm, problem not really solved. The native file dialog should not return "rejected" under MacOS if the user has clicked on "Save". We will probably not be able to solve the problem and will have to wait for Qt bug fixes. I see in some program examples with the QFileDialog that it is only checked whether a URL was returned, it could be a workaround. Maik
Git commit a1645c3afe3ffdb1ac54f7c71006e287a11b7e5c by Maik Qualmann. Committed on 23/12/2020 at 06:52. Pushed by mqualmann into branch 'master'. try with result function from QDialog M +2 -2 core/utilities/imageeditor/editor/editorwindow.cpp https://invent.kde.org/graphics/digikam/commit/a1645c3afe3ffdb1ac54f7c71006e287a11b7e5c
Hi Geoff, can you please test whether the problem still exists? Thanks! Maik
Hello, I tested again on 7.3.0 Build date: 4/23/21 9:12 PM 1) with "Use native file dialogs from system" un-checked it works fine. 2) with "Use native file dialogs from system" checked it silently fails and does not export the file. It never prompts for the Jpeg file quality or chroma settings. This is same as before. Thanks, Geoff
Git commit d965173e8435f616ac8be85f7963459e73661f7c by Maik Qualmann. Committed on 25/04/2021 at 07:31. Pushed by mqualmann into branch 'master'. check only the URLs for results in the QFileDialog FIXED-IN: 7.3.0 M +2 -2 NEWS M +4 -13 core/utilities/imageeditor/editor/editorwindow.cpp https://invent.kde.org/graphics/digikam/commit/d965173e8435f616ac8be85f7963459e73661f7c
Hello, I tested this and can export using both dialogs. However, I did notice that when using the native system dialog option the Cancel button has no effect. It continues on to prompt for the quality settings. I can then click Cancel again, or continue to Save. Thanks, Geoff