| Summary: | Krita crashes upon choosing a fill layer's color | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Jan <kde> |
| Component: | Filter Layers | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | halla, kde |
| Priority: | NOR | ||
| Version: | 4.2.7.1 | ||
| Target Milestone: | --- | ||
| Platform: | macOS (DMG) | ||
| OS: | macOS | ||
| Latest Commit: | https://invent.kde.org/kde/krita/commit/1ba421bd78fb68a346aed5803b1fbe2617b5b21e | Version Fixed In: | |
|
Description
Jan
2019-11-07 18:44:12 UTC
Also a crash: 1. Create Fill layer 2. Select Color and do not click OK on the color fly out 3. Cancel the fill layer creation. 4. Do other stuff 5. Suddenly encounter the rogue color fly out that is still there, click Cancel 6. Bam! Krita´s gone. I'd suggest embedding the (a) color dialog into the Fill layer's creation dialog. I'd go for simple sliders / input fields depending on the document's color scheme plus a color picker that I can use everywhere. Usually you want precision here. Remark: upon clicking on the color field in layer creation dialog, the rogue color flyout is not even the foremost dialog, so this can happen easily. Actually it took me until now, when filing this bug, until I found out what was happening. I always had thought this was just a very unstable feature. The reason is that on macOS, Apple's native color selector dialog is used, which is not modal, on other platforms the color selector dialog is modal, so you cannot do anything until pressing okay in the color selector dialog. The reason we use the native color selector is the following: commit e6f88a3a65332d21546231349e0c36323f0c289e Author: Boudewijn Rempt <boud@valdyas.org> Date: Thu Apr 6 11:59:44 2017 +0200 BUG:378282 Use the native color selector on OSX On OSX, the only way to pick screen colors is to use the native color selector, applications cannot access other windows than their own. Why not embed just like in other implementations and add an "Advanced / Pick Color" button on MacOS that shows this dialog? Still, this crash is very vicious and has cost me lots of hours over the time (I use fill layers a lot). So somehow this should be shielded from happening. I could try to help, if someone would give me some pointers (I am new to the krita code base and have no experience in c/c++, but have coded a lot in the past). Also it seems, at least on a mac, in the native color selector you can choose a CMYK color, but once the layer is created, the color is converted to rgb and back to cmyk. For instance if I go for 100%/0/0/0, pure cyan, upon reopening the layer's properties, it has been reverted to 41%/0/1%/0. The color does not even look like pure cyan. Git commit a8c0351c749564544e6ed244b6defe76dc66a125 by Ivan Yossi. Committed on 11/11/2019 at 02:36. Pushed by rempt into branch 'master'. Close ColorDialog if parent pointer is destroyed On macOS if the parent pointer is missing there is a crash, if the parent widget is destroyed we close the colorDialog to avoid avoid crashing when interacting with the orphan ColorDialog M +5 -0 libs/widgets/kis_color_button.cpp https://invent.kde.org/kde/krita/commit/a8c0351c749564544e6ed244b6defe76dc66a125 Git commit 1ba421bd78fb68a346aed5803b1fbe2617b5b21e by Boudewijn Rempt, on behalf of Ivan Yossi. Committed on 15/11/2019 at 10:10. Pushed by rempt into branch 'krita/4.2'. Close ColorDialog if parent pointer is destroyed On macOS if the parent pointer is missing there is a crash, if the parent widget is destroyed we close the colorDialog to avoid avoid crashing when interacting with the orphan ColorDialog (cherry picked from commit a8c0351c749564544e6ed244b6defe76dc66a125) M +5 -0 libs/widgets/kis_color_button.cpp https://invent.kde.org/kde/krita/commit/1ba421bd78fb68a346aed5803b1fbe2617b5b21e |