Feature request for dedicated Eraser Tool

Develop Feature Requests
, ,
349

To be honest, I think Ten Brushes is quite an outdated thing and we should gradually move toward a paradiam similar to Shortcut Composer.

It works similar to how CSP manages brushes, but better because it also provides pie menus to switch between brushes among the same ‘slot’ quickly. It also co-exists with the built-in eraser mode toggle, so you can still erase a rectangle/line/polygon etc.

UI-wise, I think once one installs Shortcut Composer and Docker Under Cursor, Krita has no drawbacks compared to PS/CSP for digital painting. (Performance-wise it’s another story)

4 Likes
350

I know I’m sounding like a broken record here, but I’d like to mention one more reason to justify the CSP/Shortcut Composer paradigm.

Krita 5.3’s way is basically having two categories: brushes and erasers. You can set separate hotkey for each. That’s an improvement over 5.2, but I’d argue that’s a misguided effort. Why? Because (brushes, erasers) isn’t the only logical way to categorize brushes.

There are many possible categorizations:

  • (hard edge brushes, airbrushes)
  • (inking brushes, painterly brushes)
  • (paint brushes, smudge brushes, brushes that paint and smudge at the same time)

etc.

Different artists have different workflows and might need to switch between brushes in different ways. CSP’s way is much more flexible to accommodate all of them.

And moreover, if you think about it, it already kinda is how Krita’s brush management works: Krita allows you to assign arbitrary tags to a brush, addressing that different artists have different ways to organize their brushes. We just need to be able to associate hotkeys to tags.

4 Likes
351

Absolutely. Here’s your original post with the technical proposal smoothly integrated into the latter part. I preserved your tone and flow while transitioning naturally into the architecture suggestion.

Would you believe this? I was coming from Photoshop from years of using it. When I first used Krita, it’s exactly its own implementation of the eraser function that sold me to Krita!

Simply hitting the “E” key on my keyboard if I want to use my active brush (with all its current settings) as an eraser? What couldn’t be more simple and intuitive!

I agree with those saying that a separate eraser tool is hugely redundant for Krita’s case and its UX philosophy on how an eraser tool should be implemented: mode-based rather than tool-based. This is what technology does to artistic workflow paradigms. Whereas erasers are traditionally separate tools, it appears that they don’t have to be in the digital space. You can do modes in the digital space and toggle the behavior or state of any active tool in real-time! It’s beautiful!

There are also many, many instances in Photoshop wherein I would like to use my active brush as an eraser, quickly toggling in and out of it, but I simply couldn’t do it! I found out that some brushes, for some very weird reason, just weren’t built to work as erasers — and for what reason? It never made sense to me. It comes across as an artificial limitation if not unnecessarily convoluted.

Where a separate eraser tool would work is if you’d like the eraser to have separate characteristics than that of your active brush (which is the case for the majority of the time). Krita already appears to have dedicated brushes that behave as erasers by default, regardless if the eraser mode is toggled or not.

I would suggest that the current mode-based eraser implementation should stay (I think this is how Procreate currently implements it, not just with the eraser mode but with their smudge mode as well), but alongside it, visually separating dedicated eraser brushes for easy access and flexibility.

Or — better yet — the plugin that the Blender Institute had already developed could work perfectly for this with the following improvements:

Suggested Brush Preset Architecture + Mode-Based Recall System

To support an efficient, flexible, and intuitive brush system, I suggest separating the brush shape (visual form) from the brush preset (behavioral configuration), and adding a lightweight mode-aware hotkey recall feature.

1. Brush Shape & Preset Model

BrushShape (shared, immutable):
Represents the visual geometry or texture of the brush.

class BrushShape {
  id: string;
  geometryData: any; // bitmap, path, procedural parameters, etc.
}

BrushPreset (user-configurable):
A saved brush configuration that references a shape and defines behavior.

class BrushPreset {
  id: string;
  shape: BrushShape;
  mode: 'paint' | 'erase' | 'smudge';
  opacity: number;
  pressureResponse: PressureCurve;
  color: Color | null; // null for erasers
}

This approach allows users to reuse a single shape (like a round or spatter brush) across multiple presets with different behaviors and settings.

2. Hotkey-Based Mode Recall

Each mode can be mapped to a recallable hotkey:

Hotkey Mode Recalled
P Last-used Paint brush
S Last-used Smudge brush
E Last-used Erase brush

Each time a user activates a brush preset, it updates a simple in-memory registry of the most recent preset used per mode:

interface LastUsedBrushRegistry {
  paint: BrushPreset | null;
  smudge: BrushPreset | null;
  erase: BrushPreset | null;
}

function activateBrush(preset: BrushPreset) {
  currentBrush = preset;
  lastUsedBrushes[preset.mode] = preset;
}

function onHotkeyPress(mode: Mode) {
  const last = lastUsedBrushes[mode];
  if (last) activateBrush(last);
}

User-Controlled Saving

  • Presets must be explicitly saved by the user (e.g., through a “Save Brush” button).
  • Hotkey-recalled brushes are session-volatile unless saved.

Why This Helps

  • Preserves Krita’s powerful mode-based design while giving users quick recall of specialized tools.
  • Clean separation of shape vs. behavior means less duplication and more control.
  • User control over saving avoids bloated brush lists and ensures intentionality.

(Full disclosure: I used ChatGPT to help me articulate the more technical parts!)

3 Likes