Bug 456807 - Problems with the gradient fill for vectors in the Tool Options docker.
Summary: Problems with the gradient fill for vectors in the Tool Options docker.
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Unclassified
Component: Tools/Vector (show other bugs)
Version: 5.0.6
Platform: Android Other
: NOR normal
Target Milestone: ---
Assignee: sh_zam
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-07-16 17:16 UTC by YetAnotherKritaUser
Modified: 2022-08-09 08:05 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Krita usage log (17.82 KB, text/plain)
2022-07-20 16:07 UTC, YetAnotherKritaUser
Details
One of 4 screenshots (1.08 MB, image/jpeg)
2022-07-20 16:09 UTC, YetAnotherKritaUser
Details
2 of 4 screenshots (1.01 MB, image/jpeg)
2022-07-20 16:10 UTC, YetAnotherKritaUser
Details
3 of 4 screenshots (1.07 MB, image/jpeg)
2022-07-20 16:10 UTC, YetAnotherKritaUser
Details
4 of 4 screenshots showing what I've found. (1.12 MB, image/jpeg)
2022-07-20 16:11 UTC, YetAnotherKritaUser
Details
The crash log. (572 bytes, text/plain)
2022-07-22 12:06 UTC, YetAnotherKritaUser
Details
Tested latest debug version pic #1 (567.61 KB, image/jpeg)
2022-07-26 16:32 UTC, YetAnotherKritaUser
Details
New debug Test pic #2 (658.91 KB, image/jpeg)
2022-07-26 16:33 UTC, YetAnotherKritaUser
Details
From 5.2.0-prealpha a80d206 (714.28 KB, image/jpeg)
2022-07-27 17:47 UTC, YetAnotherKritaUser
Details
#2 From 5.2.0-prealpha a80d206 (675.76 KB, image/jpeg)
2022-07-27 17:48 UTC, YetAnotherKritaUser
Details
#3 From 5.2.0-prealpha a80d206 (624.78 KB, image/jpeg)
2022-07-27 17:48 UTC, YetAnotherKritaUser
Details
#4 From 5.2.0-prealpha a80d206 (581.76 KB, image/jpeg)
2022-07-27 17:48 UTC, YetAnotherKritaUser
Details
#5 From 5.2.0-prealpha a80d206 (529.87 KB, image/jpeg)
2022-07-27 17:49 UTC, YetAnotherKritaUser
Details

Note You need to log in before you can comment on or make changes to this bug.
Description YetAnotherKritaUser 2022-07-16 17:16:11 UTC
SUMMARY
***
NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols.
See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***


STEPS TO REPRODUCE
1. Within the gradient fill for vectors Tool Docker: select a color to make a gradient
2. 
3. 

OBSERVED RESULT
The selected area is deselected after I chose the 1st color. It does the same thing when I chose the 2nd color. I can’t get the right color from the source photo.


EXPECTED RESULT
What I expect: ability to select color for gradients and solids from the reference image, and/or the raster layer.


SOFTWARE/OS VERSIONS
Android: 12
Windows: 10
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 5.12.12

ADDITIONAL INFORMATION
I reported the bug as suggested by @AhabGreybeard in this thread: https://krita-artists.org/t/trouble-with-gradient-for-vector-on-android/43394

From AhabGreybeard who also tested and found the following:
Testing on Windows 10 with 5.0.6 and 5.1.0-beta2:
The 5.1.0-beta2 no longer has the refusal to edit the end stop problem but it seems to have more problems.
At one point with 5.0.6, I totally lost the FG-> BG gradient and had two GPS Eye (Blue) gradients.
Then the gradient collection went back to normal after I closed 5.0.6 and started 5.1.0-beta2 and then had more bugs.

