Krita merge requestshttps://invent.kde.org/graphics/krita/-/merge_requests2023-05-11T00:54:25Zhttps://invent.kde.org/graphics/krita/-/merge_requests/1787Allow building with Clang/CL and fix building with GCC2023-05-11T00:54:25ZAmy sparkAllow building with Clang/CL and fix building with GCCHi @dkazakov !
As promised, I'm sending this MR to allow building Krita with MSVC.
While rebuilding my developer environment, I found the following MSVC-specific bits were overlooked in !1334 (error logs [here](https://invent.kde.org/-...Hi @dkazakov !
As promised, I'm sending this MR to allow building Krita with MSVC.
While rebuilding my developer environment, I found the following MSVC-specific bits were overlooked in !1334 (error logs [here](https://invent.kde.org/-/snippets/2614)):
- Lager relies on `template<template<>> class`es, which are unsupported/buggy: https://developercommunity.visualstudio.com/t/c-invalid-template-argument-for-template-parameter/831128
- The fix for the Lager forwarding issue introduced [here](https://github.com/dimula73/lager/commit/51e3c0eff39b58f5572f29222dfb699d8a05d9df#diff-b38425a103f7d814f65e573deea86a2d98a9cbecbce0fd4dac41cb1c3b04cbb5R230)) relies on resolving to a higher-level namespace, which MSVC doesn't like in this particular case (the `lager::lenses::detail` takes higher precedence than `lager::detail`)
I didn't try to fix these because they seem to be compiler bugs, so instead I switched to Clang/CL for the Krita build itself. Once I did that, I found the following: (error logs [here](https://invent.kde.org/-/snippets/2612))
- KDE's CompilerSettings enable many flags that are Clang-specific and are ignored or interpreted differently in the MSVC flavour.
- Chiefly among them is `-Wall`, which Clang/CL maps to `-Weverything`, thus making the build spam hundreds of warnings per file.
- Implicitly defining destructors of `QScopedPointer` consumers, like `KisBrushOptionWidget`, requires that the destructor of the guarded class be available at declaration time. This is not an issue with stock Clang and GCC, but Microsoft does enforce this requirement. This issue was documented previously in d64ee6a5b44d1d15aff2b56f213a9af4fb77f757:
- Qt docs: https://doc.qt.io/qt-6/qscopedpointer.html#forward-declared-pointers
- My own bug report: https://developercommunity.visualstudio.com/t/C2027-error-when-using-Qts-QSharedDataP/1424440#T-N1453705
- The new Lager-based KisCurveOption uses `std::vector<std::unique_ptr<KisDynamicSensor>>`. This causes the implicitly defined copy constructor of KisCurveOption to attempt to access the deleted copy ctor of `std::vector`.
- The new Lager-backed KisDynamicSensorFactory doesn't implement `QString id() const`, yet it's used with `KoGenericRegistry` where it's required for `add(T value)`. Again, this implicitly relies on GCC construction semantics, whereas MSVC instead requires all concepts to be implemented and elides the APIs at codegen time.
- I had improperly scoped the SSE flag check for xsimd, since it's not documented that Clang/CL doesn't enable instruction sets in the same way as MSVC (ie. up to SSE4.1 by default on 64). I only found out about this yesterday: https://aomedia-review.googlesource.com/c/aom/+/173762
(EDIT)
Upon further review, I decided to also test with the spare compiler I have in my environment, GCC UCRT64 12.2.0. There I found much more serious errors (logs [here](https://invent.kde.org/-/snippets/2619)), so I decided to actually patch up Lager in 3rdparty.
- Lager breaks the C++17 standard by attempting to define final, non-virtual functions in the nodes.
- zug::map uses deduction on the transformer function to pass the object to be transformed as the first parameter; you relied on this in turn, to call into member functions to obtain the LOD restrictions. This is also non-standards-compliant, because member functions aren't directly callable except through `std::function`, `std::bind`, or lambdas.
The functionality described in the last item is actually a post C++ 17 proposal that Clang implements for some reason: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0312r1.html
It's also described here: https://devblogs.microsoft.com/cppblog/trip-report-evolution-working-group-at-the-summer-iso-c-standards-meeting-toronto/
Test Plan
---------
Build Krita.
Note
----
The flag compatibility commit must be cherry-picked to 5.1 to allow me to test backports.
Formalities Checklist
---------------------
- [X] I confirmed this builds.
- [X] I confirmed Krita ran and the relevant functions work.
- [X] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).
_**Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build.**_
_**If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.**_Krita 5.2Merge ServiceMerge Servicehttps://invent.kde.org/graphics/krita/-/merge_requests/1772Video I/O dialog layout improvements2023-05-01T19:07:45ZAmy sparkVideo I/O dialog layout improvementsHey @emmetoneill,
This is the promised PR to deal with the video import and export dialogs. Apart from the usual clang-tidy lint fixing, I focused on improving and simplifying the dialogs' layout and make them more accessible.
There's ...Hey @emmetoneill,
This is the promised PR to deal with the video import and export dialogs. Apart from the usual clang-tidy lint fixing, I focused on improving and simplifying the dialogs' layout and make them more accessible.
There's a new widget I made for the codec options dialog, `KisStackedWidget`, that enables a `QStackedWidget` to resize itself to its current visible member's `sizeHint`, instead of staying with the maximum of all children's sizes.
Video Import
------------
| Before | After |
| ------ | ------ |
| ![before1](/uploads/a50a292ed0e0b0480219f2dab8c829ec/before1.png) | ![after1](/uploads/f626210648edb893f089247db1357c37/after1.png) |
| ![before2](/uploads/4042b8cdd55715cc753a3ffd563f88e4/before2.png) | ![after2](/uploads/d14788c3db117d2e7a214f72fa433803/after2.png) |
Video Export
------------
| Before | After |
| ------ | ------ |
| ![before_1](/uploads/68e1894b974becadb3597fda84d0ede8/before_1.png) | ![after_1_renewed](/uploads/b97b7c0aa53e3499252a801a20c46a20/after_1_renewed.png) |
| ![before_2](/uploads/87e916485b68bf2173d0ad2c2283de30/before_2.png) | ![after_2](/uploads/bc19b427ee4ca7100f4b94dbc6d607ed/after_2.png) |
| ![before_3](/uploads/857863b54946fc8cf853c0ce6375c5bf/before_3.png) | ![after_3](/uploads/512d91958c43d02e4378d5f0ee154ac7/after_3.png) |
| ![before_4](/uploads/981f511c56c73377fd62797a77b762ee/before_4.png) | ![after_4](/uploads/44f0101e62b4512e91f10b27f0060bca/after_4.png) |
Test Plan
---------
(Tell us how to test the changes you made.)
Formalities Checklist
---------------------
- [X] I confirmed this builds.
- [X] I confirmed Krita ran and the relevant functions work.
- [X] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).
_**Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build.**_
_**If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.**_Krita 5.2Merge ServiceMerge Servicehttps://invent.kde.org/graphics/krita/-/merge_requests/1765More Coverity appeasement fixes2023-03-07T10:33:34ZAmy sparkMore Coverity appeasement fixesAssorted Coverity fixes. There are more of those pass-by-value complaints involving ToolTransformArgs but they involve Dmitry's concurrency safety valve (lambdas going outside the scope of the callee).
Associated CID entries have alread...Assorted Coverity fixes. There are more of those pass-by-value complaints involving ToolTransformArgs but they involve Dmitry's concurrency safety valve (lambdas going outside the scope of the callee).
Associated CID entries have already been marked as Fix Submitted and triaged.
Test Plan
---------
Build and run Krita.
Formalities Checklist
---------------------
- [X] I confirmed this builds.
- [X] I confirmed Krita ran and the relevant functions work.
- [X] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).
_**Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build.**_
_**If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.**_Krita 5.2Merge ServiceMerge Servicehttps://invent.kde.org/graphics/krita/-/merge_requests/1761Unbreak FFmpeg compatibility2023-03-07T10:31:15ZAmy sparkUnbreak FFmpeg compatibilityHi all!
This MR unbreaks the FFmpeg importer and exporter after !1599 took place. Some of the bits are shippable without review, but there are two I'd like some external verification for:
- libaom **cannot** be built as a shared librar...Hi all!
This MR unbreaks the FFmpeg importer and exporter after !1599 took place. Some of the bits are shippable without review, but there are two I'd like some external verification for:
- libaom **cannot** be built as a shared library. Not only it'll race condition with aom_static because both are named the same, `aom` (CMake sets the same suffix for export and static libraries under MSVC), the shared version does not export the symbols for AV1 correctly.
- zlib has a conflict with macro definitions used by FFmpeg, they don't cause any issues with Unix-based compilers *unless* your system doesn't have unistd.h installed. This was reported here: https://github.com/madler/zlib/issues/787
The others are:
- update to aom 3.6 to fix some optimization bugs
- fixed our FFmpeg copy lacking the APNG muxer, which is needed when importing a video animation
- fixed our FFmpeg copy lacking FFprobe, which can be used when importing a video animation (otherwise it falls back to FFmpeg)
- fixed a missed logic check for when FFmpeg isn't available yet the dialog allows to edit all codec options
- added fallback logic to find our own installed FFmpeg or a system copy. This is needed on first install, when the `ffmpegLocation` preference isn't yet set.
Test Plan
---------
Build deps and Krita,
Formalities Checklist
---------------------
- [X] I confirmed this builds.
- [X] I confirmed Krita ran and the relevant functions work.
- [X] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).
_**Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build.**_
_**If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.**_Krita 5.2Merge ServiceMerge Servicehttps://invent.kde.org/graphics/krita/-/merge_requests/1756Fix this month's Coverity entries2023-02-24T20:50:47ZAmy sparkFix this month's Coverity entriesAgain nothing that's too concerning, *except* for two issues:
- there was the non-zero chance of crashing ourselves with KisResourceResult because of a `boost::bad_get` exception leaking into the event loop
- `KIS_SAFE_ASSERT_RECOVER_BR...Again nothing that's too concerning, *except* for two issues:
- there was the non-zero chance of crashing ourselves with KisResourceResult because of a `boost::bad_get` exception leaking into the event loop
- `KIS_SAFE_ASSERT_RECOVER_BREAK` was broken since b9f7132e88358e4ab86fc8cac1d5b99cad5c0c7e (4.3) because the `break` applied to the macro'd while loop, not to the containing loop
Test Plan
---------
Build Krita and run tests. There is no expected change in functionality except for fixed assertion breaks.
Formalities Checklist
---------------------
- [X] I confirmed this builds.
- [X] I confirmed Krita ran and the relevant functions work.
- [X] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).
_**Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build.**_
_**If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.**_
/cc @woltheravKrita 5.2Merge ServiceMerge Servicehttps://invent.kde.org/graphics/krita/-/merge_requests/1755Fix High Impact Outstanding Coverity issues2023-02-22T21:21:50ZAmy sparkFix High Impact Outstanding Coverity issuesNothing too concerning, except the fixes to the OpenGL circular buffer. The Coverity issue suggested a small ABI change was better in the long run for better validation.
Assigning to @ivany since the ABI change affects a commit of his.
...Nothing too concerning, except the fixes to the OpenGL circular buffer. The Coverity issue suggested a small ABI change was better in the long run for better validation.
Assigning to @ivany since the ABI change affects a commit of his.
Test Plan
---------
Build Krita and run the tests.
Formalities Checklist
---------------------
- [X] I confirmed this builds.
- [X] I confirmed Krita ran and the relevant functions work.
- [X] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).
_**Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build.**_
_**If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.**_
/cc @tymondKrita 5.2Merge ServiceMerge Servicehttps://invent.kde.org/graphics/krita/-/merge_requests/1753Bundle Manager: finish applying the Resource Manager UX2024-02-07T09:18:29ZAmy sparkBundle Manager: finish applying the Resource Manager UX@tymond: This MR is meant to finish applying the thumbnail/details pattern we'd designed in !1732 to the Bundle Manager.
I'm not too sure about the header/body separation, perhaps that's something to review tomorrow at the meeting? If s...@tymond: This MR is meant to finish applying the thumbnail/details pattern we'd designed in !1732 to the Bundle Manager.
I'm not too sure about the header/body separation, perhaps that's something to review tomorrow at the meeting? If so, this should be made consistent across the Bundle and Resource Manager and the DB explorer.
| Before | After |
| ------ | ------ |
| ![4-1](/uploads/4576509c6ef386abf559823c474b0e48/4-1.png) | ![imagen](/uploads/219d18723a842ca6ee9916b77761cec4/imagen.png) |
Test Plan
---------
Build Krita and open the Bundle Manager.
Formalities Checklist
---------------------
- [X] I confirmed this builds.
- [X] I confirmed Krita ran and the relevant functions work.
- [X] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).
_**Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build.**_
_**If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.**_Krita 5.3https://invent.kde.org/graphics/krita/-/merge_requests/1752Resource Manager: add a placeholder panel for no/multiple selection2024-02-07T09:18:29ZAmy sparkResource Manager: add a placeholder panel for no/multiple selectionThis MR adds a placeholder widget for when there are none/multiple resources selected, so that empty widgets are no longer shown.
| Before | After |
| ------ | ------ |
| ![1-2](/uploads/eae1c21c911d3b3c329c4f4c003272ee/1-2.png) |...This MR adds a placeholder widget for when there are none/multiple resources selected, so that empty widgets are no longer shown.
| Before | After |
| ------ | ------ |
| ![1-2](/uploads/eae1c21c911d3b3c329c4f4c003272ee/1-2.png) | ![1-1](/uploads/cd8cf5e76bbd0ea71734acd539ec4400/1-1.png) |
| ![2-2](/uploads/bb91946492665a78d1001b60fda1e5f3/2-2.png) | ![2-1](/uploads/55491e79dfea2b3789d78b7e3a3c906f/2-1.png) |
| ![3-2](/uploads/c062c351aa576cbbd44d86cd2a1ff93f/3-2.png) | ![3-1](/uploads/2c14856794020735ec434c04e09524e3/3-1.png) |
Test Plan
---------
Build Krita and open the Resource Manager. Try selecting one, two resources, and then deselect them. Check that the panel switches accordingly.
Formalities Checklist
---------------------
- [X] I confirmed this builds.
- [X] I confirmed Krita ran and the relevant functions work.
- [X] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).
_**Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build.**_
_**If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.**_Krita 5.3https://invent.kde.org/graphics/krita/-/merge_requests/1751KisApplication: add entries for plugin and resource loading2023-03-03T11:39:47ZAmy sparkKisApplication: add entries for plugin and resource loadingHi all,
This MR proposes adding two new splash messages to add some detail to the loading process. The actual heavy work is done in `KisPart::createMainWindow`, but there are two extra bits that could be extracted from that context, loa...Hi all,
This MR proposes adding two new splash messages to add some detail to the loading process. The actual heavy work is done in `KisPart::createMainWindow`, but there are two extra bits that could be extracted from that context, loading plugins and resources.
I'm not sure if these were removed some versions ago, so feel free to close the MR if the detail is deemed excessive.
Test Plan
---------
N/A
Formalities Checklist
---------------------
- [X] I confirmed this builds.
- [X] I confirmed Krita ran and the relevant functions work.
- [X] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).
_**Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build.**_
_**If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.**_https://invent.kde.org/graphics/krita/-/merge_requests/17483rdparty: port Find Modules away from LibFindMacros2023-06-27T08:08:09ZAmy spark3rdparty: port Find Modules away from LibFindMacrosHi all,
In this MR I propose changes enabling us to drop the LibFindMacros module, which introduces additional noise on Windows due to it being unable to find pkgconf as well as certain CMake-only modules (primarily libde265).
I've mov...Hi all,
In this MR I propose changes enabling us to drop the LibFindMacros module, which introduces additional noise on Windows due to it being unable to find pkgconf as well as certain CMake-only modules (primarily libde265).
I've moved all the affected Find Packages to a primary CMake lookup (if the package in 3rdparty supports it), adding the relevant namespacing and variable definitions to make naming compatible. Then I added and expanded the pkg-config fallbacks to enumerate all targets, so that other developers can copy our modules and use them without issues.
Test Plan
---------
Build Krita with all dependencies from system or 3rdparty (it should work with both). Check that there are no linking issues. I tested here with Dmitry's llvm-mingw and my MSVC development environment.
Formalities Checklist
---------------------
- [X] I confirmed this builds.
- [X] I confirmed Krita ran and the relevant functions work.
- [X] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).
_**Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build.**_
_**If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.**_https://invent.kde.org/graphics/krita/-/merge_requests/1747openexr: Simplify the existing indirections for linking2023-03-29T08:09:54ZAmy sparkopenexr: Simplify the existing indirections for linkingThis MR revises the existing indirections for building with OpenEXR support. They stem mostly from legacy components being grouped into subprojects (kritapigment for instance), so I've taken care to preserve the existing variables where ...This MR revises the existing indirections for building with OpenEXR support. They stem mostly from legacy components being grouped into subprojects (kritapigment for instance), so I've taken care to preserve the existing variables where possible.
Test Plan
---------
Build Krita with OpenEXR and check that there are no linking issues.
Formalities Checklist
---------------------
- [X] I confirmed this builds.
- [X] I confirmed Krita ran and the relevant functions work.
- [X] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).
_**Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build.**_
_**If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.**_https://invent.kde.org/graphics/krita/-/merge_requests/1746raw: Remove unused dependency on LibRaw2023-03-05T00:26:35ZAmy sparkraw: Remove unused dependency on LibRawWe use KF5KDcraw since !1682, so we no longer need to access the version
it's using directly.
Test Plan
---------
Build Krita and try importing a RAW file. The plugin should still run.
Formalities Checklist
---------------------
- [...We use KF5KDcraw since !1682, so we no longer need to access the version
it's using directly.
Test Plan
---------
Build Krita and try importing a RAW file. The plugin should still run.
Formalities Checklist
---------------------
- [X] I confirmed this builds.
- [X] I confirmed Krita ran and the relevant functions work.
- [X] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).
_**Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build.**_
_**If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.**_Krita 5.2Merge ServiceMerge Servicehttps://invent.kde.org/graphics/krita/-/merge_requests/1745G'MIC: update to 3.2.12023-02-19T13:39:47ZAmy sparkG'MIC: update to 3.2.1As usual, the release is at https://github.com/amyspark/gmic/releases/tag/v3.2.1.1. It only needs copying to files.kde, the URL is already in place.
Test Plan
---------
Build Krita.
Formalities Checklist
---------------------
- [X] ...As usual, the release is at https://github.com/amyspark/gmic/releases/tag/v3.2.1.1. It only needs copying to files.kde, the URL is already in place.
Test Plan
---------
Build Krita.
Formalities Checklist
---------------------
- [X] I confirmed this builds.
- [X] I confirmed Krita ran and the relevant functions work.
- [X] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).
_**Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build.**_
_**If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.**_Krita 5.2https://invent.kde.org/graphics/krita/-/merge_requests/1744Assorted layout improvements to the Color Selector Settings pane2023-02-22T15:52:21ZAmy sparkAssorted layout improvements to the Color Selector Settings paneHi all,
In this MR I apply a bit of the existing design language to the Color Selector preference panel. This was spurred by word-of-mouth complaints about readability and lack of flow when switching between the panels on Windows. And o...Hi all,
In this MR I apply a bit of the existing design language to the Color Selector preference panel. This was spurred by word-of-mouth complaints about readability and lack of flow when switching between the panels on Windows. And on Linux, while testing this, I found that on a native build (here Manjaro with Gnome) the selector would actually collapse on itself. I put an example as the first screenshot.
To fix that, and also improve on the accessibility, I simplified and ported the panel to the form layout, ensured that elements take their native sizes, and enforced layout through size policies instead of spacers or minimum sizes. (The latter was a key contribution to the collapse behaviour exhibited under the Fusion theme.)
I've kept these changes in different commits to ease review and revert if those are needed.
Screenshots
-----------
| Before | After |
| ------ | ------ |
| ![acs1-1](/uploads/d054b4fa454dae253f069efc75c23d53/acs1-1.png) | ![acs1-2](/uploads/dd26752fabef2692ec0b48b8368af3b9/acs1-2.png) |
| ![acs2-1](/uploads/eaf2af1414c312610745fcb5a5f85e95/acs2-1.png) | ![acs2-2](/uploads/9bcb18c430982207b41c48ca3d7f9e10/acs2-2.png) |
| ![acs3-1](/uploads/fa9d5a2ed8bfb267bb4c52eed0a0c7b8/acs3-1.png) | ![acs3-2](/uploads/6bc895290e6fa04c2ac2f855563a7355/imagen.png) |
| ![acs4-1](/uploads/aea6a1c7fc4cec2bd58179b01bf75c4b/acs4-1.png) | ![acs4-2](/uploads/e86a96fc33880379db8c3a433e8f0a11/acs4-2.png) |
| ![acs5-1](/uploads/ed22cee614800cc1191868ad89e56734/acs5-1.png) | ![acs5-2](/uploads/6aa33540bd7e40feb81e0636b69de00e/acs5-2.png) |
| ![acs6-1](/uploads/405a54cffc8b6acf489ac82dc05e79ab/acs6-1.png) | ![acs6-2](/uploads/d374b18fd984d3e7c4d165b90b70c6ea/acs6-2.png) |
Test Plan
---------
Build Krita, open the Preferences > Color Selector Settings pane, and check that all is rendered well in your system.
Formalities Checklist
---------------------
- [X] I confirmed this builds.
- [X] I confirmed Krita ran and the relevant functions work.
- [X] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).
_**Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build.**_
_**If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.**_Krita 5.2Merge ServiceMerge Servicehttps://invent.kde.org/graphics/krita/-/merge_requests/1742Assorted layout fixes for the Preferences dialog2023-02-26T00:36:11ZAmy sparkAssorted layout fixes for the Preferences dialogHi,
This MR proposes several visual enhancements to the Preferences dialog, centered around:
- the usage of form widgets, replacing the bespoke nested layouts and thus allowing automatic labeling of widgets
- the usage of a new general...Hi,
This MR proposes several visual enhancements to the Preferences dialog, centered around:
- the usage of form widgets, replacing the bespoke nested layouts and thus allowing automatic labeling of widgets
- the usage of a new general pattern, `KisWarningBlock`, for rendering user warnings/information blocks
- the usage of "comment" labels for the various instances of "needs restart" across the dialog
As part of this change, I've also applied a general replacement in .ui files, so that our spinboxes are considered as their real base class (`Q(Double)SpinBox`) instead of a `QWidget` when rendered in Qt Designer.
There's an additional, actual bugfix to the default tab in the General pane that was introduced in !1658. It mistakenly changed th default tab to the last instead of the first, possibly because the .ui was edited in Designer.
| Before | After |
| ------ | ------ |
| ![before_1](/uploads/7da3ce623ac6e976867958783f08b8a2/before_1.png) | ![after_1](/uploads/97ebfcefd1005cffa99299c181ccc2bc/after_1.png) |
| ![before_2](/uploads/13d5480aaefb0a7f45421363e6a11493/before_2.png) | ![after_2](/uploads/4df680652cc5f0c1b02d3084c05d0011/after_2.png) |
| ![before_3](/uploads/009de7f6d2044a2b391e1ed21187e278/before_3.png) | ![after_3](/uploads/89dfc72e6d2bd8d849897d33272524e2/after_3.png) |
| ![before_4](/uploads/c304f134628edfea9ac0b0b36aee00d8/before_4.png) | ![after_4](/uploads/7d12b168602cde9f621c5bd15bc927e4/after_4.png) |
| ![before_5](/uploads/c48365b66e5b8cfbcdd263a03817339c/before_5.png) | ![after_5](/uploads/dd62f8d1af0669493841bc11a06aa15b/after_5.png) ![after_6](/uploads/8b70f9e2225e1bcb0ca0bf452674c4ea/after_6.png) |
| ![before_7](/uploads/60f1373f35e1a92fa6e19a6a3795dcca/before_7.png) | ![after_7](/uploads/d4893cd59771f861833c1bd64a4c3461/after_7.png) |
| ![before_8](/uploads/27b820594a0d2500d25c4c374ec29efc/before_8.png) | ![after_8](/uploads/ec9853e5c96f6d0c9a94664ac943b23c/after_8.png) |
Test Plan
---------
Build Krita and check that the warnings of "HDR Settings", "Resources", and "Canvas acceleration" are still rendered in their appropriate context. The rest of the widgets haven't been changed logically.
Formalities Checklist
---------------------
- [X] I confirmed this builds.
- [X] I confirmed Krita ran and the relevant functions work.
- [X] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).
_**Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build.**_
_**If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.**_Krita 5.2Merge ServiceMerge Servicehttps://invent.kde.org/graphics/krita/-/merge_requests/1733DB Explorer: implement missing features2023-02-16T21:22:56ZAmy sparkDB Explorer: implement missing featuresHi!
This MR proposes implementing the two missing features in Halla's database explorer: per-resource versions listing and per-tag resource listings. To achieve that, I had to do some fixes to the resource and tag models, as well as imp...Hi!
This MR proposes implementing the two missing features in Halla's database explorer: per-resource versions listing and per-tag resource listings. To achieve that, I had to do some fixes to the resource and tag models, as well as implement missing data marshalling.
I've also taken the opportunity to improve on the layout and make it more friendly to the user, mainly by rearranging some tables, adding group boxes to label bits of the Resources tab, and fixing the rendering of controls in the Resources and Tags tables.
| Before | After |
| ------ | ------ |
| ![imagen](/uploads/e1264dbff139140b44ce014b4c79fb62/imagen.png) | ![imagen](/uploads/2aa697d126e70231605482f8f0f4dd96/imagen.png) |
| ![imagen](/uploads/7bdd983fb7948e4f204fc899a6583023/imagen.png) | ![imagen](/uploads/9479abe150bd3ebde2a81d549b593360/imagen.png) |
| ![imagen](/uploads/ad4716a708f76216702983cf6b91835a/imagen.png) | ![imagen](/uploads/8099011a500361c3a1adce6fa5d47557/imagen.png) |
| ![imagen](/uploads/b68d4c36de252b1ae0eaeeaf566b5b38/imagen.png) | ![imagen](/uploads/77495ac7b123e130ffb9557a38040049/imagen.png) |
| ![imagen](/uploads/d0794facb1dbd994747c784ee0a8d8b6/imagen.png) | ![imagen](/uploads/b592082f1bbe2ead982df1cc93ca0756/imagen.png) |
Questions
---------
Should we shrink the thumbnails provided for DecorationRole? These make row resizing impossible because they balloon the height. cc @szaman since you were working on caching these.
Test Plan
---------
Build Krita and call up the Resource Cache Database Explorer.
Formalities Checklist
---------------------
- [X] I confirmed this builds.
- [X] I confirmed Krita ran and the relevant functions work.
- [X] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).
/cc @woltheravKrita 5.2Merge ServiceMerge Servicehttps://invent.kde.org/graphics/krita/-/merge_requests/1732Bundle and Resource Manager: layout cleanup and normalization2023-02-19T23:07:18ZAmy sparkBundle and Resource Manager: layout cleanup and normalizationHi!
This MR proposes some cleanups and enhancements for the Bundle and Resource Manager dialogs:
- simplified layout with use of Form layout and stretching policies
- made layout consistent: left side thumbnail, right side metadata; le...Hi!
This MR proposes some cleanups and enhancements for the Bundle and Resource Manager dialogs:
- simplified layout with use of Form layout and stretching policies
- made layout consistent: left side thumbnail, right side metadata; left side controls, right side resource/bundle information
- fixed an inconsistency in the state of the Resource Manager between dialog launch and resource deselection
Screenshots are attached for each
| Before | After |
| ------ | ------ |
| ![imagen](/uploads/b3502a726e688324b1e3d29bd9685bcf/imagen.png) | ![imagen](/uploads/c9aa392b36fed0ca25de00c43db1ddca/imagen.png) |
| ![imagen](/uploads/8fde5799deacf965f52bac606b3ef9e5/imagen.png) | ![imagen](/uploads/1f8d04a0395ba5ee30f7d0e669285efc/imagen.png) |
| ![imagen](/uploads/f6b02600ffd8e9f84163e68b7d99641e/imagen.png) | ![imagen](/uploads/1dab6accdb6c72c36d83978a4fb11fd4/imagen.png) |
Test Plan
---------
Build Krita.
Formalities Checklist
---------------------
- [X] I confirmed this builds.
- [X] I confirmed Krita ran and the relevant functions work.
- [X] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).Krita 5.2Merge ServiceMerge Servicehttps://invent.kde.org/graphics/krita/-/merge_requests/1726464255 OpenGL: increase minimum to ES3 / 4.1 Compatibility / 4.1 Core2023-08-30T11:57:40ZAmy spark464255 OpenGL: increase minimum to ES3 / 4.1 Compatibility / 4.1 CoreThis is the second attempt of commit
ca645e71. For this one, I've ported Qt's
dynamic OpenGL module detection (which we cannot run at this time due to
QGuiApplication having not yet been instanced), and split the minimum
version per-oper...This is the second attempt of commit
ca645e71. For this one, I've ported Qt's
dynamic OpenGL module detection (which we cannot run at this time due to
QGuiApplication having not yet been instanced), and split the minimum
version per-operating system flavor.
For all OpenGL ES users, the new version will be fixed to 3.0 +
QSurfaceFormat::NoProfile (already the default-- CompatibilityProfile
and DeprecatedFunctions are no-ops).
For desktop GL users not on macOS, the new version will be fixed to 3.3
Compatibility. While testing, I found that it was easy to induce a
"crash" (in fact, forced process exit by X11) by asking NVIDIA's GLX
implementation to instantiate a 4.x surface if it was set to GLES
(whether by setRenderableType or by using NoProfile). For that reason
I've kept the Compatibility profile but without DeprecatedFunctions--
that way the display driver returns the maximum supported version.
For all desktop OpenGL users on a Mac, we use the Apple default and sole
supported version, 4.1 Core.
This reverts commit fa671d40.
BUG:464255
CCMAIL:kimageshop@kde.org
Test Plan
---------
This change only affects Linux desktops, so build Krita and check that Mesa/llvmpipe/Gallium is kept happy after the version change.
Formalities Checklist
---------------------
- [X] I confirmed this builds.
- [X] I confirmed Krita ran and the relevant functions work.
- [X] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).Krita 5.2Merge ServiceMerge Servicehttps://invent.kde.org/graphics/krita/-/merge_requests/1718Add Meson-ified dependencies (consolidation branch)2023-02-02T14:22:43ZAmy sparkAdd Meson-ified dependencies (consolidation branch):wave:
This MR integrates, for ease of testing and review, the 3rdparty and packaging changes from !1607 and !1599, so that we no longer need to cherry-pick the Meson fixes on both MRs.
See 3rdparty/CMakeLists.txt for the new dependen...:wave:
This MR integrates, for ease of testing and review, the 3rdparty and packaging changes from !1607 and !1599, so that we no longer need to cherry-pick the Meson fixes on both MRs.
See 3rdparty/CMakeLists.txt for the new dependencies.
Test Plan
---------
Build 3rdparty.
Formalities Checklist
---------------------
- [x] I confirmed this builds.
- [x] I confirmed Krita ran and the relevant functions work.
- [x] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).
/cc @woltherav @ivany @emmetoneill @eoinoneillKrita 5.2https://invent.kde.org/graphics/krita/-/merge_requests/1717Refactor the test suite SDK into a new library target2023-01-18T12:42:43ZAmy sparkRefactor the test suite SDK into a new library target:wave:
Yet more cleanup. In this case, I propose a refactor that simplifies greatly the setup of our test suite, through a new linkable target `kritatestsdk`.
Once linking to kritatestsdk, the system-wide definitions for looking up re...:wave:
Yet more cleanup. In this case, I propose a refactor that simplifies greatly the setup of our test suite, through a new linkable target `kritatestsdk`.
Once linking to kritatestsdk, the system-wide definitions for looking up resources, data, and output directories will be integrated into the executable harness. To finish it off, when declaring the executable to be a test via `kis_add_test` or `kis_add_benchmark`, the customized definitions will be created and inserted through `target_compile_definitions`.
There are some cleanup preliminaries I've ordered towards the beginning of this branch. Towards the end, you'll find some extra refactors made possible by this change, in particular unbreaking the Layer Docker, and cleaning up duplicated translation units in the PSD and LUT docker. (I believe these were left over from when they needed to be compiled twice due to the MODULE linkage issue. See !1500.)
Test Plan
---------
Build Krita and run its tests.
Formalities Checklist
---------------------
- [X] I confirmed this builds.
- [X] I confirmed Krita ran and the relevant functions work.
- [X] I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
- [X] I made sure my commits build individually and have good descriptions as per [KDE guidelines](https://community.kde.org/Policies/Commit_Policy).
- [X] I made sure my code conforms to the standards set in the HACKING file.
- [X] I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per [KDE Licensing Policy](https://community.kde.org/Policies/Licensing_Policy).Krita 5.2Merge ServiceMerge Service