| Summary: | If Krita loads with the Eraser as default brush, it paints to black when used | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | amyspark <amy> |
| Component: | Brush Engine/Shape | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dimula73, scottpetrovic |
| Priority: | NOR | ||
| Version First Reported In: | 4.0.1 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/krita/686e733dd03269bb43a745d7110132f38424f3f0 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: | Video provided by zveryok of the bug | ||
Confirmed on my Ubuntu 17.10 box. I started looking at this, but it appears it might be a bit deeper than I thought. The code that loads the preset when the application starts is here KisViewManager::setCurrentView(KisView *view):409 When this function grabs the last used preset, it grabs the correct name. The code seems to think the composite mode is "normal" and erase mode is set to false which isn't what is saved in the preset. There must be something that hasn't been loaded correctly when this gets called. (In reply to Scott Petrovic from comment #2) > I started looking at this, but it appears it might be a bit deeper than I > thought. The code that loads the preset when the application starts is here > > KisViewManager::setCurrentView(KisView *view):409 > > When this function grabs the last used preset, it grabs the correct name. > The code seems to think the composite mode is "normal" and erase mode is set > to false which isn't what is saved in the preset. There must be something > that hasn't been loaded correctly when this gets called. Go to KisPaintopBox::setCurrentPaintop(KisPaintOpPresetSP preset) and check preset->settings()->eraserMode(). It (somehow) does not save/load that it has the Eraser enabled. The bug sounds weird, because the normal erasers were never expected to have Eraser Mode active, instead they were expected to have a Eraser composite op set... Git commit 686e733dd03269bb43a745d7110132f38424f3f0 by L. E. Segovia. Committed on 15/05/2018 at 18:42. Pushed by lsegovia into branch 'amyspark/D12832-eraser-fix'. Fix Eraser not loading upon first launching Krita This is a mix of: - The paintopbox not receiving the change of compositeop. - Qt messing up with Krita's highlightable buttons. - The paintopbox loading the preset before setCurrentView, which borks Qt from emitting the relevant update signals. Differential Revision: https://phabricator.kde.org/D12832 M +1 -1 libs/ui/KisViewManager.cpp M +6 -0 libs/ui/kis_action_manager.cpp M +49 -19 libs/ui/kis_paintop_box.cc https://commits.kde.org/krita/686e733dd03269bb43a745d7110132f38424f3f0 |
Created attachment 112417 [details] Video provided by zveryok of the bug (bug found by zveryok on #pepper&carrot) If Krita is closed with the Eraser selected, next time Krita is opened and the Eraser is used, it paints with the foreground color until it is *deselected* and the application closed. Reproduced under Arch Linux (zveryok, attached video) and MacOS Sierra 10.12.6 and Windows 7 x64 (amyspark).