Bug 355886 - Brush preset choice from quick menu not affecting the choice in docker and the other way around (issue of one preset always active in chosen tag)
Summary: Brush preset choice from quick menu not affecting the choice in docker and th...
Status: RESOLVED DUPLICATE of bug 348120
Alias: None
Product: krita
Classification: Applications
Component: Usability (show other bugs)
Version: 2.9.9
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
: 357913 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-11-25 11:06 UTC by kalia24
Modified: 2016-07-08 14:15 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Testing clip (3.56 MB, video/mp4)
2016-04-10 13:07 UTC, Marcus Kjeldsen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kalia24 2015-11-25 11:06:12 UTC
Most of the time I'm using presets from my Favourite tag mapped to quick-choice menu, but sometimes I need one brush from other tag - so instead of making mess in tags (99% that I'd forgot to change things back after I'm done with the work), I just open the additional tag in the Brush Presets docker. Problem is: when I choose a brush from that additional tag, then change to some of my Fav, then I can't choose that additional one again, since it's still selected in docker (though the brush in fact is working in other preset chosen through quick menu). Only way then is activating some other preset from additional tag and then the preset I need. Worst case is when tag contains only one preset - it's impossible at all to chose it then!
Issue in general - there's always one preset chosen in the tag selected in Brush Presets docker, no matter what the actual brush settings are. So even when u choose some tag in the docker, u have one preset active, but u can't use it until u chose it again, which is impossible if there's no other preset in the tag.

Reproducible: Always

Steps to Reproduce:
1. Select some preset from Brush Presets docker.
2. Select some preset from quick menu (RMB for me).
3. U can't choose the preset from step 1 again, since it's still "active".
3a. Create some tag and assign only one preset to in.
3b. Choose the one-preset tag in Brush Presets docker - u can't activate this lone preset at all.

Actual Results:  
Unable to choose brush preset I need, since it's marked as "active" even though it's not.

Expected Results:  
Only the preset that is really in use should be marked as "active", every other should be available for activating.
Comment 1 wolthera 2016-01-13 13:29:54 UTC
*** Bug 357913 has been marked as a duplicate of this bug. ***
Comment 2 Marcus Kjeldsen 2016-04-10 09:31:49 UTC
Seems to work well (for me at least) in 2.9.11 and 3.0 Alpha 1 :)
Comment 3 kalia24 2016-04-10 11:09:54 UTC
For me in 2.9.11 it's still the same - changing preset through RMB menu doesn't deactivate the choice in Presets docker, so it's still impossible to choose it once more.
Are u sure u're checking the same thing as described above?
Note that the set in Presets docker is NOT the one under RMB, but some other set (in case of the same set in RMB menu and docker it works indeed, but that's not the point of this issue).
Comment 4 Marcus Kjeldsen 2016-04-10 13:07:58 UTC
Created attachment 98320 [details]
Testing clip

Could be I'm not doing it correctly of course :) I'm attaching a [poorly recorded] clip with testing on 2.9.11.

I'm selecting a preset in the docker, selecting a preset from the right click menu, and also from the dropdown in the toolbar. It appears like the preset selection is updating as it should in all places. I am drawing brushstrokes inbetween, though. Would that make a difference?
Comment 5 Marcus Kjeldsen 2016-04-10 13:09:17 UTC
Aaand of course I missed that the set has to be different :D I'll have another look ;)
Comment 6 Marcus Kjeldsen 2016-04-10 13:11:35 UTC
Yup, I can indeed confirm for both 2.9.11 and for 3.0 Alpha 1 :) Good catch.
Comment 7 Halla Rempt 2016-04-11 06:55:10 UTC
Let's confirm then.
Comment 8 wolthera 2016-07-08 14:15:53 UTC

*** This bug has been marked as a duplicate of bug 348120 ***