I tried 6.2-pre (July 25) version and the preference for Icon Theme no longer gives an option for Dark icons, such as Breeze Dark. The only option is "Use Icon Theme From System". I have restarted Digikam several times.
I'll add that I've only tested this on MacOS, Mojave 10.14.6
Can you please check if the "breeze.rcc" and "breeze-dark.rcc" exist in the digikam installation directory? Maik
Gilles, possibly a QStandardPaths problem. In which directory are the breeze.rcc files on OSX? Maik
Found them here: /opt/digikam/Applications/KF5/digikam.app/Contents/Resources/breeze-dark.rcc /opt/digikam/Applications/KF5/digikam.app/Contents/Resources/breeze.rcc
Can you start digikam in the terminal and post the first 10 lines? The path should be: /opt/digikam/Applications/KF5/digikam.app/Contents/MacOS/digikam Maik
Git commit 1df5099fef527ce8378b97a538ecdc9b548293fa by Maik Qualmann. Committed on 26/07/2019 at 21:19. Pushed by mqualmann into branch 'master'. check again for the "index.theme" file The cache file may not exist under OSX. M +1 -1 core/utilities/setup/setupmisc.cpp https://invent.kde.org/kde/digikam/commit/1df5099fef527ce8378b97a538ecdc9b548293fa
To Maik, comment #3 : QStandardPath is problematic under MAcOS, especially for KF5 based API and application. The vision to handle QStandardPath from KF5 team and Qt5 team is completely different. As i know this divergence is not yet resolved in source code. So to join dots, i write a shell script, which patch automatically QStandardPath call everywhere before to compile codes when we build MacOS PKG : https://cgit.kde.org/digikam.git/tree/project/bundles/macports/fixbundledatapath.sh Called here : https://cgit.kde.org/digikam.git/tree/project/bundles/macports/03-build-digikam.sh#n105 https://cgit.kde.org/digikam.git/tree/project/bundles/3rdparty/ext_kf5_frameworks/CMakeLists.txt#n128 https://cgit.kde.org/digikam.git/tree/project/bundles/3rdparty/ext_marble/CMakeLists.txt#n59 But i doubt that the problem come from this patch, else nothing will work properly, as the KXMLGui XML definition will not be loaded and GUI will appear without menu for example. I thinking more about a wrong path used to package icons in the bundle. About the Qt5/KF5 conflict about QStandardPath, i CC Renee J Bertin, who know better than me the story and if the issue will be finally closed in the future. Gilles Caulier I CC
For comment #5. digikam.widgets: Breeze icons resource file found digikam.general: Switch to widget style: "Fusion" digikam.general: AlbumWatch is disabled digikam.general: Database Parameters: Type: "QSQLITE" DB Core Name: "/Users/gsking/Pictures/digikam4.db" DB Thumbs Name: "/Users/gsking/Pictures/thumbnails-digikam.db" DB Face Name: "/Users/gsking/Pictures/recognition.db" DB Similarity Name: "/Users/gsking/Pictures/similarity.db" Connect Options: ""
Thanks for the log when this message appears: digikam.widgets: Breeze icons resource file found also "Breeze Dark" is found. I think the problem will be fixed with my little change from comment 6, because it restores the old behavior. Maik
(In reply to caulier.gilles from comment #7) > To Maik, comment #3 : > > QStandardPath is problematic under MAcOS, especially for KF5 based API and > application. > > The vision to handle QStandardPath from KF5 team and Qt5 team is completely > different. As i know this divergence is not yet resolved in source code. Erm, no. KF5 code (mostly) uses QSP as it should, given how KF5 software is installed most of the time. The main problem lies in the conflict between platform requirements on "platform-native" install locations and schemas in QSP and in KDE's build system. In other words, KDE's build system is designed around the assumption of having shared resources in a central location, which happens to match with the standard Unix QSP implementation but not that for the Mac OS and MS Windows (which assume some form of sandboxing). Qt were never downright hostile against supporting a shared install schema/model on Mac and/or PC, I long had an exchange with David Faure about this, but ultimately we just never got around to coming up with something that would have stood a chance to be included in Qt. Either way that wouldn't have helped you here. > About the Qt5/KF5 conflict about QStandardPath, i CC Renee J Bertin, who Gilles, you should know how to write my name without changing my gender :P > know better than me the story and if the issue will be finally closed in the > future. You could look at Kate to see how embedding resources into the binary can be leveraged; the breeze icon theme even has a feature to help with this. That feature is documented but I think in the code only.
To Rene from comment #10 : sorry for the typo in your name, it's not intentional (:-))) Thanks for your feedback. I will look how Kate package MacOS version Maik, Read well the Rene comment, it's very informative. Gilles
I tried with 6.2 (July 30) packages on MacOS, Mojave 10.14.6. I am happy to report this is now working as expected.