| Summary: | Brush properties widget (on the right) in Popup Palette becomes smaller and smaller | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Tim Čas <darkuranium> |
| Component: | Dockers | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | damian.nsp, halla, kekomit, snopmark, teodora.chiosa |
| Priority: | NOR | ||
| Version First Reported In: | 4.2.2 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | https://invent.kde.org/kde/krita/commit/ed1bf6eefcc919b15f0bb88d98cd72a95dad9dd2 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: |
Screenshots
Here's a screenshot of the bug. |
||
To clarify: When I said this:
> If the issue does not immediately appear, it seems to be triggered by clicking & dragging on the up/down arrows next to a property (but only with some brushes).
I meant that it seems to *also* be triggered by that. Though I am not 100% certain about that (it is definitely also triggered by changing the selected brush, however).
I also get this bug in Krita version 4.2.7.1 on Windows 10 64-bit. I have also added a screenshot. Created attachment 123094 [details]
Here's a screenshot of the bug.
I had the same issue with 4.2.8 desktop version Whatever I clicked in that section (sliders, options, tags, even changing the brush) made the sliders smaller. I went to the IRC chatroom, told me to try 4.1.7 portable version. So I opened a new canvas and did the same thing and there too was the same issue. That was until I restarted the portable version and fixed itself, I even clicked in troublesome corners and was fine too. (with and without full canvas mode) So then I opened the 4.2.8 version and it fixed itself there too (for now, because I've had this issue for a while and I don't remember what version I was using) I'm using Windows 7 home basic *** Bug 417037 has been marked as a duplicate of this bug. *** *** Bug 420242 has been marked as a duplicate of this bug. *** Git commit 93bdd1d6f56092e2f229dc6202aa068f4526ddbc by Mathias Wein. Committed on 01/05/2020 at 01:06. Pushed by mwein into branch 'master'. Fix Brush HUD width adjustment This time hopefully for real. There are two issues to bypass: 1) Layouts don't just instantly calculate new dimension as you modify them, it would be way too expensive, so Qt has a delayed pass for that in the event loop. So we need to wait until this has happened for the properties layout before resizing. 2) QScrollArea has a pretty broken sizeHint() implementation. It will just not give us a useful size that we could use. See also QTBUG-76256 and QTBUG-58447 The most sane solution I could come up with is to install the HUD widget as event filter for the content widget of the scroll area, and catch the LayoutRequest event. This event gets sent by the layout to the parent widget to indicate its new dimension are now available. This is what Q(Abstract)ScrollArea does internally anyway, so even fixing the sizeHint and waiting for the event to trigger again on the outer layout just costs another loop iteration and results in multiple screen updates. Since we need to adjust the width a few levels up, we need to calculate the margins our self, but the layout is not overly complex luckily. M +17 -1 libs/ui/brushhud/kis_brush_hud.cpp M +1 -0 libs/ui/brushhud/kis_brush_hud.h https://invent.kde.org/kde/krita/commit/93bdd1d6f56092e2f229dc6202aa068f4526ddbc Git commit ed1bf6eefcc919b15f0bb88d98cd72a95dad9dd2 by Boudewijn Rempt, on behalf of Mathias Wein. Committed on 02/05/2020 at 08:07. Pushed by rempt into branch 'krita/4.3'. Fix Brush HUD width adjustment This time hopefully for real. There are two issues to bypass: 1) Layouts don't just instantly calculate new dimension as you modify them, it would be way too expensive, so Qt has a delayed pass for that in the event loop. So we need to wait until this has happened for the properties layout before resizing. 2) QScrollArea has a pretty broken sizeHint() implementation. It will just not give us a useful size that we could use. See also QTBUG-76256 and QTBUG-58447 The most sane solution I could come up with is to install the HUD widget as event filter for the content widget of the scroll area, and catch the LayoutRequest event. This event gets sent by the layout to the parent widget to indicate its new dimension are now available. This is what Q(Abstract)ScrollArea does internally anyway, so even fixing the sizeHint and waiting for the event to trigger again on the outer layout just costs another loop iteration and results in multiple screen updates. Since we need to adjust the width a few levels up, we need to calculate the margins our self, but the layout is not overly complex luckily. (cherry picked from commit 93bdd1d6f56092e2f229dc6202aa068f4526ddbc) M +17 -1 libs/ui/brushhud/kis_brush_hud.cpp M +1 -0 libs/ui/brushhud/kis_brush_hud.h https://invent.kde.org/kde/krita/commit/ed1bf6eefcc919b15f0bb88d98cd72a95dad9dd2 |
Created attachment 121435 [details] Screenshots SUMMARY The brush properties widget in the Popup Palette becomes smaller and smaller as it's (re)opened. STEPS TO REPRODUCE 0. Create a new image, or open existing 1. Open popup palette 2. Close popup palette 3. Repeat steps 1 & 2 as necessary; brush changes may be required to trigger the bug in some cases (as opposed to merely open/close) OBSERVED RESULT (tl;dr: see "krita-bug.mkv" within the attached archive) The brush properties widget within the Popup Palette will become smaller and smaller as it's reopened (compare "popup-palette-1.png" and "popup-palette-2.png"), eventually making the brush properties useless. If the issue does not immediately appear, it seems to be triggered by clicking & dragging on the up/down arrows next to a property (but only with some brushes). Brush changes seem to speed up the process, although it is quite fast as it is. EXPECTED RESULT The widget should not shrink as the palette is closed & reopened, but stay the same size. SOFTWARE/OS VERSIONS Krita: 4.2.2 Windows: 10 Education N (64-bit) ADDITIONAL INFORMATION The issue seems to only happens once per program start --- and the abnormal size is only present on the image where it happens (in other words: creating another image and trying the same thing seems to not trigger the bug again). This happens with both a mouse *and* a drawing tablet. I can reproduce this issue the vast majority of the time without needing a brush change to trigger it (approximately 25 out of 30 tests), and 100% of the time with a brush change. In no case did it ever reappear after I had opened a 2nd image.