| Summary: | Problems with the gradient fill for vectors in the Tool Options docker. | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | YetAnotherKritaUser <sesapj> |
| Component: | Tools/Vector | Assignee: | sh_zam <shzam> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | shzam |
| Priority: | NOR | ||
| Version: | 5.0.6 | ||
| Target Milestone: | --- | ||
| Platform: | Android | ||
| OS: | Other | ||
| Latest Commit: | https://invent.kde.org/graphics/krita/commit/591c4145f7dea43b92a5fcb95397a1b693b370a7 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: |
Krita usage log
One of 4 screenshots 2 of 4 screenshots 3 of 4 screenshots 4 of 4 screenshots showing what I've found. The crash log. Tested latest debug version pic #1 New debug Test pic #2 From 5.2.0-prealpha a80d206 #2 From 5.2.0-prealpha a80d206 #3 From 5.2.0-prealpha a80d206 #4 From 5.2.0-prealpha a80d206 #5 From 5.2.0-prealpha a80d206 |
||
|
Description
YetAnotherKritaUser
2022-07-16 17:16:11 UTC
Can confirm the bug. Assigning to myself. Hello! I've fixed the bug (https://invent.kde.org/szaman/krita/-/commits/bug-456807-focus-issue-android). I haven't pushed it to main Krita yet, because it is somewhat a bug prone area and I want to confirm everything (window management, floating dockers, brush editor) runs like it used to before but with bug fixed. Can you please test the APK: https://drive.google.com/file/d/1iii7nRIMMNmwHMbM2KeQbnw3H0HTVMo8/view?usp=sharing to verify this. The APK should be installed side-by-side, so you won't lose your configs or anything such. A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1526 Created attachment 150769 [details]
Krita usage log
The usage log. I think it will have all the times that it was started.
Created attachment 150770 [details]
One of 4 screenshots
Created attachment 150771 [details]
2 of 4 screenshots
Created attachment 150772 [details]
3 of 4 screenshots
Created attachment 150773 [details]
4 of 4 screenshots showing what I've found.
From testing the debug apk... Crashed once when I was choosing color for Gradient. What I did: Select shape tool Select area Try to choose Gradient fill tool. Sometimes it will work, other times, I have to tap on the Line tool first then it will allow the Gradient fill to work. Is there some way to allow the tools for Vector to be moved next to each other? Git commit 597aa06ca2bacadd81546c9afbb6abd0efe75f46 by Sharaf Zaman. Committed on 22/07/2022 at 08:13. Pushed by szaman into branch 'master'. Bugfix: remove an incorrectly placed SAFE_ASSERT - which resulted in a bug where gradient wouldn't change using the gradient selector drop-down menu. This shouldn't be considered buggy to use the same gradient to update the UI. One non buggy use case is, if we're on a different tab (like color) and we come back to the gradient tab, even though the gradient didn't change, the UI update would still use the same `d->activeGradient`. M +0 -4 libs/ui/widgets/KoFillConfigWidget.cpp https://invent.kde.org/graphics/krita/commit/597aa06ca2bacadd81546c9afbb6abd0efe75f46 Hi, thank you for testing! I've fixed the problems with selecting and changing gradient resource from the drop-down. (In reply to YetAnotherKritaUser from comment #9) > From testing the debug apk... > > Crashed once when I was choosing color for Gradient. Can you please share the crash log file: by going to Help -> Show crash log for bug reports? > Is there some way to allow the tools for Vector to be moved next to each > other? You mean, moving the options in Tool Options Docker next to "Select Shapes Tool" etc? No, I don't think there's a way to do that, if I'm not mistaken. Created attachment 150817 [details]
The crash log.
Here the crash log that you asked for.
Git commit bbbfefc5854160c6eddd0bb4fb7d85cbf0eee70f by Sharaf Zaman. Committed on 25/07/2022 at 05:33. Pushed by szaman into branch 'master'. Bugfix: selecting shapes wouldn't enable KoFillConfigWidget This signal was wrongly (in fc362afcb2) removed under the assumption it is an alias to `selectionContentChanged()` signal. This signal doesn't need blockers, like it did previously, because the blockers were meant to stop the selectionContentChanged (e.g we change the color and it would fire selectionContentChanged(), to which we'd respond with again updating color -- a cycle). M +2 -0 libs/ui/widgets/KoFillConfigWidget.cpp https://invent.kde.org/graphics/krita/commit/bbbfefc5854160c6eddd0bb4fb7d85cbf0eee70f Hello, thank you for testing! I've fixed the problem mentioned in Screenshot 1, 3 and fixed the crash. Can you please re-test the APK. I've uploaded a version 2 of the APK at the same link. I didn't fix the problem in screenshot 2 -- because that is a problem in a core part of how vectors are rendered inside Krita and it isn't a regression, is it? I didn't quite understand the comment, "core part of how vectors are rendered inside Krita and it isn't a regression." For the 2nd screenshot... The one that I mentioned that the color handles were hard to move? I did some testing of the new Debug version and I'll attach some screenshots of what I tested so far. Created attachment 150923 [details]
Tested latest debug version pic #1
Created attachment 150924 [details]
New debug Test pic #2
(In reply to sh_zam from comment #14) P.S. do you need the latest usage log? oh my bad! I uploaded the version which doesn't have the fix for _this_ specific problem. I've uploaded the APK which fixes the color picking problem.
> For the 2nd screenshot... The one that I mentioned that the color handles were hard to move?
Yes, I meant to say that the problem with dragging vector handles also exists in Krita's Play Store version (right?), so this is something we can fix separately not necessarily in this ticket :)
(In reply to sh_zam from comment #19) Here's my findings: Preset keeps getting changed from foreground/background to foreground/alpha When desired preset is selected, the colors get changed to grey/white Tried to change the 1st color, couldn't use the Advanced Color Selector which has the color history (and therefore the desired palette.) Things I did: 1) Select area 2) Change gradient type 3) Colors change to grey/white 4) Tap first color 5) Use Advanced Color selector... Nothing happens 6) Must use the other selector (see screenshot) 7) Finally get right color 8) Select 2nd color handle 9) Repeat procedure (#5 onward) 10) Choosing color from Advanced Color Selector works, However... 11) Gradient preset gets changed to foreground/alpha 12) Color swatches on top toolbar get changed both to the same color. Will attach more screenshots... Created attachment 150947 [details]
From 5.2.0-prealpha a80d206
Created attachment 150948 [details]
#2 From 5.2.0-prealpha a80d206
Created attachment 150949 [details]
#3 From 5.2.0-prealpha a80d206
Created attachment 150950 [details]
#4 From 5.2.0-prealpha a80d206
Created attachment 150951 [details]
#5 From 5.2.0-prealpha a80d206
Git commit ed46cf17aa9ca64b6446a061f58f8d23aff5ef68 by Sharaf Zaman. Committed on 28/07/2022 at 15:55. Pushed by szaman into branch 'krita/5.1'. Bugfix: remove an incorrectly placed SAFE_ASSERT - which resulted in a bug where gradient wouldn't change using the gradient selector drop-down menu. This shouldn't be considered buggy to use the same gradient to update the UI. One non buggy use case is, if we're on a different tab (like color) and we come back to the gradient tab, even though the gradient didn't change, the UI update would still use the same `d->activeGradient`. (cherry picked from commit 597aa06ca2bacadd81546c9afbb6abd0efe75f46) M +0 -4 libs/ui/widgets/KoFillConfigWidget.cpp https://invent.kde.org/graphics/krita/commit/ed46cf17aa9ca64b6446a061f58f8d23aff5ef68 Git commit c7271b351e8b0bb69e281e3aacabf903dfbd6d92 by Sharaf Zaman. Committed on 28/07/2022 at 15:55. Pushed by szaman into branch 'krita/5.1'. Bugfix: selecting shapes wouldn't enable KoFillConfigWidget This signal was wrongly (in fc362afcb2) removed under the assumption it is an alias to `selectionContentChanged()` signal. This signal doesn't need blockers, like it did previously, because the blockers were meant to stop the selectionContentChanged (e.g we change the color and it would fire selectionContentChanged(), to which we'd respond with again updating color -- a cycle). (cherry picked from commit bbbfefc5854160c6eddd0bb4fb7d85cbf0eee70f) M +2 -0 libs/ui/widgets/KoFillConfigWidget.cpp https://invent.kde.org/graphics/krita/commit/c7271b351e8b0bb69e281e3aacabf903dfbd6d92 Hello! I'm afraid I can't reproduce this. I can't use Advanced Color Selector with either color stops and it is an expected behavior now. Because the stop color selector is a modal window (just like it is on the desktop). Git commit 75bc7997264751fd25991ac25282aa2ac70e503a by Sharaf Zaman. Committed on 28/07/2022 at 18:35. Pushed by szaman into branch 'master'. Android: Handle bug with modality of windows The issue was that there was no provision of modality in Qt Android plugin. So we added that, the popups still get higher preference over modal windows if the event is in the area of popup's bounding rect. The oversight in previous fix of the similar bug was that I had assumed that "focus" wouldn't shift to the object which we are color picking, it didn't happen for everything but did happen for canvas where the selected vector shape would be deselected. A +115 -0 3rdparty/ext_qt/0001-Android-Fix-incorrect-handling-of-window-modality.patch M +1 -0 3rdparty/ext_qt/CMakeLists.txt M +0 -4 libs/widgets/KisDlgInternalColorSelector.h https://invent.kde.org/graphics/krita/commit/75bc7997264751fd25991ac25282aa2ac70e503a Git commit 591c4145f7dea43b92a5fcb95397a1b693b370a7 by Sharaf Zaman. Committed on 09/08/2022 at 07:38. Pushed by szaman into branch 'krita/5.1'. Android: Handle bug with modality of windows The issue was that there was no provision of modality in Qt Android plugin. So we added that, the popups still get higher preference over modal windows if the event is in the area of popup's bounding rect. The oversight in previous fix of the similar bug was that I had assumed that "focus" wouldn't shift to the object which we are color picking, it didn't happen for everything but did happen for canvas where the selected vector shape would be deselected. (cherry picked from commit 75bc7997264751fd25991ac25282aa2ac70e503a) A +115 -0 3rdparty/ext_qt/0001-Android-Fix-incorrect-handling-of-window-modality.patch M +1 -0 3rdparty/ext_qt/CMakeLists.txt M +0 -4 libs/widgets/KisDlgInternalColorSelector.h https://invent.kde.org/graphics/krita/commit/591c4145f7dea43b92a5fcb95397a1b693b370a7 |