Bug 277047

Summary: Layer lock is not respected when switching from tablet to mouse
Product: [Applications] krita Reporter: pentalis
Component: DockersAssignee: Dmitry Kazakov <dimula73>
Status: RESOLVED FIXED    
Severity: normal CC: dimula73
Priority: NOR    
Version: git master (please specify the git hash!)   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description pentalis 2011-07-04 07:40:57 UTC 
This strange bug has been there since version 2.3. I just found it.

How to reproduce:
0.- Pick either a mouse or your table to perform the steps.
1.- Make a layer, paint a little.
2.- Lock the layer, try to paint (sometimes you will still be able to paint at this point, specially in the first try).
3.- Now switch device, from mouse to tablet or tablet to mouse.
4.- Try to paint again, you will be able to paint, even though the layer is locked.
5.- If you switch layers, the locked layer will start behaving correctly again.

Expected results:
The locked layer always behaves as if locked, no matter if the input device change.
Comment 1 Dmitry Kazakov 2012-02-25 06:40:29 UTC 
I cannot reproduce exactly the bug you describe, but I can see another one here:

1) Lock the layer with mouse
2) Try to paint something with mouse (nothing is painted)
3) Try to paint something with tablet (nothing is painted)
4) Unlock layer with tablet

Here you cannot paint anything on a tablet until you reactivate the tool.
Comment 2 Dmitry Kazakov 2012-02-25 07:07:18 UTC 
I'll try to take a look at it.
Comment 3 Dmitry Kazakov 2012-02-29 08:31:37 UTC 
Git commit 3a9a73d330066400e159845fe590865ff8dee8a2 by Dmitry Kazakov.
Committed on 25/02/2012 at 12:53.
Pushed by dkazakov into branch 'master'.

Fixed a tool activation when the current layer is not enabled

Way to reproduce:
1) Open new document
2) Disable a layer with a mouse
3) Enable a layer with a tablet
You will not be able to paint with the tablet.

What actually happened was that a new CanvasData was created, but
the previous tool could not be activated in the new data, because of
an explicit check in switchTool. So that we ended up in a state with
no tool at all.

This patch brings a bit more consistency there. Now you can always
switch the tool in the KoToolManager, even when active layer is
disabled, but the KoToolProxy will get information about the new tool
only when the layer gets enabled back. This is what the code in
currentLayerChanged() and toolCanBeUsed() has been doing before. There was
inconsistency in postSwitchTool(), because it didn't check for the
availability of the active layer, now it is gone.

M  +13   -27   libs/flake/KoToolManager.cpp
M  +2    -2    libs/flake/KoToolManager_p.h

http://commits.kde.org/calligra/3a9a73d330066400e159845fe590865ff8dee8a2