"Brush names" vs "roles"

Feature Requests
1

Summary: Store a ‘user’ name for each brush, as well as its actual name on disk, so that users can identify brushes by how they use them rather than the name their creator decided on.

As I use MyPaint, I’ve observed a difference between what brushes are called and how I use them.
For example tanda/acrylic_3_paint isn’t “acrylic_3_paint”, in my mind, it’s ‘gesture sketching’.

That situation makes it unduly hard to remember which brush I want, especially since there are a LOT of nice brushes – way more than I can load into the 9 quick access slots . However, I don’t want to go and change their name permanently, because that would make updates hard to figure out (I know this from experience :wink:

I have attempted to use groups to alleviate this, but it doesn’t really work. IMO this is because the name change should apply universally - If I say that I think of Kaerhon’s classic_sk brush as a brush for ‘mass/volume sketching’, then I want to see it described as mass/volume sketching -everywhere- (not just implicitly, by for example, being in the mass/volume group). It’s also partially because using groups to manage this would create a lot of micromanagement (30-50 groups, each with only a few brushes). Not a good fit.

This is a problem that other software, like Krita and GIMP, have attempted to solve via tagging + search. Putting aside the additional complexity of that solution, I think it suffers from the same problem as groups – the user doesn’t necessarily think in terms of ontologically neat groupings, rather, they are more likely to think in terms of a more vague ‘feel’ which is only captured by a specific individual phrase. Therefore its utility is unduly limited.

So I’m here to propose the idea, that perhaps we need to allow two names for a brush. One which is a ‘symbolic’ name – the actual filename, like it is currently. The other is a ‘screen’ or ‘user’ name, which the user sets in accordance with how they think of or use the brush.
These screen names would be stored in the mypaint config directory, not in the brush file, since the value of the information is entirely subjective.

2

Sounds interesting! Let’s say you use Tags less like groups and more like a name ( = only once) - wouldn’t that work? Because I like the tags idea. It sounds more flexible… However, I guess you want to display the “personal” name over the given name… And displaying Tags so prominently could look cluttered for people with multiple tags…

To copy a brush and rename it leads to the similar update issues like just renaming it, I suspect?

3

Thanks for responding.

Yes, I don’t care about the filename most of the time – I would want to look it up occasionally, but the point of this proposal is that seeing the filename is only useful for exploring new brushes. To me, showing the filename in the case of brushes you haven’t yet named personally, and otherwise showing the personal name, makes sense.

I think using single tags for personal names could definitely work, assuming we could display tags in place of filenames. I didn’t want to actually propose a tagging system, because they can be surprisingly complicated.

Actually you can copy a brush and rename it ok because of ‘parent brush’ tracking, that’s a good point. You would still need to do a bit of scripting to extract the ‘parent brush’ to handle updates, though.

Also, on most Unix-like systems, symlinks would be quite effective (FWIW if you don’t know, symlinks are files that just link to a ‘real file’. So they have their own name but point at an existing file). They would still need special handling if you want to make your own changes, though (make sure the ‘real’ brush file that the link points at is updated, rather than the symlink being overwritten with a separate normal file)

4

You can already rename your brushes and give them descriptions, private notes, and group them into categories you yourself define. I think this is too complex already, to be honest, but it’s what I inherited.

I want to move away from meaningful filenames entirely, and use uuids for new brushes, so that necessitates a separate name field. Which could be overridden. But that’s a thing for a future update and some careful rethinking about the entire way a user’s brush collection works. The code is in desparate need of refactoring down there :cry:

Symlink clutter in user config dirs. Ugh, no. It’s a management nightmare for the long term. Users should not have to manage their brushes folder in a file manager, full stop.

5

Well, descriptions and notes currently can only be seen in the brush settings editor, so they barely exist. Showing the description in addition to the brush name (in the tooltip you get when picking brushes) would make description a lot more practical for this kind of purpose IMO.

In case of groups, well, I think I said I already tried that. Maybe with a radically different UI, groups could be made to serve this purpose (but then they would probably have effectively become tags :wink:

Yeah, symlinks are kind of terrible most of the time. Definitely an ugly hack. Better than nothing, though.

6

The brush descriptions are in the tooltip for the brushes when the selector is in a side pane, but not in the B selector. Either way, to show names and descriptions in both, and when hovering with a stylus (not just mouse) would be a great improvement.

7

I’m using the side pane and don’t get the description in the tooltip. Maybe I need to save the brush first?

What you’re saying about mouse is a bit unclear. Is it that you only get the description with mouse, not with tablet?

8

Yes. Tablet: No tooltip, mouse: tooltip.

9

That’s probably because the pointer has to be perfectly still before the tooltip shows. Try hovering the pointer above the brush then lifting the pen away from your tablet’s active range.

10

That’s a good explanation, but the suggestion for a better UI still has merit.

11

Not my experience (I exclusively use tablet). I get a tooltip, but it just states the brush name eg. tanda/marker , no description.

EDIT: Oh, wait. I was looking at the wrong thing (the button in the bottom right corner). If I click the brushes icon and then a group (eg ‘Set #3’) then the tooltips in that dockable show descriptions. TIL that people use those individual-group dockables… (personally they don’t fit my usage at all, maybe if I had a more organized mind they would?)

12

So I’ll just stick some brush->description additions I’m making here. Hopefully they will be useful to others and maybe we can work out some loose description language for brush qualities?

  • tanda/marker-01: FLAT LINE / DIAGRAM. Soft Thin [Jitter Low, 0.4]
  • tanda/marker-05: MASS/GESTURE. Cloudy noise [pOpac soft, pSize soft, 1.2]
  • tanda/oil-01-clean: ROUGH SMUDGE. Oily elliptical hay [dAngle, pSize, noColor, 2.5]
  • tanda/oil-03-clean: SMOOTHISH SMUDGE. Oily elliptical wax [dAngle pSize noColor 2.9]
  • tanda/oil-03-paint: SMUDGEY PAINT. Oily elliptical [pSize soft, tSmudge soft, 2.3]
  • tanda/oil-06-paint: THICK PAINT. Oily [pSize soft, tSmudge soft, 0.8]

So what I’m doing here is ‘ROLE. 1-4 word modifier [0-3 items summarizing main variations in brush response]’

  • Brush response descriptors are intentionally vague : Jitter Low is more practically useful than Jitter 5%.
  • … With the specific exception of sizes, which are shown as px/10 (for example tanda/marker-01 lists 0.4, which means the typical dab is about 4 px radius)
  • If size is listed in ROLE, then the brush characteristic is fixed to that size and behaves differently when radius is changed. If it’s listed in brush-responses, then the brush quality remains the same when you change radius. In technical terms, different brushes differ in the invariance of their qualities to base radius.
13

I’ve submitted a super small PR to fix the tooltip issue so that the quick brush choice thing (B) has the description in the tooltip too.

14

Nice! I’ll test it soon.