What is happening: Color selection for gradient is not working when on Vector layer, cannot select colors from reference image. Also, colors selected from raster layer aren’t carried over to Vector layer. Color seems to be able to be chosen from the installed palettes Only.
Suggestion: The Gradient tool should use the gradient that’s been set up already.
On a side note: when moving the gradient handles, (within the Vector shape) the gradient area seems to blink (on Android).
Problem is present on both Android and Windows 10
Comment 1 sh_zam 2022-07-17 11:04:27 UTC
Can confirm the bug. Assigning to myself.
Comment 2 sh_zam 2022-07-19 10:11:00 UTC
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.
Comment 3 Bug Janitor Service 2022-07-20 15:54:46 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1526
Comment 4 YetAnotherKritaUser 2022-07-20 16:07:59 UTC
Created attachment 150769 [details]
Krita usage log

The usage log. I think it will have all the times that it was started.
Comment 5 YetAnotherKritaUser 2022-07-20 16:09:35 UTC
Created attachment 150770 [details]
One of 4 screenshots
Comment 6 YetAnotherKritaUser 2022-07-20 16:10:05 UTC
Created attachment 150771 [details]
2 of 4 screenshots
Comment 7 YetAnotherKritaUser 2022-07-20 16:10:40 UTC
Created attachment 150772 [details]
3 of 4 screenshots
Comment 8 YetAnotherKritaUser 2022-07-20 16:11:17 UTC
Created attachment 150773 [details]
4 of 4 screenshots showing what I've found.
Comment 9 YetAnotherKritaUser 2022-07-20 16:12:56 UTC
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?
Comment 10 sh_zam 2022-07-22 08:43:18 UTC
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
Comment 11 sh_zam 2022-07-22 09:09:37 UTC
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.
Comment 12 YetAnotherKritaUser 2022-07-22 12:06:36 UTC
Created attachment 150817 [details]
The crash log.

Here the crash log that you asked for.
Comment 13 sh_zam 2022-07-25 06:20:41 UTC
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
Comment 14 sh_zam 2022-07-26 08:49:09 UTC
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?
Comment 15 YetAnotherKritaUser 2022-07-26 16:29:31 UTC
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.
Comment 16 YetAnotherKritaUser 2022-07-26 16:32:54 UTC
Created attachment 150923 [details]
Tested latest debug version pic #1
Comment 17 YetAnotherKritaUser 2022-07-26 16:33:53 UTC
Created attachment 150924 [details]
New debug Test pic #2
Comment 18 YetAnotherKritaUser 2022-07-26 16:35:31 UTC
(In reply to sh_zam from comment #14)

P.S. do you need the latest usage log?
Comment 19 sh_zam 2022-07-27 07:14:26 UTC
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 :)
Comment 20 YetAnotherKritaUser 2022-07-27 17:44:15 UTC
(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...
Comment 21 YetAnotherKritaUser 2022-07-27 17:47:22 UTC
Created attachment 150947 [details]
From 5.2.0-prealpha a80d206
Comment 22 YetAnotherKritaUser 2022-07-27 17:48:00 UTC
Created attachment 150948 [details]
#2 From 5.2.0-prealpha a80d206
Comment 23 YetAnotherKritaUser 2022-07-27 17:48:26 UTC
Created attachment 150949 [details]
#3 From 5.2.0-prealpha a80d206
Comment 24 YetAnotherKritaUser 2022-07-27 17:48:56 UTC
Created attachment 150950 [details]
#4 From 5.2.0-prealpha a80d206
Comment 25 YetAnotherKritaUser 2022-07-27 17:49:21 UTC
Created attachment 150951 [details]
#5 From 5.2.0-prealpha a80d206
Comment 26 sh_zam 2022-07-28 15:58:17 UTC
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
Comment 27 sh_zam 2022-07-28 15:58:49 UTC
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
Comment 28 sh_zam 2022-08-01 05:16:31 UTC
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).
Comment 29 sh_zam 2022-08-01 05:54:02 UTC
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
Comment 30 sh_zam 2022-08-09 08:05:43 UTC
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