[krita] [Bug 446360] BETA3 “copy” and “cut” layers are severely stuck
https://bugs.kde.org/show_bug.cgi?id=446360 --- Comment #3 from Wojciech Trybus --- Yes, the issue appears to be fixed in current nightly build too (5.0.0-beta3-cc9aa2f) Can I mark it as fixed, or was that result of some temporal revert or random change that only hid the bug? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 446365] New: Pattern scale slider in toolbar longer than other sliders (beta3)
https://bugs.kde.org/show_bug.cgi?id=446365 Bug ID: 446365 Summary: Pattern scale slider in toolbar longer than other sliders (beta3) Product: krita Version: unspecified Platform: Kubuntu Packages OS: Linux Status: REPORTED Keywords: regression Severity: normal Priority: NOR Component: Usability Assignee: krita-bugs-n...@kde.org Reporter: wojt...@gmail.com Target Milestone: --- Created attachment 144142 --> https://bugs.kde.org/attachment.cgi?id=144142=edit Prolonged pattern scale slider SUMMARY Pattern slider got about 2 times longer since beta2 (screenshot attached). I guess it could be longer than it used to to compensate additional multiplier combobox, but this seems unintended STEPS TO REPRODUCE 1. Change any default toolbox slider to Pattern scale SOFTWARE/OS VERSIONS Operating System: Kubuntu 20.04 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 Will change reported version from unspecified to beta3, as soon as it's enabled -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 446360] BETA3 “copy” and “cut” layers are severely stuck
https://bugs.kde.org/show_bug.cgi?id=446360 Wojciech Trybus changed: What|Removed |Added CC||wojt...@gmail.com Status|REPORTED|CONFIRMED Component|* Unknown |CPU Canvas Ever confirmed|0 |1 Keywords||regression, release_blocker --- Comment #1 from Wojciech Trybus --- Can confirm on kubuntu 20.04 too. Regression since beta2, probably a release blocker. The bug happens for both "copy" and "cut" actions, only for whole layers - copying selection of selected pixels seems unaffected. Delay takes 5 seconds regardless of layer size. Leaving the version as "unspecified" as there is no beta3 enabled yet. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 441370] KDE Plasma cursor is not displayed over docker area right after painting on 5.0 beta1
https://bugs.kde.org/show_bug.cgi?id=441370 Wojciech Trybus changed: What|Removed |Added CC||tomtomtomreportingin@gmail. ||com --- Comment #5 from Wojciech Trybus --- *** Bug 443694 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 443694] If pop-up palette is closed when the cursor is outside the palette, canvas cursor doesn't switch to system cursor when hovering into dockers
https://bugs.kde.org/show_bug.cgi?id=443694 Wojciech Trybus changed: What|Removed |Added Resolution|--- |DUPLICATE CC||wojt...@gmail.com Status|REPORTED|RESOLVED --- Comment #1 from Wojciech Trybus --- I mark it as a duplicate of a bug I reported for beta1. *** This bug has been marked as a duplicate of bug 441370 *** -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 441644] Stay on top setting for multiple views (windows) doesn't work properly.
https://bugs.kde.org/show_bug.cgi?id=441644 Wojciech Trybus changed: What|Removed |Added CC||wojt...@gmail.com --- Comment #2 from Wojciech Trybus --- As a workaround, maybe you'd like my plugin: https://youtu.be/LwUfLQAgWwA It adds a lot of logic behind subwindows behaviour - one of the features is assuring the one or two (split screen) subwindows are filling the whole available workspace, while all the other subwindows are floating as "always on top". -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 441368] Canvas displays black when changing frames in 5.0 beta1 - kubuntu
https://bugs.kde.org/show_bug.cgi?id=441368 Wojciech Trybus changed: What|Removed |Added Resolution|WAITINGFORINFO |NOT A BUG Status|NEEDSINFO |RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 441368] Canvas displays black when changing frames in 5.0 beta1 - kubuntu
https://bugs.kde.org/show_bug.cgi?id=441368 --- Comment #2 from Wojciech Trybus --- After more testing: this is caused by some of my settings - removing kritarc fixed the issue. So far I couldn't find a setting that caused it - it's not any obvious 'Display' setting, and may as well result from some add-on that left its trace in kritarc. Should I close the report as "not a bug"? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 441370] KDE Plasma cursor is not displayed over docker area right after painting on 5.0 beta1
https://bugs.kde.org/show_bug.cgi?id=441370 --- Comment #2 from Wojciech Trybus --- I think I found the true cause behind this bug. It's not related to just painting a line, but to hiding a pop-up palette using the tablet stylus, without picking a brush. NEW STEPS TO REPRODUCE: 1. Invoke pop-up palette (RMB) 2. Hide pop-up palette with stylus, without picking a brush - click with any of stylus buttons outside the pop-up. 3. Hover over docker area This does not happen when you pick a preset using the pop-up, or you use mouse or keyboard (remapped canvas input) to hide it. Clicking at the docker regains the cursor, until next time you cancel a pop-up. Turns out, I use this palette a lot, and haven't thought about using the mouse earlier while testing. I used appimage. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 441370] New: KDE Plasma cursor is not displayed over docker area right after painting on 5.0 beta1
https://bugs.kde.org/show_bug.cgi?id=441370 Bug ID: 441370 Summary: KDE Plasma cursor is not displayed over docker area right after painting on 5.0 beta1 Product: krita Version: 5.0.0-beta1 Platform: Other OS: Linux Status: REPORTED Keywords: regression Severity: normal Priority: NOR Component: Usability Assignee: krita-bugs-n...@kde.org Reporter: wojt...@gmail.com Target Milestone: --- SUMMARY Kubuntu 20.04/KDE Plasma specific. No cursor is displayed over docker area after painting on canvas. To make it visible, you need to click on docker area - bug happens every time you paint anything on canvas. STEPS TO REPRODUCE 1. Paint a line 2. Hover over the docker area OBSERVED RESULT No cursor is displayed unless clicked on docker area Operating System: Kubuntu 20.04 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 Kernel Version: 5.4.0-81-generic OS Type: 64-bit Processors: 16 × AMD Ryzen 7 2700 Eight-Core Processor Memory: 31,4 GiB -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 441368] New: Canvas displays black when changing frames in 5.0 beta1 - kubuntu
https://bugs.kde.org/show_bug.cgi?id=441368 Bug ID: 441368 Summary: Canvas displays black when changing frames in 5.0 beta1 - kubuntu Product: krita Version: 5.0.0-beta1 Platform: Kubuntu Packages OS: Linux Status: REPORTED Keywords: regression Severity: normal Priority: NOR Component: OpenGL Canvas Assignee: krita-bugs-n...@kde.org Reporter: wojt...@gmail.com Target Milestone: --- Created attachment 140950 --> https://bugs.kde.org/attachment.cgi?id=140950=edit Displaying canvas fails when went loading existing frame SUMMARY Marked as OpenGL, but also related to Animation. OpenGL fails on kubuntu 20.04 when displayed frame is changed, and other existing frame needs to get loaded. You can create new frames and draw on them, but going back to any of them causes the whole screen to go black (screenshot attached). The data is still there, and is displayed properly in the layers docker, but the only way to fix displaying the canvas is to reopen a document. Bug is Linux, or KDE Plasma specific - I confirmed it works well on Windows 10. STEPS TO REPRODUCE 1. Create a new animation document 2. Paint two frames in one layer 3. Go back to the first frame OBSERVED RESULT Black canvas as shown in screenshot SOFTWARE/OS VERSIONS Operating System: Kubuntu 20.04 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 Kernel Version: 5.4.0-81-generic OS Type: 64-bit Processors: 16 × AMD Ryzen 7 2700 Eight-Core Processor Memory: 31,4 GiB -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 441366] New: L*a*b color model got broken in 5.0 beta1
https://bugs.kde.org/show_bug.cgi?id=441366 Bug ID: 441366 Summary: L*a*b color model got broken in 5.0 beta1 Product: krita Version: 5.0.0-beta1 Platform: Kubuntu Packages OS: Linux Status: REPORTED Keywords: regression Severity: normal Priority: NOR Component: Color models Assignee: krita-bugs-n...@kde.org Reporter: wojt...@gmail.com Target Milestone: --- Created attachment 140948 --> https://bugs.kde.org/attachment.cgi?id=140948=edit Document in L*a*b SUMMARY Creating a document in L*a*b or converting RGB document to this color model, causes the color selector to display and pick corrupted colors (available colors does not make sense - screenshot attached) STEPS TO REPRODUCE 1. Create document in L*a*b OBSERVED RESULTS: corrupted color space as shown on screenshot SOFTWARE/OS VERSIONS Operating System: Kubuntu 20.04 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 Kernel Version: 5.4.0-81-generic OS Type: 64-bit Processors: 16 × AMD Ryzen 7 2700 Eight-Core Processor Memory: 31,4 GiB ADDITIONAL INFORMATION Also confirmed on Windows 10 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 441150] Storyboard Docker Bug - Frame number is not updated on moving to new frame- Krita 5.0 Beta
https://bugs.kde.org/show_bug.cgi?id=441150 Wojciech Trybus changed: What|Removed |Added CC||wojt...@gmail.com Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #1 from Wojciech Trybus --- I'd like to confirm this bug. It's not windows specific - I replicated it on Kubuntu. Timeline integration works well only from docker -> timeline, but not the other way round - It's possible to move elements on the timeline by changing amount of frames in the docker, but dragging those frames causes wrong storyboard elements to move (the frame length is changed not on a previous frame, but on the dragged one, causing mismatch). -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 423226] Drawing angle input gets 180 degree offset, when canvas is in mirror mode
https://bugs.kde.org/show_bug.cgi?id=423226 Wojciech Trybus changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #2 from Wojciech Trybus --- I'm marking my bug report as resolved, as I've noticed it started working correctly on master. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 433440] Allow calibration of tilt-direction signal
https://bugs.kde.org/show_bug.cgi?id=433440 --- Comment #1 from Wojciech Trybus --- PROPOSED GUI this feature requires only one angle widget specified in tablet settings, as shown in the attachment. ADDITIONAL INFO link to the entire discussion on KA: https://krita-artists.org/t/feature-request-global-brush-angle-offset-for-tilt-direction/17442 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 433440] New: Allow calibration of tilt-direction signal
https://bugs.kde.org/show_bug.cgi?id=433440 Bug ID: 433440 Summary: Allow calibration of tilt-direction signal Product: krita Version: unspecified Platform: Other OS: Unspecified Status: REPORTED Severity: wishlist Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: wojt...@gmail.com Target Milestone: --- Created attachment 136053 --> https://bugs.kde.org/attachment.cgi?id=136053=edit Proposed gui - angle offset selector in "Tablet Settings" SUMMARY The idea is to allow calibration of a tilt-direction signal, similarly as we do with pressure sensitivity. Angle specified by the user in the settings, would get subtracted from the tilt-direction signal before it reaches the curve in brush preset. SOLVED PROBLEMS I believe it would solve two problems with tilt sensor: 1. it would allow to unify the tilt sensitive brushes among right- and left-handed users, and those without tilt support. Right now those three types of user would experience different rotation due to the way of holding a pen, and fixing it requires changes in every single preset. 2. The angle specified in the brush editor becomes quite arbitrary, when used along with tilt-rotation. It gets especially visible with angle widget introduced in 4.4.3. PROPOSED GUI -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 432417] The fill tool instead of filling inside the lines, it fills the entire page and covers the drawing
https://bugs.kde.org/show_bug.cgi?id=432417 Wojciech Trybus changed: What|Removed |Added Resolution|--- |NOT A BUG Status|REPORTED|RESOLVED CC||wojt...@gmail.com --- Comment #1 from Wojciech Trybus --- This sounds very much like a user support question than the actual bug. Go to the tool options dock (bottom right corner by default). I believe that either: 1. your "threshold" is too big, so that the tool can go trough nearly any color (drop it down to 1) 2. "fill entire selection" is on (fills selected area without taking colors to account) 3. you're on a different layer, and either use "fast mode", or sample: "current layer". I'm marking it as "not a bug" for now. For the future I would suggest to ask at krita-artists.org first, as this is a much better place to seek help with a program, and you post a bug report only when others there confirm it's the actual issue with krita. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 432020] Color selector only in black and white
https://bugs.kde.org/show_bug.cgi?id=432020 --- Comment #2 from Wojciech Trybus --- *** Bug 432021 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 432021] Color selector only in black and white
https://bugs.kde.org/show_bug.cgi?id=432021 Wojciech Trybus changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED CC||wojt...@gmail.com --- Comment #1 from Wojciech Trybus --- *** This bug has been marked as a duplicate of bug 432020 *** -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 432020] Color selector only in black and white
https://bugs.kde.org/show_bug.cgi?id=432020 Wojciech Trybus changed: What|Removed |Added CC||wojt...@gmail.com Status|REPORTED|RESOLVED Resolution|--- |NOT A BUG --- Comment #1 from Wojciech Trybus --- Use krita-artists.org for user support. At a bar at the bottom you can see, you picked a grayscale color space. This means you don't want to use any colors other than grays, and many blending modes can't be used. Create a new artwork with 8-bit. RGB space or concert your image to this space. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 427427] New: Wrap around mode not updating properly on linux
https://bugs.kde.org/show_bug.cgi?id=427427 Bug ID: 427427 Summary: Wrap around mode not updating properly on linux Product: krita Version: 4.4.0-beta2 Platform: Other OS: Linux Status: REPORTED Keywords: regression Severity: normal Priority: NOR Component: OpenGL Canvas Assignee: krita-bugs-n...@kde.org Reporter: wojt...@gmail.com Target Milestone: --- SUMMARY Wrap around mode instead of updating exactly on time is not updating properly. Usually all the other tiles update approximately once a second, but sometimes the new line isn't displayed at all on any other tile - update needs to be forced with moving a cursor there or zooming, panning the canvas which forces the whole canvas to update. STEPS TO REPRODUCE 1. Open wrap around mode 2. draw anything OBSERVED RESULT other tiles update rarely EXPECTED RESULT immediate change as in krita 4.3 SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Kubuntu 20.04 (available in About System) KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 427153] Some self made .png patterns not read correctly in subtract alpha mode
https://bugs.kde.org/show_bug.cgi?id=427153 --- Comment #6 from Wojciech Trybus --- Big thanks for handling this issue! Yes, this would explain why I couldn't reproduce this change with any other pattern. All the default ones are in grayscale, while I always found it easier to draw a pattern on a new layer and use clipboard to move it to patterns. This results in black on transparent instead of grayscale. At least now I know how to fix my pattern in case the transparent/grayscale ones are to be differed. Sorry for the bundle not working - I had a lot of problems with it, and I don't know any other way to create it. Wish you luck on the issue, and thanks for all your work. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 427153] Some self made .png patterns not read correctly in subtract alpha mode
https://bugs.kde.org/show_bug.cgi?id=427153 --- Comment #2 from Wojciech Trybus --- Created attachment 132024 --> https://bugs.kde.org/attachment.cgi?id=132024=edit Image showing difference of the bahaviour -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 427153] New: Some self made .png patterns not read correctly in subtract alpha mode
https://bugs.kde.org/show_bug.cgi?id=427153 Bug ID: 427153 Summary: Some self made .png patterns not read correctly in subtract alpha mode Product: krita Version: 4.4.0-beta2 Platform: Other OS: Linux Status: REPORTED Keywords: regression Severity: normal Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: wojt...@gmail.com Target Milestone: --- Created attachment 132023 --> https://bugs.kde.org/attachment.cgi?id=132023=edit bundle with one of the presets that stopped working. I would add the image too, but I guess I can have only one attachment? SUMMARY I found out that presets from my brushpack are still not working the same way they did in 4.3 (even after fixing the cut-off bug). Subtract pattern behaviour changed, though the difference seems to be only on one of the .png patterns I made myself, and not on the default ones. I tried really hard to tell exactly which part of the pattern settings works differently, but couldn't find a direct answer. STEPS TO REPRODUCE 1. import the bundle I attached (contains one preset with a brushtip and pattern) 2. compare the result on krita 4.3 and 4.4b2 OBSERVED RESULT The pattern is barely visible in 4.4. It isn't subtracting most of the pixels. The preview on brush editor seems fine. EXPECTED RESULT No change in the same mode from 4.3 to 4.4 SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: kubuntu 20.04 (available in About System) KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 426874] New: Subtract alpha pattern mode changed its behaviour
https://bugs.kde.org/show_bug.cgi?id=426874 Bug ID: 426874 Summary: Subtract alpha pattern mode changed its behaviour Product: krita Version: 4.4.0-beta1 Platform: Kubuntu Packages OS: Linux Status: REPORTED Keywords: regression Severity: normal Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: wojt...@gmail.com Target Milestone: --- Created attachment 131871 --> https://bugs.kde.org/attachment.cgi?id=131871=edit Examples of not fully cut out pixels SUMMARY In the new behaviour of the subtract alpha, it is much more likely for pixels not to get fully subtracted. Especially visible with strong cut-off pattern enabled STEPS TO REPRODUCE 1. Create a new brush without any other dynamics than "pattern" 2. Pick any texture, and in its options, set texturing mode to "subtract (alpha)", cutoff policy to "cut off pattern", and place the left arrow much closer to the right one OBSERVED RESULT in 4.3 the pattern gets cut, resulting only in some painted dots (where pattern had extreme value) in 4.4 all the remaining pixels gets painted, but with the flow dependent on the pattern. It still saturates to the maximum value very easily EXPECTED RESULT Subtracting with pattern with extreme values, results in many fully subtracted pixels, not just a bit lower opacity ones. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Kubuntu 20.04 (available in About System) KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 426867] New: Color picker color squares don't hide when action is over
https://bugs.kde.org/show_bug.cgi?id=426867 Bug ID: 426867 Summary: Color picker color squares don't hide when action is over Product: krita Version: 4.4.0-beta1 Platform: Kubuntu Packages OS: Linux Status: REPORTED Keywords: regression Severity: normal Priority: NOR Component: Color Selectors Assignee: krita-bugs-n...@kde.org Reporter: wojt...@gmail.com Target Milestone: --- SUMMARY the pixels on which color squares (active and picked color) were displayed don't update when the color picking action is over. You need to hover over those areas to force it's update. Sometimes it updated in the middle of a stroke. Once I managed to make it not appear at all until restart, but couldn't recreate it. STEPS TO REPRODUCE 1. Pick a color from canvas with ctrl+LMB OBSERVED RESULT Two color squares stay visible after the ctrl is released EXPECTED RESULT color squares hide immediately after the action SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Kubuntu 20.04 (available in About System) KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 ADDITIONAL INFORMATION I own QHD display - I believe something was done with canvas tiles updating on larger than HD screens. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 425768] Allow Copy/Paste/Cut via Shortcuts to Layer Pane
https://bugs.kde.org/show_bug.cgi?id=425768 Wojciech Trybus changed: What|Removed |Added CC||wojt...@gmail.com --- Comment #1 from Wojciech Trybus --- This was already changed afaik - new copy/cut/paste logic should be available in 4.3.1 and can be tested in krita plus. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 425370] Ability to press Delete key alone instead of needing to perform PC-type delete to delete selection contents
https://bugs.kde.org/show_bug.cgi?id=425370 Wojciech Trybus changed: What|Removed |Added CC||wojt...@gmail.com --- Comment #1 from Wojciech Trybus --- There is an easy enough way to get it: go to settings > Configure krita... > Keyboard shortcuts and type "clear" . You can then assign this action to the key you want. If this should be made a default choice for mac, would probably have to be consulted with other mac users on krita artists forum. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 423226] New: Drawing angle input gets 180 degree offset, when canvas is in mirror mode
https://bugs.kde.org/show_bug.cgi?id=423226 Bug ID: 423226 Summary: Drawing angle input gets 180 degree offset, when canvas is in mirror mode Product: krita Version: unspecified Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: wojt...@gmail.com Target Milestone: --- SUMMARY Input 'drawing angle' in brush engines (both pixel and color smudge) is getting affected by the mirror mode. All the other inputs are independent of canvas mirroring, only the drawing angle gets a 180 degree offset when in this mode. Video (rotation -> drawing angle): https://youtu.be/q4cEyipjCp8 STEPS TO REPRODUCE 1. Pick any non-symetric brushtip 2. Connect any output to drawing angle (best seen with rotaton) 3. Draw with and without mirror canvas mode (M) enabled OBSERVED RESULT Brushes get 180 degree offset in mirror mode EXPECTED RESULT Mirror mode don't affect the brushes (relative to the user) SOFTWARE/OS VERSIONS Windows: Windows 10 macOS: - Linux/KDE Plasma: Kubuntu 20.04 (available in About System) KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 ADDITIONAL INFORMATION Best seen with rotation -> drawing angle connection, when the tip is rotated 180 degree, but it seems to occur with all the other outputs (tested with size which switches from minimum to maximum on the left without mirror mode, and on the right with it) Tested the issue both on Windows 10 and Kubuntu 20.04. I recreated it in krita 3.3, as that was the oldest appimage I could find fast. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 419306] Advanced color selector not closing on keyboard inputs
https://bugs.kde.org/show_bug.cgi?id=419306 --- Comment #4 from Wojciech Trybus --- (In reply to vanyossi from comment #3) > Hello there, are you getting this issue on Kubuntu or in windows? on macos > color selector closes with any action, also ig the cursor leaves the color > selection. > > We implemented a change in cea9741dd7dbb for fixing bug 418668 that probably > introduced this bug on win and linux. It happens in both kubuntu and windows 10. Closing on mouse leaving the popup works fine - it's only not closing on keyboard inputs, that can perform actions (actions are being done, popup stays as it was), and it used to react to any input without performing its action. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 419306] Advanced color selector not closing on keyboard inputs
https://bugs.kde.org/show_bug.cgi?id=419306 --- Comment #2 from Wojciech Trybus --- (In reply to wolthera from comment #1) > setting this to wishlist Of course, thank you, and sorry for the trouble. I made the bug report as Tiar asked me to on Krita-artists - according to Linx3d it was a change made by Ivan Yossi to fix another issue, and I thought it was probably unintended. Anyway it is not that severe, so I guess I will learn to live with it. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 419306] New: Advanced color selector not closing on keyboard inputs
https://bugs.kde.org/show_bug.cgi?id=419306 Bug ID: 419306 Summary: Advanced color selector not closing on keyboard inputs Product: krita Version: 4.2.9 Platform: Kubuntu Packages OS: Linux Status: REPORTED Keywords: regression Severity: normal Priority: NOR Component: Color Selectors Assignee: krita-bugs-n...@kde.org Reporter: wojt...@gmail.com Target Milestone: --- SUMMARY Pressing keyboard keys don't close the advanced color selector pop-up. Actions assigned to them are being performed instead. STEPS TO REPRODUCE 1. Open color selector (shift+i) 2. try to close it with any key with action assigned to it OBSERVED RESULT The pop-up can be closed with unassigned keys, and those acting as modifiers (ctrl, shift, v...), and by assigned keys, if actions cannot be done (undo with nothing left in undo stack, or deselect if nothing is selected). Otherwise those actions are performed without closing the pop-up. EXPECTED RESULT Pop-up closed with any keyboard input. SOFTWARE/OS VERSIONS Windows: Windows 10 Linux/KDE Plasma: Kubuntu 19.04 KDE Plasma Version: 5.15.4 KDE Frameworks Version: 5.56.0 Qt Version: 5.12.2 ADDITIONAL INFORMATION Reproduced on Windows 10. Regression occurred in Krita 4.2.9. Beta release was working well. -- You are receiving this mail because: You are watching all bug changes.
