[krita] [Bug 370196] New: Allow Selection (marching ants) boundaries to be hidden
https://bugs.kde.org/show_bug.cgi?id=370196 Bug ID: 370196 Summary: Allow Selection (marching ants) boundaries to be hidden Product: krita Version: 3.0.1 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: usability Assignee: krita-bugs-n...@kde.org Reporter: phoenix.en...@gmail.com I find the marching ants distracting when working on a document. For example: isolating an clearly-defined area so that the rest isn't affected by brush strokes. I find that having the marching ants around screws with my value and color perception. A workaround is to make a completely-transparent mask selection. However, this seems more like a hack and it's better to have a completely separate option for toggling selection display. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 370026] Pop-up Palette shows Favorite Presets instead of last-used tag
https://bugs.kde.org/show_bug.cgi?id=370026 --- Comment #1 from Phoenix Enero --- Sorry, the Actual Results and Expected Results should be the other way around (I keep getting confused...) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 370026] New: Pop-up Palette shows Favorite Presets instead of last-used tag
https://bugs.kde.org/show_bug.cgi?id=370026 Bug ID: 370026 Summary: Pop-up Palette shows Favorite Presets instead of last-used tag Product: krita Version: 3.0.1 Platform: Windows CE OS: other Status: UNCONFIRMED Severity: normal Priority: NOR Component: usability Assignee: krita-bugs-n...@kde.org Reporter: phoenix.en...@gmail.com This is something that happens rarely. I haven't yet found the actual cause but I will keep this thread updated. Reproducible: Sometimes Steps to Reproduce: 1. Run Krita 2. Open any document 3. Open the Pop-up Palette/"Circle Menu" (i.e. with right-click) Actual Results: Pop-up Palette shows the brushes from the last-used tag Expected Results: Pop-up Palette shows the Favorite Presets -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 342105] [HUION] Cannot right click with the Pen of Huion H610 Pro
https://bugs.kde.org/show_bug.cgi?id=342105 --- Comment #47 from Phoenix Enero --- I just noticed something: Stylus buttons work perfectly okay inside the Brushes panel test canvas (the panel where you create/modify brushes.) Right-click selects a color, middle-click drags the test canvas. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 369475] Resizing the Krita window hangs for about 10-20 seconds after a long period of not resizing the window
https://bugs.kde.org/show_bug.cgi?id=369475 --- Comment #2 from Phoenix Enero --- I resize the window every now and then. The gaps between every time I resize is usually longer than 30 minutes. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 369600] New: Brush scaling mode should be proportional to zoom mode
https://bugs.kde.org/show_bug.cgi?id=369600 Bug ID: 369600 Summary: Brush scaling mode should be proportional to zoom mode Product: krita Version: 3.0.1 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: usability Assignee: krita-bugs-n...@kde.org Reporter: phoenix.en...@gmail.com Having to Shift-drag over long distances just to change brush sizes in low zoom can be very annoying when working with large files. I propose that brush scaling should be proportional to current zoom, so that shift-dragging has consistent brush scaling over different zoom levels. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 369475] New: Resizing the Krita window hangs for about 10-20 seconds after a long period of not resizing the window
https://bugs.kde.org/show_bug.cgi?id=369475 Bug ID: 369475 Summary: Resizing the Krita window hangs for about 10-20 seconds after a long period of not resizing the window Product: krita Version: 3.0.1 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: crash Priority: NOR Component: general Assignee: krita-bugs-n...@kde.org Reporter: phoenix.en...@gmail.com After working on a document for a long time I resized the Krita window. It ended up hanging for about 10-20 seconds. This also happens without doing anything on a document, just leaving it open for a long duration. I suspect some memory is being swapped though I don't know enough about the internals of Krita to say definitively. Reproducible: Always Steps to Reproduce: 1. Open any document in a new Krita window. 2. Do anything (or nothing) inside Krita **except** resizing the window for about 30 minutes or more. 3. Resize the window Actual Results: The window hangs (Not Responding) for about 10-20 seconds Expected Results: The window resizes normally. This bug also appears in Krita 3.0.0. I have not tested for the bug in an empty (no working documents) window yet. Operating System is Windows 7 x64. My computer has no SSDs (solid-state drives), only hard drives. It has 8 GB memory and i7-3930k Sandy Bridge CPU. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 369306] Unfocusing the window then drawing at the canvas yields no pressure detection or smoothing at the initial stroke.
https://bugs.kde.org/show_bug.cgi?id=369306 --- Comment #2 from Phoenix Enero --- @wolthera I said nothing about window unfocusing mid-stroke. My workflow involves Krita occupying one-half (or more) of my screen, with the rest containing a browser showing my reference photos, I move a lot between the programs so it's slightly annoying that after focusing on the browser then drawing on the (Krita) canvas it yields a non-pressure detected stroke. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 369306] New: Unfocusing the window then drawing at the canvas yields no pressure detection or smoothing at the initial stroke.
https://bugs.kde.org/show_bug.cgi?id=369306 Bug ID: 369306 Summary: Unfocusing the window then drawing at the canvas yields no pressure detection or smoothing at the initial stroke. Product: krita Version: 3.0 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: usability Assignee: krita-bugs-n...@kde.org Reporter: phoenix.en...@gmail.com Trying to draw after putting the window out of focus yields no pressure detection or smoothing at the initial brush stroke. Subsequent brush strokes work normally. Reproducible: Always Steps to Reproduce: 1. Open any document or create a new one. 2. Place the Krita window out of focus. You can do this by clicking anywhere outside the Krita window. 3. Draw a brush stroke in the Krita canvas. Actual Results: Brush stroke looks ragged with no pressure detection at all. Expected Results: Brush stroke has pressure detection and is stabilized (this may vary between different brushes.) Tablet I'm using is HUION H610 Pro. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 369305] Color picking alternate invocation gets stuck when un-focusing the Krita window
https://bugs.kde.org/show_bug.cgi?id=369305 --- Comment #1 from Phoenix Enero --- Forgot to add: The tablet I'm using is HUION H610 Pro. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 369305] New: Color picking alternate invocation gets stuck when un-focusing the Krita window
https://bugs.kde.org/show_bug.cgi?id=369305 Bug ID: 369305 Summary: Color picking alternate invocation gets stuck when un-focusing the Krita window Product: krita Version: 3.0 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: usability Assignee: krita-bugs-n...@kde.org Reporter: phoenix.en...@gmail.com Activating any of the color picking alternate invocation (such as when holding the Control Key) then placing the Krita window out of focus keeps the activated invocation stuck. Reproducible: Always Steps to Reproduce: Set Canvas Input Settings → Alternative Invocation to default. Keep the Krita program windowed (for convenience as you'll see later.) 1. Open any document or create a new one. 2. Place your cursor in the Krita canvas area. 3. Hold the control key. You should see a Foreground Color PIck. 4. While holding the control key, un-focus the Krita window by clicking anywhere that isn't the Krita window. 5. Release the control key. 6. Move the cursor back to the Krita canvas. Actual Results: The Foreground Color PIck mode is still activated. Clicking the canvas will pick the color instead of placing a brush stroke. Expected Results: The Foreground Color Pick mode is not activated. Clicking the canvas would place a brush stroke instead of picking the color. Similar behavior is shown with the other Color Pick alternate invocations: Foreground Color Pick from Current Layer, Background Color Pick from Current Layer, Background Color Pick from Merged Layers. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 368360] Krita does not remember shortcut save location.
https://bugs.kde.org/show_bug.cgi?id=368360 Phoenix Enero changed: What|Removed |Added CC||phoenix.en...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 342105] [HUION] Cannot right click with the Pen of Huion H610 Pro
https://bugs.kde.org/show_bug.cgi?id=342105 --- Comment #45 from Phoenix Enero --- I'm sorry, non-HUION users not non-Wacom users. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 342105] [HUION] Cannot right click with the Pen of Huion H610 Pro
https://bugs.kde.org/show_bug.cgi?id=342105 Phoenix Enero changed: What|Removed |Added CC||phoenix.en...@gmail.com --- Comment #44 from Phoenix Enero --- Disclaimer: I have no idea about the technical side of this program. Could the hack be turned on with a setting (i.e. "Workaround tablets not supporting specification WTxxx" or whatever) so users without the problem can use the program normally without performance decrease? Or is the abstraction so deep that something like that would only _increase_ the performance drop? And is the performance drop really that high? If it's just one layer of abstraction can the performance drop be accepted by non-Wacom users? Having software that works is slightly more important that having software run fast. I'll also note that Photoshop and Manga Studio EX 5.0 seem to have no problems with stylus buttons. Tablet used: HUION H610 Pro. -- You are receiving this mail because: You are watching all bug changes.
