[krita] [Bug 458764] Copy and pasting a selection twice in a row produces a blank layer.
https://bugs.kde.org/show_bug.cgi?id=458764 --- Comment #10 from Autumn Lansing --- Thanks for the workaround, Dmitry. :) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 458764] Copy and pasting a selection twice in a row produces a blank layer.
https://bugs.kde.org/show_bug.cgi?id=458764 --- Comment #5 from Autumn Lansing --- Created attachment 152128 --> https://bugs.kde.org/attachment.cgi?id=152128=edit Krita file used in video And here's the document from that video. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 458764] Copy and pasting a selection twice in a row produces a blank layer.
https://bugs.kde.org/show_bug.cgi?id=458764 --- Comment #4 from Autumn Lansing --- Created attachment 152127 --> https://bugs.kde.org/attachment.cgi?id=152127=edit Video of bug Here's a video of the bug in action. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 458764] Copy and pasting a selection twice in a row produces a blank layer.
https://bugs.kde.org/show_bug.cgi?id=458764 --- Comment #2 from Autumn Lansing --- It happens continuously for me. It also happens when I move the copied material. The selection box moves with the new layer and still surrounds the newly-copied material, but Ctrl C and Ctrl V to copy what's on Layer 2 produces a new blank Layer 3. 1. Select and area in Layer 1 2. Ctrl C to copy then Ctrl V to paste, which creates Layer 2 3. Move the newly-copied material on Layer 2 to a different position. The selection box will follow it. 4. Ctrl C and then Ctrl V to create Layer 3. Layer 3 will be blank. On the Layers docker, there is a visible difference in the shape of the layer icon for Layer 3. For example, in what I just did to test this, Layer 1 and Layer 2 icons are square, but the Layer 3 icon is a narrow, upright rectangle. Hovering over the icons, Layer 1 and Layer 2 show previews of what's on the layer, but Layer 3 shows a blank layer. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 458764] New: Copy and pasting a selection twice in a row produces a blank layer.
https://bugs.kde.org/show_bug.cgi?id=458764 Bug ID: 458764 Summary: Copy and pasting a selection twice in a row produces a blank layer. Product: krita Version: 5.1.0 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: * Unknown Assignee: krita-bugs-n...@kde.org Reporter: aut...@autumnlansing.com Target Milestone: --- SUMMARY Copy and pasting a selection twice in a row produces a blank layer. Copying a selected area works the first time, creating a new layer (Layer 2) with a copy of the selection from Layer 1. If you immediately copy and paste from Layer 2, however, it creates a new blank layer (Layer 3), despite the fact that Layer 2 still has an active selection box and one would expect the selection to be copied into Layer 3. If you create a new selection box around the material in Layer 2, it will copy correctly to Layer 3, but you can no longer do multiple copy and pastes from one original selection. You have to manually reselect the material again. This used to work correctly prior to 5.0. It may have worked correctly in 5.0 itself but I don't remember if I encountered the problem prior to 5.1 or not. STEPS TO REPRODUCE 1. Select an area in Layer 1 2. Ctrl C to copy then Ctrl V to paste, which creates Layer 2 3. Immediately Ctrl C and Ctrl V again to create Layer 3 OBSERVED RESULT Layer 3 is blank. EXPECTED RESULT Layer 3 should be a copy of Layer 2 SOFTWARE/OS VERSIONS Qt Version (compiled): 5.12.12 Version (loaded): 5.12.12 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 5.18.18-200.fc36.x86_64 Pretty Productname: Fedora Linux 36 (Cinnamon) Product Type: fedora Product Version: 36 Desktop: X-Cinnamon ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 436422] Concentric ellipse assistant tool fails to draw a perfect circle when using "snap to assistants"
https://bugs.kde.org/show_bug.cgi?id=436422 --- Comment #12 from Autumn Lansing --- I'm assuming that dpi and ppi are the same thing? The jump/delay doesn't happen at 1 ppi. To be honest, I don't consider that a tenable workaround, at least not for me at the scale I work. My usual page size is 2008 x 3071 pixels at 300 ppi. Testing out conversion back and forth between 300 and 1 ppi, I've yet to successfully finish. Each time I try, the "Updating" bar at the bottom never moves from 0%, even after ten minutes, and I've had to kill Krita each time because it becomes unresponsive. It's far less of a hassle to deal with the jump/delay than trying to convert existing documents and templates between the two ppis and hoping it works. Or perhaps I'm just not doing it right. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 436422] Concentric ellipse assistant tool fails to draw a perfect circle when using "snap to assistants"
https://bugs.kde.org/show_bug.cgi?id=436422 --- Comment #9 from Autumn Lansing --- Ahab, the bug can be very hard to see the larger the circle you make. Even I wouldn't notice it at the size you show in your image if I wasn't looking for it. Try zooming in and making a very tiny circle that's about one grid wide. It's very visible at that scale. Likewise, the related problem with straight lines is about 1/2 pixel in width. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 436422] Concentric ellipse assistant tool fails to draw a perfect circle when using "snap to assistants"
https://bugs.kde.org/show_bug.cgi?id=436422 --- Comment #8 from Autumn Lansing --- Created attachment 141019 --> https://bugs.kde.org/attachment.cgi?id=141019=edit Image of Krita assistant tool bug -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 434269] Krita freezes briefly after every completed brush stroke
https://bugs.kde.org/show_bug.cgi?id=434269 --- Comment #5 from Autumn Lansing --- Awesome! Thanks, Dmitry! I look forward to it. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 434269] Krita freezes briefly after every completed brush stroke
https://bugs.kde.org/show_bug.cgi?id=434269 --- Comment #3 from Autumn Lansing --- Thanks, Dmitry! I'd noticed that the problem didn't occur when I only had two or three documents open, so I've been using the workaround you suggested. I'm glad that the issue was something you could fix and not a problem on my end. It's a very frustrating bug. I look forward to the release of 5.0. Thanks for all your hard work! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 436422] Concentric ellipse assistant tool fails to draw a perfect circle when using "snap to assistants"
https://bugs.kde.org/show_bug.cgi?id=436422 --- Comment #5 from Autumn Lansing --- And I noticed today that this happens with ALL the assistant tools. It's just not as easily noticeable when making a straight line. There is a jump in each tool at the start, which results in a slightly darker line segment than the rest of the stroke. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 436422] Concentric ellipse assistant tool fails to draw a perfect circle when using "snap to assistants"
https://bugs.kde.org/show_bug.cgi?id=436422 --- Comment #4 from Autumn Lansing --- As it happens with a mouse and even with my tablet unplugged, it's probably not related to tablet settings. I've previously reported the so-far unaddressed bug 434269, which can sometimes cause freehand curves to jump and give a straight line, but in that case it only happens if I don't wait the three seconds or so for the freeze to happen before starting my stroke. If I wait until after the brief freeze, then I can draw a freehand curve without any problems. In this new bug, there is no freeze. It happens whenever I draw a circle /ellipse with the tool, regardless. It's mostly unnoticeable at large scale, but when drawing small circles, it's highly noticeable. The smaller the circle, the more noticeable it is. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 436422] Concentric ellipse assistant tool fails to draw a perfect circle when using "snap to assistants"
https://bugs.kde.org/show_bug.cgi?id=436422 --- Comment #2 from Autumn Lansing --- I use an Intuos 4. And it happens with both tablet and mouse. It also happens with each brush smoothing option. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 436422] New: Concentric ellipse assistant tool fails to draw a perfect circle when using "snap to assistants"
https://bugs.kde.org/show_bug.cgi?id=436422 Bug ID: 436422 Summary: Concentric ellipse assistant tool fails to draw a perfect circle when using "snap to assistants" Product: krita Version: 4.4.3 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Tool/Assistants Assignee: krita-bugs-n...@kde.org Reporter: aut...@autumnlansing.com Target Milestone: --- Created attachment 138036 --> https://bugs.kde.org/attachment.cgi?id=138036=edit Video showing bug with concentric ellipse tool SUMMARY The concentric ellipse assistant tool fails to draw a perfect circle when using "snap to assistants." When you begin the stroke, the pen travels a short distance before anything appears on the canvas, and when the stroke does appear it jumps from the point where you first put down the pen to the point where the pen currently sits, creating a straight line. Continuing the stroke happens in a perfect circle until you reach a point near the end of the circle, and then it again stops and makes another straight line jump to the point where the circle first began. The two straight line jumps are equal in length. STEPS TO REPRODUCE 1. Create a concentric ellipse with the assistant tool. 2. Draw a circle with "snap to assistants." OBSERVED RESULT The stroke jumps in a straight line at the beginning and at the end of the circle. EXPECTED RESULT A perfect circle without any straight lines. Krita Version: 4.4.3 Languages: en_US, en Hidpi: true Qt Version (compiled): 5.12.9 Version (loaded): 5.12.9 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 5.10.21-200.fc33.x86_64 Pretty Productname: Fedora 33 (Cinnamon) Product Type: fedora Product Version: 33 Desktop: X-Cinnamon OpenGL Info Vendor: "NVIDIA Corporation" Renderer: "GeForce GTX 660/PCIe/SSE2" Version: "4.6.0 NVIDIA 460.56" 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::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::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::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Version: 4.6 Supports deprecated functions true is OpenGL ES: false QPA OpenGL Detection Info supportsDesktopGL: true supportsOpenGLES: true isQtPreferOpenGLES: false Hardware Information GPU Acceleration: auto Memory: 24034 Mb Number of Cores: 4 Swap Location: /tmp Current Settings Current Swap Location: /tmp Current Swap Location writable: true Undo Enabled: true Undo Stack Limit: 30 Use OpenGL: true Use OpenGL Texture Buffer: true Use AMD Vectorization Workaround: false Canvas State: OPENGL_SUCCESS Autosave Interval: 900 Use Backup Files: true Number of Backups Kept: 1 Backup File Suffix: ~ Backup Location: Same Folder as the File Backup Location writable: false Use Win8 Pointer Input: false Use RightMiddleTabletButton Workaround: false Levels of Detail Enabled: false Use Zip64: false Display Information Number of screens: 2 Screen: 0 Name: DVI-D-0 Depth: 24 Scale: 1 Resolution in pixels: 1920x1080 Manufacturer: HP Inc. Model: HP VH240a- Refresh Rate: 60 Screen: 1 Name: DP-0 Depth: 24 Scale: 1 Resolution in pixels: 1920x1080 Manufacturer: LG Electronics Model: LG IPS FULLHD Refresh Rate: 60 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 434269] Krita freezes briefly after every completed brush stroke
https://bugs.kde.org/show_bug.cgi?id=434269 Autumn Lansing changed: What|Removed |Added Summary|Pen/mouse stutters after|Krita freezes briefly after |every completed brush |every completed brush |stroke |stroke -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 434269] Pen/mouse stutters after every completed brush stroke
https://bugs.kde.org/show_bug.cgi?id=434269 --- Comment #1 from Autumn Lansing --- As I worked in Krita today, I paid close attention to what was going on, and I now have a better idea of what's happening. It's not simply the pen or mouse stuttering, it's Krita itself freezing. After completing a pen stroke, not only does the pen and mouse stutter, but it affects everything in Krita: rotating the canvas, zooming in and out, adjusting sliders in a toolbox, etc. The program itself freezes briefly. There's another problem I've been having that I now believe is related to this as well. On occasion, after a pen stroke is completed, Krita freezes and remains frozen. The only way to unfreeze it is to save the file I'm working on. I'm changing the title of this bug to reflect the new information. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 434269] New: Pen/mouse stutters after every completed brush stroke
https://bugs.kde.org/show_bug.cgi?id=434269 Bug ID: 434269 Summary: Pen/mouse stutters after every completed brush stroke Product: krita Version: 4.4.3-beta1 Platform: Appimage OS: Linux Status: REPORTED Severity: major Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: aut...@autumnlansing.com Target Milestone: --- SUMMARY I originally added this problem onto Bug 421376, but after trying to diagnose it better I see differences in that bug to what I'm experiencing, so I'm creating a separate report. Krita stutters two or three seconds after I complete a pen or mouse stroke. If I start a new stroke right away, the stutter will happen while I'm drawing. If I move the cursor across the canvas without drawing, the cursor will stutter as it moves, and any brush stroke after that is normal. When I complete that brush stroke however, the stutter cycle begins all over again. See video: https://drive.google.com/file/d/11i-G1C847naJ7YajYXeq9ZuDN4SJ3b53/view?usp=sharing This is not a memory issue. It occurs when there's well over 10 GB of memory free. It occurs with both pen tablet and mouse. It doesn't matter if Instant Preview is on or off. It also ONLY occurs in Krita. It doesn't happen in GIMP or any other program. I'm experiencing this in the current beta, 4.4.3-beta1. It also occurred in 4.4.2. I recently upgraded my Nvidia card from a Quadro 600 to a GeForce GTX 660. I'm not sure if the issue was happening before that, but it's become painfully more noticeable in the past couple of weeks, perhaps because I'm doing more detail work in Krita at the moment. The GeForce card, however, is the same card I used in my previous machine, and there were no problems with it up through November of last year when I switched computers. I updated the Nvidia drivers today and the problem still happens. This stutter makes Krita rather annoying to work with. I've had to adjust my workflow to wait a few seconds after I complete a line before I start drawing another. STEPS TO REPRODUCE 1. Draw a line. 2. Move the cursor after completing the line. OBSERVED RESULT The cursor stutters after two or three seconds. EXPECTED RESULT No stutter SOFTWARE/OS VERSIONS Krita Version: 4.4.3-beta1 Languages: en_US, en Hidpi: true Qt Version (compiled): 5.12.9 Version (loaded): 5.12.9 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 5.10.21-200.fc33.x86_64 Pretty Productname: Fedora 33 (Cinnamon) Product Type: fedora Product Version: 33 Desktop: X-Cinnamon OpenGL Info Vendor: "NVIDIA Corporation" Renderer: "GeForce GTX 660/PCIe/SSE2" Version: "4.6.0 NVIDIA 460.56" 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::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::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::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Version: 4.6 Supports deprecated functions true is OpenGL ES: false QPA OpenGL Detection Info supportsDesktopGL: true supportsOpenGLES: true isQtPreferOpenGLES: false Hardware Information GPU Acceleration: auto Memory: 24034 Mb Number of Cores: 4 Swap Location: /tmp Current Settings Current Swap Location: /tmp Current Swap Location writable: true Undo Enabled: true Undo Stack Limit: 30 Use OpenGL: true Use OpenGL Texture Buffer: true Use AMD Vectorization Workaround: false Canvas State: OPENGL_SUCCESS Autosave Interval: 900 Use Backup Files: true Number of Backups Kept: 1 Backup File Suffix: ~ Backup Location: Same Folder as the File Backup Location writable: false Use Win8 Pointer Input: false Use RightMiddleTabletButton Workaround: false Levels of Detail Enabled: false Use Zip64: false Display Information Number of screens: 2 Screen: 0 Name: DVI-D-0 Depth: 24 Scale: 1 Resolution in pixels: 1920x1080 Manufacturer: HP Inc. Model: HP VH240a- Refresh Rate: 60 Screen: 1 Name: DP-0 Depth: 24 Scale: 1 Resolution in pixels: 1920x1080 Manufacturer: LG Electronics
[krita] [Bug 421376] Krita hiccups while painting every few seconds
https://bugs.kde.org/show_bug.cgi?id=421376 Autumn Lansing changed: What|Removed |Added CC||aut...@autumnlansing.com --- Comment #4 from Autumn Lansing --- The exact same issue is happening for me as well. It seemed to have begun only recently though, starting in at least 4.3.2 and continuing in 4.4.3-beta1. It may have been happening prior to this, however, and I just didn't notice at the time. It's highly noticeable now. It's not a memory issue, as it occurs when there's well over 10 GB of memory available. It also ONLY happens in Krita. It doesn't happen in GIMP. It happens with both mouse and table pen. It also happens with a newly-opened Krita window, not just a instance that's been open for a while. Though I'm not certain, I may have begun to notice it after I upgraded my Nvidia card from a Quadro 600 to a GeForce GTX 660. The GeForce card, however, is the same card used in my previous computer, and this problem never occurred with it there, so I don't think that has anything to do with it, but I thought I'd mention it in case it was relevant. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 430168] Brush presets change when switching windows or selecting tools in the toolbox docker
https://bugs.kde.org/show_bug.cgi?id=430168 --- Comment #4 from Autumn Lansing --- No worries. That's understandable. Let me add that today I discovered another event that triggers this bug: Plugging in my graphics tablet, an Intuos 4, while a brush with less than 100% opacity is selected, will also trigger the "edited" icon on the brush preset the first time the pen comes close enough to the tablet to be active. STEPS TO REPRODUCE 1. Select a brush with less than 100% opacity. 2. Plug in a graphics tablet. 3. Bring the pen into contact with the tablet. OBSERVED RESULT The "pencil" overlay appears on the selected brush, though the brush's settings don't appear to have been changed. EXPECTED RESULT The overlay shouldn't appear and the brush settings shouldn't change. I've also noticed other instances of this bug happening while working. I haven't yet figured out what triggers those events however. I also have two brushes that switch opacity at least once a day. My sketch pencil, at 75% opacity, and my eraser, at 100%, will sometimes trade opacities. I don't know what triggers that yet either. I'm assuming it's related to the other instances. I hope this extra information helps triage the bug when you're ready to tackle it. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 430168] Brush presets change when switching windows or selecting tools in the toolbox docker
https://bugs.kde.org/show_bug.cgi?id=430168 --- Comment #2 from Autumn Lansing --- Just updating to say this still happens in 4.4.2-beta2. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 430168] Brush presets change when switching windows or selecting tools in the toolbox docker
https://bugs.kde.org/show_bug.cgi?id=430168 --- Comment #1 from Autumn Lansing --- In relation to the first part of the bug, I'll also add that when a new window is manually opened in an active session, brushes with opacity less than 100% will have that opacity changed to 100% as well. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 430168] New: Brush presets change when switching windows or selecting tools in the toolbox docker
https://bugs.kde.org/show_bug.cgi?id=430168 Bug ID: 430168 Summary: Brush presets change when switching windows or selecting tools in the toolbox docker Product: krita Version: 4.4.2-beta1 Platform: Appimage OS: Linux Status: REPORTED Severity: major Priority: NOR Component: Dockers Assignee: krita-bugs-n...@kde.org Reporter: aut...@autumnlansing.com Target Milestone: --- I've been experiencing some maddening issues with brush presets. There are two slightly different problems. I'm not sure if they're related, but they have a lot in common, so I'm posting them as one bug. I use sessions, and I don't know if these problems occur when not using sessions. I'm also was not sure which component to select for the bug report. I chose Dockers, as this involves two of them. -- The first problem is related to opacity. An actively-selected brush with opacity less than 100% will be changed to 100% opacity in the following situations: a. Upon starting Krita, when using sessions, when the second window opens. The brush's opacity is fine when the first window opens, but once Krita starts to open the second, the opacity becomes 100%. STEPS TO REPRODUCE 1. Using sessions, open more than one window and select a brush with opacity. 2. Save the session and close it. 3. Reopen the session. OBSERVED RESULT The selected brush's opacity will change to 100% when the second window opens. EXPECTED RESULT The brush's opacity should be unchanged. --- b. When clicking on one of the icons in the toolbox docker, the opacity of the brush will change to 100%. This only happens once per icon though. After you reset the brush by clicking "reload brush preset," this does not happen for the same icon, but it will happen for another icon that hasn't previously been selected. This also happens per window. If you switch to another window, the bug starts all over again. STEPS TO REPRODUCE 1. Open Krita with a saved session. 2. Select a brush with opacity. Reload it to clear up the above issue if affected. 3. Click on one of the icons in the toolbox docker. OBSERVED RESULT The selected brush's opacity will change to 100%. EXPECTED RESULT The brush's opacity should be unchanged. -- The second part of this bug doesn't change opacity, however, the small "pencil" overlay in the Brush Presets docker that signifies when a brush has been changed from its original preset appears on the active brush when doing certain things, even though the brush settings seem not to have not been changed, at least not obviously. This happens when: a. Switching to another opened window (in sessions) for the first time. Once you click the "reload original preset" button, it doesn't happen again when selecting that same window. STEPS TO REPRODUCE 1. Using sessions, select a brush with opacity and clear up any issues with the first part of this bug, as above. 2. Switch to another open window. OBSERVED RESULT The "pencil" overlay appears on the selected brush, though the brush's settings don't appear to have been changed. EXPECTED RESULT The overlay shouldn't appear and the brush settings shouldn't change. --- b. When selecting one of the selection tools. Simply clicking on the icon in the toolbox docker or hitting the new keyboard shortcuts will cause this to happen repeatedly until you click one of the non-selection tool icons in the docker, for example the Assistant Tool. Using that example, the overlay appears on the brush preset the first time you click the Assistant Tool icon, and, after you reload the preset, will appear again when you click on one of the selection tools, but after that it does not appear again when clicking on any icons in the toolbox docker. STEPS TO REPRODUCE 1. Using sessions, reload the brush presets to clear up issues with the first part of this bug. 2. Click on one of the selection tools and then reload the brush's presets again to clear up issues with the second part of this bug. 3. Now, click on one of the selection tools again. OBSERVED RESULT The "pencil" overlay appears on the selected brush, though the brush's settings don't appear to have been changed. EXPECTED RESULT The overlay shouldn't appear and the brush settings shouldn't change. -- This behavior was occurring in 4.1 as well, but I didn't figure out what was causing it until just today. I hope my descriptions are clear. I spent an hour-and-a-half tracking down all the situations that cause it to happen. SOFTWARE/OS VERSIONS Krita Version: 4.4.2-beta1 Languages: en_US, en Hidpi: true Qt Version (compiled): 5.12.9 Version (loaded): 5.12.9 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 5.8.18-300.fc33.x86_64 Pretty Productname: Fedora 33 (Cinnamon) Product Type: fedora Product Version: 33
[krita] [Bug 427658] Weird interaction between Polygonal Selection Tool and Assistant Previews
https://bugs.kde.org/show_bug.cgi?id=427658 --- Comment #5 from Autumn Lansing --- Just updating to say that this still occurs in 4.4.2-beta1. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 427658] New: Weird interaction between Polygonal Selection Tool and Assistant Previews
https://bugs.kde.org/show_bug.cgi?id=427658 Bug ID: 427658 Summary: Weird interaction between Polygonal Selection Tool and Assistant Previews Product: krita Version: 4.4.0 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Tool/Assistants Assignee: krita-bugs-n...@kde.org Reporter: aut...@autumnlansing.com Target Milestone: --- SUMMARY Using the Polygonal Selection Tool while Assistant Previews are visible produces odd artifacts on screen wherever the tool's lines intersect with the preview lines. The preview lines are basically erased and redrawn elsewhere along the tool's line, multiple times if you stop the pointer and move it again. This happens on every side of the polygon until you complete the shape, and then all the artifacts vanish and everything is back to normal. This happens with mouse or tablet pen. I tried to get a screenshot of the problem but it didn't appear. The screenshot showed everything normally. Also, if I pull up another program window in front of Krita (alt-tab to something else) while the artifacts are present and then switch back again to Krita, the artifacts will be gone. This behavior is new to 4.4. STEPS TO REPRODUCE 1. Ensure that Assistant Previews are visible. 2. Create either a Concentric Ellipse or a Parallel Ruler, or both. 3. Use the polygon selection tool and create a selection across preview lines. OBSERVED RESULT Preview lines are disrupted and produce odd artifacts on screen. EXPECTED RESULT No interaction between preview lines and selection tool. SOFTWARE/OS VERSIONS Krita Version: 4.4.0 Languages: en_US, en Hidpi: true Qt Version (compiled): 5.12.9 Version (loaded): 5.12.9 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 5.7.15-100.fc31.x86_64 Pretty Productname: Fedora 31 (MATE-Compiz) Product Type: fedora Product Version: 31 Desktop: X-Cinnamon OpenGL Info Vendor: "NVIDIA Corporation" Renderer: "GeForce GTX 660/PCIe/SSE2" Version: "4.6.0 NVIDIA 450.66" 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::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::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::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Version: 4.6 Supports deprecated functions true is OpenGL ES: false QPA OpenGL Detection Info supportsDesktopGL: true supportsOpenGLES: true isQtPreferOpenGLES: false Hardware Information GPU Acceleration: auto Memory: 16001 Mb Number of Cores: 6 Swap Location: /tmp Current Settings Current Swap Location: /tmp Current Swap Location writable: true Undo Enabled: true Undo Stack Limit: 30 Use OpenGL: true Use OpenGL Texture Buffer: true Use AMD Vectorization Workaround: false Canvas State: OPENGL_SUCCESS Autosave Interval: 300 Use Backup Files: true Number of Backups Kept: 1 Backup File Suffix: ~ Backup Location: Same Folder as the File Backup Location writable: false Use Win8 Pointer Input: false Use RightMiddleTabletButton Workaround: false Levels of Detail Enabled: false Use Zip64: false Display Information Number of screens: 2 Screen: 0 Name: HDMI-0 Depth: 24 Scale: 1 Resolution in pixels: 1920x1080 Manufacturer: LG Electronics Model: LG IPS FULLHD Refresh Rate: 60 Screen: 1 Name: DVI-D-0 Depth: 24 Scale: 1 Resolution in pixels: 1920x1080 Manufacturer: HPN Model: HP VH240a- Refresh Rate: 60 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 409479] Canvas freezes after using move tool.
https://bugs.kde.org/show_bug.cgi?id=409479 --- Comment #2 from Autumn Lansing --- And, oddly, it's stopped happening. It had been happening to me several times a day with 4.2.0 through 4.2.2, but it hasn't occurred once in the last two weeks using 4.2.2 and 4.2.3. Nothing has changed on my setup, so I'm unsure what may have been causing it. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 409479] New: Canvas freezes after using move tool.
https://bugs.kde.org/show_bug.cgi?id=409479 Bug ID: 409479 Summary: Canvas freezes after using move tool. Product: krita Version: 4.2.2 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Tools/Move Assignee: krita-bugs-n...@kde.org Reporter: aut...@autumnlansing.com Target Milestone: --- Created attachment 121315 --> https://bugs.kde.org/attachment.cgi?id=121315=edit System information SUMMARY I'm experiencing frequent issues that occur after using the move tool. It's very random. It doesn't happen every time I move a selection, and there doesn't seem to be any pattern to what causes it. After making a selection and then moving it, Krita sometimes pops up the "Waiting for image operation to complete" dialog box. The operation never completes however. I've waited as long as five minutes. The size of the selection to move doesn't seem to matter. I can cancel the dialog box, sometimes on the first try, though sometimes it takes multiple clicks. About half the time I can then resume using Krita as normal, but the other half of the time the canvas becomes unresponsive. I can click on the menus, even change the window, but I can't do anything on the canvas itself with either the tablet pen or the mouse. Hiding/unhiding layers doesn't work either. I have to restart Krita at that point. I can usually save my work before I do. In anticipation of some questions that may be asked: * I had to create a fresh configuration when I started using Krita 4.2, as my old configuration was causing problems with my pen. * Instant Preview is off. STEPS TO REPRODUCE 1. Load a drawing and start randomly moving things around the page. 2. If the "Waiting for image operation to complete" dialog box shows, cancel it 3. Try drawing on the canvas or moving around the canvas. OBSERVED RESULT The canvas is frozen. EXPECTED RESULT The canvas should not be frozen. SOFTWARE/OS VERSIONS Attached as a file as it's quite long. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 408086] Can't change layer visibility, lock/unlock, etc. with tablet pen
https://bugs.kde.org/show_bug.cgi?id=408086 Autumn Lansing changed: What|Removed |Added Status|NEEDSINFO |RESOLVED --- Comment #3 from Autumn Lansing --- I figured out what was happening. I start the Krita appimage from a script (so I can have a menu entry in my DE) and at one point in the past I had to export the environmental variable QT_XCB_NO_XI2_MOUSE=1 as part of that script in order to get Krita to work correctly. Commenting out that export solved the problem. I imagine it's related to your updated QT version. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 408086] Can't change layer visibility, lock/unlock, etc. with tablet pen
https://bugs.kde.org/show_bug.cgi?id=408086 Autumn Lansing changed: What|Removed |Added Version|4.2.0 |4.2.1 --- Comment #1 from Autumn Lansing --- This bug still occurs in 4.2.1 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 408086] New: Can't change layer visibility, lock/unlock, etc. with tablet pen
https://bugs.kde.org/show_bug.cgi?id=408086 Bug ID: 408086 Summary: Can't change layer visibility, lock/unlock, etc. with tablet pen Product: krita Version: 4.2.0 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Layer Stack Assignee: krita-bugs-n...@kde.org Reporter: aut...@autumnlansing.com Target Milestone: --- SUMMARY I just tried the newly-released 4.2.0 and discovered that I can no longer change the visibilty of layers, or lock/unlock them, etc. using my tablet pen. I'm an Intuos4 user. When touching the pen to the icons, they quickly blink off and then back on again. Holding the pen on the icons for several seconds does not have any different effect. The mouse works normally. STEPS TO REPRODUCE 1. Using an Intuos4 pen, tap the layer visibilty icon. OBSERVED RESULT Icon blinks off and then on again. Layer does not change visibility. EXPECTED RESULT Layer should change visibility and icon should reflect that. I've had to go back to 4.1.7 until this is fixed, as I'm constantly fiddling with layers, and it's too disruptive to switch back and forth between pen and mouse. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 399419] Show Painting Assistants toggle is inconsistent between windows
https://bugs.kde.org/show_bug.cgi?id=399419 --- Comment #5 from Autumn Lansing --- Thanks. :) It's currently a work in progress. I played around with it more today in various scenarios, and the bug happens every single time in the exact way that I described. I'm unsure what might be different in my setup that would cause it. It's not a critical bug, though, by any means. It's just an annoyance. I'll add to the report if I discover any new facts or if it stops happening in a new version. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 399419] Show Painting Assistants toggle is inconsistent between windows
https://bugs.kde.org/show_bug.cgi?id=399419 --- Comment #3 from Autumn Lansing --- Created attachment 115523 --> https://bugs.kde.org/attachment.cgi?id=115523=edit Image of painting assistant bug Here's an image of the bug. You'll notice that the assistants are visible even though the view option is toggled off. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 399419] New: Show Painting Assistants toggle is inconsistent between windows
https://bugs.kde.org/show_bug.cgi?id=399419 Bug ID: 399419 Summary: Show Painting Assistants toggle is inconsistent between windows Product: krita Version: 4.1.3 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Tool/Assistants Assignee: krita-bugs-n...@kde.org Reporter: aut...@autumnlansing.com Target Milestone: --- When working with multiple windows, toggling the "View > Show Painting Assistants" option becomes confused as to which state each window is in and show inconsistencies. Toggling off the option on one window to hide the assistants (unchecking the menu option) and then switching to another window where the assistants are not hidden resets the toggle's checkmark in the menu to a global checked state. Switching back to the first window, where the assistants have been hidden, displays the checkmark in the menu next to the option though the assistants themselves are still hidden. Unchecking the option in that state, which one assumes would hide the assistants, shows the assistants instead. The checkmark in the menu ends up being very confusing as you can't rely on its state to tell if the option is off or on. If it makes a difference, I heavily use sessions. STEPS TO REPRODUCE 1. Create several windows with painting assistants in each. 2. Toggle off assistants in one window 3. Switch to a second window with assistants not hidden 4. Switch back to the first window with the hidden assistants. 3. Observe the state of the toggle checkmark versus the visible state of the assistants. OBSERVED RESULT The toggle checkmark does not consistently match the visibility state. EXPECTED RESULT The checkmark should be consistent for each window, showing when the assistants are visible in the window and not showing when they're hidden. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 396512] Brush tags with spaces or underscores show no icons in Brush Presets docker upon restart
https://bugs.kde.org/show_bug.cgi?id=396512 --- Comment #2 from Autumn Lansing --- It's still happening to me on 4.1.1. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 396512] New: Brush tags with spaces or underscores show no icons in Brush Presets docker upon restart
https://bugs.kde.org/show_bug.cgi?id=396512 Bug ID: 396512 Summary: Brush tags with spaces or underscores show no icons in Brush Presets docker upon restart Product: krita Version: 4.1.0 Platform: Appimage OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: aut...@autumnlansing.com Target Milestone: --- If the name of a brush tag group has a space or underscore in it, e.g. "comic ink" or "comic_ink", and that tag group is selected in the brush presets docker when Krita is closed, upon restart no icons or details show in the docker. The docker will be blank. Switching to another tag group and back again is required to get the brush icons to show. This behavior started when the new brush engine was introduced. The old engine didn't have this issue. Steps to reproduce: 1. Assign a brush to a new tag group with a space or underscore in its name. 2. Select that brush group in the brush presets docker. 3. Quit Krita. 4. Restart Krita. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392235] Cannot re-enable locked but hidden dockers
https://bugs.kde.org/show_bug.cgi?id=392235 --- Comment #2 from Autumn Lansing <aut...@autumnlansing.com> --- Ah, yes. I was able to unlock it through another workspace and realized that the official release had started me in a different workspace than I normally use. There was no visual information to make me think that though, and the beta version had not done it, hence my confusion. Yes, an emergency unlocking mechanism might be helpful. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392231] Inability to scale text borders - half implemented?
https://bugs.kde.org/show_bug.cgi?id=392231 Autumn Lansing <aut...@autumnlansing.com> changed: What|Removed |Added CC||aut...@autumnlansing.com Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #1 from Autumn Lansing <aut...@autumnlansing.com> --- This is my experience as well. I don't know if you've not added that functionality yet or if it's a bug, but I'm confirming if it's a bug. This may be related to bug 391796. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392235] New: Palette Docker missing
https://bugs.kde.org/show_bug.cgi?id=392235 Bug ID: 392235 Summary: Palette Docker missing Product: krita Version: 4.0 Platform: Appimage OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Dockers Assignee: krita-bugs-n...@kde.org Reporter: aut...@autumnlansing.com Target Milestone: --- With 4.0.0. the Palette docker is missing. It shows up in the menu under Settings > Dockers, but it's unchecked and grayed out so that I can't check it again. Several other entries are actually grayed out as well: the Advanced Color Selector, Layers, and Brush Presets, but they're checked and show up in the dock thankfully. I can bring up the Python Palette Docker to use so I'm not without a palette, but it's a bit annoying as it seems to randomly select a different palette each time I start Krita. I'm using the Appimage in Fedora 27. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 385030] Adding "toggle assistant" to the toolbar results in crash
https://bugs.kde.org/show_bug.cgi?id=385030 Autumn Lansing <aut...@autumnlansing.com> changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #16 from Autumn Lansing <aut...@autumnlansing.com> --- With the official 4.0.0 release, Krita no longer crashes when adding the Toggle Assistant to the toolbar. The Toggle Assistant still disappears between sessions, but as you said, that would take a big redesign to fix and it isn't a major issue. My reported bug, though, has been resolved. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 389574] New: The Assistant Tool control box becomes unresponsive after rotating image
https://bugs.kde.org/show_bug.cgi?id=389574 Bug ID: 389574 Summary: The Assistant Tool control box becomes unresponsive after rotating image Product: krita Version: 4.0.0-beta.1 Platform: Appimage OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: Tool/Assistants Assignee: krita-bugs-n...@kde.org Reporter: aut...@autumnlansing.com Target Milestone: --- When you use the Assistant Tool, then use a brush to draw without it being snapped to the assistant, then rotate the canvas with 4 or 6, the control box for the drawing assistant becomes non-responsive. The box is visible on the screen, but if you try to use any of the controls to either move it, hide it or delete it, none of those actions happen. Instead it starts a new assistant. Steps to reproduce: 1. Open a new or old file. 2. Select the Assistant Tool and make a new ruler on the page. 4. Select the Freehand Brush Tool. 3. Unselect "Snap to Assistant." 4. Draw a stroke on the page. 5. Hit the 4 or 6 shortcut to rotate the canvas. 6. Select the Assistant Tool again and try to move or close the ruler you created in step 2. This only happens when the brush isn't snapped to the assistant. You can draw, rotate the page and move the tool all you want if you're snapped to it. The first time you unsnap and draw, however, then the next rotation will cause the glitch. The only way to remedy the problem is to close the file and reopen it. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 385030] Adding "toggle assistant" to the toolbar results in crash
https://bugs.kde.org/show_bug.cgi?id=385030 --- Comment #15 from Autumn Lansing <aut...@autumnlansing.com> --- All the command line tells me is: "/home/autumn/bin/krita: line 4: 7550 Segmentation fault (core dumped) /home/autumn/bin/krita/krita-4.0.0-beta1.1-x86_64.appimage" I've included a core dump as provided by Fedora's automated problem reporting system, if that will be helpful. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 385030] Adding "toggle assistant" to the toolbar results in crash
https://bugs.kde.org/show_bug.cgi?id=385030 --- Comment #14 from Autumn Lansing <aut...@autumnlansing.com> --- Created attachment 109976 --> https://bugs.kde.org/attachment.cgi?id=109976=edit krita crash core dump -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 385030] Adding "toggle assistant" to the toolbar results in crash
https://bugs.kde.org/show_bug.cgi?id=385030 --- Comment #11 from Autumn Lansing <aut...@autumnlansing.com> --- It's still crashing for me. It's the exact same behavior in 4.0.0-beta1.1 as it was in my original report. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 385030] Adding "toggle assistant" to the toolbar results in crash
https://bugs.kde.org/show_bug.cgi?id=385030 --- Comment #9 from Autumn Lansing <aut...@autumnlansing.com> --- I see why it used to disappear then. But even though it would disappear from the toolbar, it would still show as a current action in the Configure Toolbars dialog next time you started Krita. You'd have to move it back to available actions and add it again each time. Not a huge problem. Just a minor annoyance. I'm still getting crashes on adding it though with the final release version of 3.3.0. Adding other toolbar options causes a crash as well, but when I restart Krita, those options are present on the toolbar. Toggle Assistant never shows at all. It also crashes for me when I remove the items I added from the toolbar. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 385030] New: Adding "toggle assistant" to the toolbar results in crash
https://bugs.kde.org/show_bug.cgi?id=385030 Bug ID: 385030 Summary: Adding "toggle assistant" to the toolbar results in crash Product: krita Version: 3.3.0-rc.1 Platform: Appimage OS: Linux Status: UNCONFIRMED Severity: crash Priority: NOR Component: general Assignee: krita-bugs-n...@kde.org Reporter: aut...@autumnlansing.com Target Milestone: --- Krita 3.3.0-rc.1 crashes when I try to add "toggle assistant" to the toolbar. After restarting Krita, "toggle assistant" is gone from the "Configure Toolbars>Available actions" menu but not present in "Current actions". After another restart, it appears in "Current actions," but it doesn't show on the toolbar. Removing it from "Current actions" and then adding it again results in another crash. I'll note that, in previous Krita versions, "toggle assistant" was one of the buttons that disappeared from the toolbar after every restart, as referenced in bug #365222. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 368573] Tablet Pen stops responding for a short period of time after each stroke
https://bugs.kde.org/show_bug.cgi?id=368573 --- Comment #4 from Autumn Lansing <aut...@autumnlansing.com> --- Yes, but the problem only came about with 3.0.1. 3.0 works perfectly. Something changed in Krita that's causing the skipping. The tablet and pen work fine in all other apps I've tested them in, such as GIMP. It's only in Krita 3.0.1 that there's a problem, so something in the way that Krita handles events in its latest version is creating the issue. Aside from breaking the lock when moving the pen to the other monitor, the lock is also broken if another app is brought into focus on the same monitor, so as long as Krita is in focus, it keeps the pen locked up for around five seconds before releasing it. What changed in Krita's handling of pen events between versions that might cause this? If I file this with the Awesome team, they may not have the equipment to test it. If the problem is on their end, then I need to be able to point them in the right direction. As it is, Krita seems to be doing something different from all other apps, and I fear they may kick the bug back to you. I'm a developer, though not very experienced with C++, which I assume Krita is written in, but I'd be happy to look into the bug further if I knew where to start. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 368573] Tablet Pen stops responding for a short period of time after each stroke
https://bugs.kde.org/show_bug.cgi?id=368573 --- Comment #2 from Autumn Lansing <aut...@autumnlansing.com> --- I use Awesome Window Manager. I tested in Cinnamon, and it works fine in that DE, but not in Awesome. Something new I noticed as well: I have a multi-monitor setup, and if I swipe the pen to the other monitor and then back to Krita again, I can make a new stroke. That seems to break whatever is locking up the pen. It locks up again after making that new stroke though. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 368573] New: Tablet Pen stops responding for a short period of time after each stroke
https://bugs.kde.org/show_bug.cgi?id=368573 Bug ID: 368573 Summary: Tablet Pen stops responding for a short period of time after each stroke Product: krita Version: 3.0.1 Platform: Appimage OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: tablet support Assignee: krita-bugs-n...@kde.org Reporter: aut...@autumnlansing.com I have an Intuos 4 tablet. With the latest 3.0.1 version of Krita, the pen stops drawing after making a stroke. The pen still moves on screen, but it doesn't lay down paint and the brush outline is gone. I'm also unable to move the drawing around by holding down the pen's buttons during this time. After a few seconds, the pen starts responding normally again until after making another stroke, when it stops again. The size of the brush outline also changes while making strokes. It becomes very small when first starting the stroke then grows to a larger size as the stroke continues. It doesn't seem to affect the stroke width on the canvas however, as far as I've seen. The pen and tablet work fine in 3.0. The problem is only in 3.0.1. I tested with a new rc file just to check if my settings might be to blame and that made no difference. I'm unsure how to debug this, so please let me know what I can do to help. Reproducible: Always Steps to Reproduce: 1. Make a stroke with the pen, then lift up the pen from the tablet 2. Start a new stroke. The stroke doesn't appear on the canvas, and the brush's outline doesn't show on screen. 3. Wait a few seconds and try again. It works. Repeat steps. -- You are receiving this mail because: You are watching all bug changes.
