[Discover] [Bug 397771] my updates are not allowing me to update and has been trying to update for the past 3 days and wont let me shutdown or log off my computer until its updated
https://bugs.kde.org/show_bug.cgi?id=397771 tt changed: What|Removed |Added CC||vemmabr...@hotmail.com -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 431310] New: pasting a screenshot into krita leads to ugly artifacts
https://bugs.kde.org/show_bug.cgi?id=431310 Bug ID: 431310 Summary: pasting a screenshot into krita leads to ugly artifacts Product: krita Version: 4.4.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: f...@gmx.de Target Milestone: --- SUMMARY on linux mint pasting a screencap into krita leaves ugly artifacts STEPS TO REPRODUCE 1. hit the print key and select "copy to clipboard" (on linux mint) 2. open a new file in krita 3. paste the clipboard in 4. do it 5-15 times until krita decides to paste the clipboard in without artifacts OBSERVED RESULT jpeg compression like artifacts EXPECTED RESULT crisp pixels in a 1:1 copy SOFTWARE/OS VERSIONS Linux/KDE Plasma: Mint ADDITIONAL INFORMATION after a ton of tries it works, so krita can do it, but somehow does not do it all the time -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 431310] pasting a screenshot into krita leads to ugly artifacts
https://bugs.kde.org/show_bug.cgi?id=431310 --- Comment #2 from tt --- (In reply to Tymond from comment #1) > Are you sure you have a proper size for the new file? Can you please check > if File -> New -> From Clipboard gives you better or the same results? doing what you suggested seems to give more consistent results, actually I tried a few times and saw no artifacts. But it is not the bug I reported, the bug is about pasting a screenshot from the clipboard into an already existing project. This is a workaround but no fix. I might have worded the bug description misleading, sometimes you just want to paste a screenshot into an existing project. The project resolution does not matter anyways, pasting a screenshot from clipboard into a smaller project files just hides parts of the pixel data and you can move the resulting new layer around and reveal hidden pixels. somehow krita converts clipboard pixel data to jpeg and pastes it in? the same process works flawless with gimp under the same linux (mint). -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 431310] pasting a screenshot into krita leads to ugly artifacts
https://bugs.kde.org/show_bug.cgi?id=431310 --- Comment #5 from tt --- I upgraded mint to 20.1 as of today and use krita 4.4.1 (and not 4.1.x that comes with mint) and I seem to not be able to reproduce this bug anymore. But please keep this open for a few more days, in case it happens again I can post here of course. Just like it always is, as soon as you close this bugreport it will happen again, I'm pretty sure... :P -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 431310] pasting a screenshot into krita leads to ugly artifacts
https://bugs.kde.org/show_bug.cgi?id=431310 --- Comment #6 from tt --- and it did it again, I had to exlain something wrong with blender and made a screencap and pasted it into krita, , even with a bigger canvas than my monitor and these artifacts happened: https://i.imgur.com/dyy5YPk.png after pasting it in for 7 times it pasted it in without these artifacts. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 431310] pasting a screenshot into krita leads to ugly artifacts
https://bugs.kde.org/show_bug.cgi?id=431310 --- Comment #8 from tt --- Created attachment 135169 --> https://bugs.kde.org/attachment.cgi?id=135169&action=edit krita paste pasted into krita -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 431310] pasting a screenshot into krita leads to ugly artifacts
https://bugs.kde.org/show_bug.cgi?id=431310 --- Comment #9 from tt --- Created attachment 135170 --> https://bugs.kde.org/attachment.cgi?id=135170&action=edit gimp screenshot paste pasted into gimp -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 431310] pasting a screenshot into krita leads to ugly artifacts
https://bugs.kde.org/show_bug.cgi?id=431310 --- Comment #10 from tt --- okay, since Mint 20.1 this bug happens way less than on 20.0, or maybe because I use the current Krita version and not the way outdated version from the mint package manager, but now it happened again. pasted the screenshot into krita and have these jpg like artifacts, pasted it into gimp for comparison and it is smooth. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 431310] pasting a screenshot into krita leads to ugly artifacts
https://bugs.kde.org/show_bug.cgi?id=431310 --- Comment #12 from tt --- maybe... maybe not... I already asked on the mint forums but since I can paste the very same screenshot into gimp without quality loss it is either krita or how krita communicates with the default screenshot tool of mint or how it handles the clipboard data. https://forums.linuxmint.com/viewtopic.php?f=47&t=336540 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 431182] New: ctrl+alt+I to resize has the cursor as default on the OK button
https://bugs.kde.org/show_bug.cgi?id=431182 Bug ID: 431182 Summary: ctrl+alt+I to resize has the cursor as default on the OK button Product: krita Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Resize/Scale Image/Layer Assignee: krita-bugs-n...@kde.org Reporter: f...@gmx.de Target Milestone: --- SUMMARY STEPS TO REPRODUCE hit ctrl+alt+I to resize and type a new width number, but it doesn't work as the active cursor is on the "OK" button to confirm no change at all. not intuitive or useful. Ctrl+Alt+C for crop does it right, the active cursor is in the first input field as it should be, you can type new values straight ahead. this is intuitive and for ease of use and also for consistency the active field for the resize menu should be the first input field of course. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 420045] New: resize beyond the canvas borders with crop tool
https://bugs.kde.org/show_bug.cgi?id=420045 Bug ID: 420045 Summary: resize beyond the canvas borders with crop tool Product: krita Version: 4.2.9 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Tools Assignee: krita-bugs-n...@kde.org Reporter: f...@gmx.de Target Milestone: --- please make krita more like photoshop where the crop tool lets you resize the image beyond the set canvas size to a new size. For a quick resizing workflow I totally prefer the crop tool to not stop at the set canvas size but to expand beyond it and make the resulting image bigger and NOT having to type numbers into a field and click or tab to the next field and enter more numbers without immediate visual feedback. Would you use that "enter values" methos to crop the image to a smaller size? I think not! Why not allow it for enlarging with visual feedback. It is very okay when the crop tool snaps to the current canvas size, I'd even expect that. this is no bug but not great behaviour too. If you want to delete this suggestion please send me a message before that and tell me where to add suggestions like this. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 420045] resize beyond the canvas borders with crop tool
https://bugs.kde.org/show_bug.cgi?id=420045 --- Comment #2 from tt --- I wish this setting was active in krita as default... :) thanks for mentioning the other places. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 419588] New: collapsing shortcut setting menus keeps them visible
https://bugs.kde.org/show_bug.cgi?id=419588 Bug ID: 419588 Summary: collapsing shortcut setting menus keeps them visible Product: krita Version: 4.2.9 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Shortcuts and Canvas Input Settings Assignee: krita-bugs-n...@kde.org Reporter: f...@gmx.de Target Milestone: --- SUMMARY STEPS TO REPRODUCE 1. settings > configure krita > shorcuts 2. hello>hello>sayhelloworld> expand shortcut 3. collapse from the first hello and the expanded "change shortcut" stays visible OBSERVED RESULT the he expanded "change shortcut" menu stays visible over the other options and is even resposible. EXPECTED RESULT everything collapses SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: linux mint (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 419588] collapsing shortcut setting menus keeps them visible
https://bugs.kde.org/show_bug.cgi?id=419588 --- Comment #1 from tt --- another expect behaviour would be that it is impossible to collapse anything at all in the shortcut settings when the "change shortcut" dialog is active. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487387] New: Digital clock font selector unreadable with dark theme
https://bugs.kde.org/show_bug.cgi?id=487387 Bug ID: 487387 Summary: Digital clock font selector unreadable with dark theme Classification: Plasma Product: plasmashell Version: master Platform: Other OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: Digital Clock Assignee: plasma-b...@kde.org Reporter: wr...@mar.co.tt Target Milestone: 1.0 Created attachment 169716 --> https://bugs.kde.org/attachment.cgi?id=169716&action=edit Screenshot of the font selector SUMMARY When using Breeze dark, the font selector in the digital clock has clear text on clear background, making the items in the list almost invisible STEPS TO REPRODUCE 1. Set theme to Breeze dark 2. On Digital Clock widget, right click "Configure Digital Clock" 2. Under "Appearance", select the "Manual Option" for the "Text Display" radio 3. Click "Choose Style..." button OBSERVED RESULT The list of fonts is in clear color over clear background, making it unreadable EXPECTED RESULT The list of fonts is in clear color over dark background SOFTWARE/OS VERSIONS Operating System: EndeavourOS KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.0 Graphics Platform: Wayland Graphics Processor: NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2 Manufacturer: Gigabyte Technology Co., Ltd. Product Name: B660 DS3H AX DDR4 ADDITIONAL INFORMATION I am able to replicate the bug on my laptop, with similar versions of KDE. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 487387] Use of unstyled Qt font selector dialogs constitutes a visual and usability regression
https://bugs.kde.org/show_bug.cgi?id=487387 --- Comment #2 from Marco TT --- (In reply to Nate Graham from comment #1) > Yeah, unfortunately this is going to affect almost all the font selectors > because we're using the unstyled version that comes from Qt, which doesn't > look great or integrate properly with our color scheme stuff. We're using it > because the alternative was even worse; see Bug 478155. Ah, thanks for the quick reply. Should a bug be logged to QT? I took a cursory look at their bug tracker and at a glance I don't see any ticket on QFontDialog becoming unresponsive - but I'm not a developer so it may be worded differently. -- You are receiving this mail because: You are watching all bug changes.
