[krita] [Bug 411124] New: Merge Group on invisible group layer crashes krita
https://bugs.kde.org/show_bug.cgi?id=411124 Bug ID: 411124 Summary: Merge Group on invisible group layer crashes krita Product: krita Version: 4.2.5 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: Layer Stack Assignee: krita-bugs-n...@kde.org Reporter: captains...@gmail.com Target Milestone: --- If a group layer with any sublayers is set to invisible and "Merge Group" is selected from the right-click menu on that group in the layers docker, Krita crashes. STEPS TO REPRODUCE 1. Create a new image 2. Create a group layer and add at least one layer to it (or right-click an existing layer -> Group -> Quick Group) 3. Make that group layer invisible by clicking its eye icon in the layers docker 4. Right-click that group layer and click "Merge Group" OBSERVED RESULT Krita crashes immediately. EXPECTED RESULT Either the group should be merged and remain invisible, a message should appear saying this action makes little sense, or "Merge Group" should be greyed out if the user shouldn't be doing that in that situation in the first place. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kernel 4.15.0-58-generic (via Ubuntu) (available in About System) KDE Plasma Version: 5.12.8 KDE Frameworks Version: 5.47.0 Qt Version: 5.9.5 ADDITIONAL INFORMATION With some additional testing, I've seen this NOT crash a few times with the exact same inputs. I'd put it at around a 95% crash rate, though. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 408225] Canvas itself becomes transparent with transparent pixels, showing what is behind the Krita window
https://bugs.kde.org/show_bug.cgi?id=408225 --- Comment #7 from Nicholas Killewald --- Looks like it's fixed in 4.2.1. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 408225] Canvas itself becomes transparent with transparent pixels, showing what is behind the Krita window
https://bugs.kde.org/show_bug.cgi?id=408225 --- Comment #3 from Nicholas Killewald --- Sure, here's the output: OpenGL Info Vendor: "NVIDIA Corporation" Renderer: "GeForce GTX 970/PCIe/SSE2" Version: "4.6.0 NVIDIA 390.116" Shading language: "4.60 NVIDIA" Requested format: QSurfaceFormat(version 3.0, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) Current format:QSurfaceFormat(version 4.6, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) Version: 4.6 Supports deprecated functions true is OpenGL ES: false QPA OpenGL Detection Info supportsDesktopGL: true supportsOpenGLES: true isQtPreferOpenGLES: false == log == Supported renderers: QFlags(0x2|0x4) Surface format preference list: * QSurfaceFormat(version 3.0, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) QSurfaceFormat::RenderableType(OpenGL) * QSurfaceFormat(version 3.0, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) QSurfaceFormat::RenderableType(OpenGLES) Probing format... QSurfaceFormat::RenderableType(OpenGL) Found format: QSurfaceFormat(version 3.0, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) QSurfaceFormat::RenderableType(OpenGL) == end log == SESSION: 31 May 2019 20:35:49 -0700. Executing /usr/bin/krita WARNING: This file contains information about your system and the images you have been working with. If you have problems with Krita, the Krita developers might ask you to share this file with them. The information in this file is not shared automatically with the Krita developers in any way. You can disable logging to this file in Krita's Configure Krita Dialog. Please review the contents of this file before sharing this file with anyone. Krita Version: 4.2.0 Languages: en_US Hidpi: false Qt Version (compiled): 5.9.5 Version (loaded): 5.9.5 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 4.15.0-50-generic Pretty Productname: Ubuntu 18.04.2 LTS Product Type: ubuntu Product Version: 18.04 Hardware Information GPU Acceleration: auto Memory: 32131 Mb Number of Cores: 8 Swap Location: /tmp 31 May 2019 20:35:57 -0700: Closing. OpenGL Info Vendor: "NVIDIA Corporation" Renderer: "GeForce GTX 970/PCIe/SSE2" Version: "4.6.0 NVIDIA 390.116" Shading language: "4.60 NVIDIA" Requested format: QSurfaceFormat(version 3.0, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) Current format:QSurfaceFormat(version 4.6, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) Version: 4.6 Supports deprecated functions true is OpenGL ES: false QPA OpenGL Detection Info supportsDesktopGL: true supportsOpenGLES: true isQtPreferOpenGLES: false == log == Supported renderers: QFlags(0x2|0x4) Surface format preference list: * QSurfaceFormat(version 3.0, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferS
[krita] [Bug 408225] New: Canvas itself becomes transparent with transparent pixels, showing what is behind the Krita window
https://bugs.kde.org/show_bug.cgi?id=408225
Bug ID: 408225
Summary: Canvas itself becomes transparent with transparent
pixels, showing what is behind the Krita window
Product: krita
Version: 4.2.0
Platform: Kubuntu Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: OpenGL Canvas
Assignee: krita-bugs-n...@kde.org
Reporter: captains...@gmail.com
Target Milestone: ---
Created attachment 120509
--> https://bugs.kde.org/attachment.cgi?id=120509&action=edit
Screenshot showing issue; note the desktop visible through the transparent
orange areas
Any pixels that are transparent and show the canvas (that is, show the
checkerboard "transparent" pattern and would have an alpha of less than 1.0 if
ultimately exported) seem to be showing what's behind the Krita window itself.
That is, the desktop (or whatever else is there) becomes visible through the
transparent areas.
I stumbled across this when I noticed the antialiased edges of black Bezier
curve vectors didn't look black on-screen. When I zoomed in, I saw the default
Kubuntu wallpaper peeking out through the enlarged, transparent pixels. I
tried it with other transparencies, and sure enough, they all showed my desktop
behind the transparent areas.
Curiously, if there's no pixel data at all in a given region (or the pixels are
completely transparent), that area is NOT transparent to the desktop, and just
the plain checkerboard is visible.
If I turn off Canvas Graphics Acceleration in the settings, the problem goes
away, leading me to believe this is something to do with OpenGL.
STEPS TO REPRODUCE
1. Create a new image.
2. Draw a filled, opaque square by whatever means you wish.
3. Set the layer on which the square is to anything less than 100% Opacity.
OBSERVED RESULT
The desktop is visible through the transparent square and the transparency
checkerboard.
EXPECTED RESULT
Only the checkerboard should be visible through the transparent square; the
Krita canvas itself should not be transparent.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Kubuntu 18.04, running Linux 4.15.0-50-generic from Ubuntu
packages
(available in About System)
KDE Plasma Version: 5.12.7
KDE Frameworks Version: 5.47.0
Qt Version: 5.9.5
ADDITIONAL INFORMATION
This problem shows up on both my desktop and my laptop. The desktop has a
GeForce GTX 970, and the laptop has the mobile version of same. Both are
running the same version of Kubuntu with the same KDE Plasma, Frameworks,
Krita, and Qt versions.
In the attached screenshot, you can see a diagonal yellow line from the default
Kubuntu 18.04 wallpaper behind the transparent orange area ("Curtains Fore" in
the layer list, currently set to 34% opacity for demonstration), as well as the
icons for Inkscape and GKrellM in a folder widget on the desktop. Areas with
no pixel data just show the checkerboard.
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 366419] Group layer with gaussian blur filter mask gets divided into squares
https://bugs.kde.org/show_bug.cgi?id=366419 Nicholas Killewald changed: What|Removed |Added CC||captains...@gmail.com --- Comment #8 from Nicholas Killewald --- I just tested this on Krita 4.0.0. While the problem still exists when viewing the image in Krita itself, it seems like the artifacts don't show up when exporting to PNG anymore. I suppose this is probably related to why it takes so much longer to export in 4.0.0 (it looks as if it's fully re-rendering the entire image on export, which is good). So it might be mitigated as far as export is concerned, but not on the Krita canvas. -- You are receiving this mail because: You are watching all bug changes.
[wacomtablet] [Bug 347022] Unable to setup wacom tablet - widget missing
https://bugs.kde.org/show_bug.cgi?id=347022 Nicholas Killewald changed: What|Removed |Added CC||captains...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 337685] SFTP: Filesystem expose doesn't work
https://bugs.kde.org/show_bug.cgi?id=337685 --- Comment #20 from Nicholas Killewald --- Created attachment 105225 --> https://bugs.kde.org/attachment.cgi?id=105225&action=edit Patch to make KDE Connect ignore rmnet-related network interfaces on Android devices After further research, it looks like anything rmnet-related is safe to ignore, as that has to do with cellular communication and/or USB tethering. Since that seems to be causing Sergey's original problem (and my problem, and presumably others'), I made this quick patch that should take care of it. I hope I formatted the patch correctly. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 337685] SFTP: Filesystem expose doesn't work
https://bugs.kde.org/show_bug.cgi?id=337685 Nicholas Killewald changed: What|Removed |Added CC||captains...@gmail.com --- Comment #19 from Nicholas Killewald --- I'm getting the same issue with the KDE Connect app 1.6.1 and Android 7.1.2 (using a Pixel). It looks like what's happening is that Android is reporting the wrong IP address to the KDE side of things (in my case, the "v4-rmnet_data6" interface, which seems reasonably like "rmnet0" that Sergey noted in the initial description). Looking over the source of the Android app, I can see exactly where it happens: getLocalIpAddress() in SimpleSftpServer.java is going through all the available network interfaces until it finds the first non-local IPv4 address, or the last IPv6 address if it never finds an IPv4. On my phone, at least, v4-rmnet_data6 shows up in the list before a "real" address, so when SftpPlugin.java gets the message to start browsing (in onPackageReceived()), it sends out that IP address, meaning the KDE side tries to connect to it to no avail. This appears to be device-specific; on my Nexus 9 (Android 7.1.1), I don't get any rmnet-related interfaces or IP addresses, and the filesystem browser works perfectly there. It's only on my Pixel that I get this problem. That said, I'm not sure how you could definitively tell what the "real" interface is on the Android device to get the proper IP address, unless the KDE side instead defaults to using whatever address it just used to send the message to start browsing. -- You are receiving this mail because: You are watching all bug changes.
