Yet Another Brush Proposal

[Matthew Woehlke]

Valerie wrote:
>> I'd go with PS's model... a "revert to default" seems complicated (where
>> the heck do you store the defaults? In the source code?!), but a 
>> load/save system is just good UI. If you screw up, load the "default 
>> gradients" preset. If you fsck that too, well then... ;-)
> 
> I don't get it. XD (then again, I don't use Photoshop)
> 
>> (This being open source, you would of course just re-install them.
> 
> Re-installing, I Do get. :-)

Re-installing is only needed if you do something to the stock brush set. 
Since this belongs to the package it has the same permissions as the 
executable/libraries, which is, not necessarily user-writable.

>> if you used a package you probably cannot write to those anyway,
>> so...)
> 
> Um... are you referring to the need of having special permissions
> to modify packages in the source? (basically, it's what forces me to
> use sudo every time I want to delete those extra Gimp round brushes?)

NoooooO! Ok, let me try to explain. In PS, *all brushes* are stored in 
the user data area, which is how I would do things in Krita. So... try 
to load the user brushes. If the file does not exist, instead load a 
well-known set of brushes from the install directory. As soon as changes 
are made, save everything to the user data area; the stock brushes are 
never (automatically) read again. (Hopefully we don't need to worry 
about adding brushes that are new in the package; I'm not sure that 
would be desirable anyway. A notice that the package brushes have 
changed might be ok, though.)

Now... you can also export all or some of your brushes to separate 
collections, import collections... or replace your current brushes with 
a collection. So the way you "revert" is to replace your current brushes 
with the stock collection. (Technically, you could also nuke your 
preferences directory and then the stock brushes would be auto-loaded on 
next startup.)

No brushes are ever defined in the actual codebase.

Or, in files:

/usr/share/apps/krita/brushes/default.kbc // the "stock"/default set
/usr/share/apps/krita/brushes/calligraphy.kbc // a sample collection
~/.kde/share/apps/krita/brushes/current.kbc // what you actually have
~/MyKritaStuff/My_Circles.kbc // a user saved collection

>> Pigment opacity should be downplayed, if we even need it (maybe dumped 
>> somewhere obscure in the color picker). Think of pigment opacity as 
>> something that is *combined* with rate, pressure, etc, i.e. things where
>> the brush would deposit less pigment. Basically, it only exists so that 
>> you can get mostly-translucent painting even when pressing really hard
>> :-).
>>
>> That said, I think I disagree with not having options separate, or at 
>> least separable. Actually, putting them next to each other is a good 
>> idea (if it's feasible), but I haven't put a whole lot of thought into 
>> actual interface layout. But in my mind, what pigment I put on the 
>> canvas, the instrument I use to put it there, and the way I wave around 
>> that instrument should all be separate and interchangeable.
> 
> Ah-hah! I get it now. You and I may just be after completely different
> paint interface concepts:
> - I'm thinking more of a CG-approach, as this is what I'm used to
> (and what most digital programs use) 
> - you may just be going for a more "realistic" paint interface approach

Yes, something like that. I'm aiming for my tool selection to work like 
real life. "I want, hmm, the #5 camelhair round brush, with some 
watercolor paint, 75% water, and <some color>. And I'll paint with the 
bezier tool." All the "CG knobs" should be available, but hidden behind 
good presets (even better if they can be hidden behind "simple" 
adjustments, but that's harder). Sort of like Painter; you can configure 
things up the wazoo, but in practice you'll end up with a few presets 
you like and rarely fiddle with them.

> With CG you have somewhat more technical terms floating around such 
> as opacity and whatnot that you'd usually not have with natural
> media (pencil or paint with 42.3% opacity? Right). And to chose
> color you have all these fancy sliders whereas in real life you make
> due with squeezing tubes (RGB 122,154,001 what?).
> 
> These concepts are Handy, but don't exist in real life. 
> 
> I think both approaches are needed. They'll just end up in different
> workspaces depending on what people are comfortable with.
>
> Basically, what needs to be coded first is a more advanced version
> of the color mixer: you'd instead have a real Paint mixer. In this
> paint mixer, you first chose the type of paint you want, then you
> add other basic colors to modify the one in the mixed, and you add
> water and such to change the so-called opacity implicitly. To add
> color to your brush, you dab into the mixer, and the different
> bristles may even take on different colors.
> 
> Is this what you had in mind? :-)

Um... yes and no. I'd like a paint mixer also, but the initial goal is 
just to say "pigment type, pigment color, pigment opacity, wetness" 
(note that opacity and wetness aren't quite the same; wetness really is 
part of pigment type, as it affects things like bleed, bidi, and not 
just how "solid" the color is). That said, one or more of those 
parameters can probably be hidden in the normal use case. To get pure 
colors though, you'd still have the normal color pickers.

IOW, I'm not thinking so much about the mixer as I am thinking about how 
to define the jars of "pure paint" you have available. But that's only 
part of what I'm thinking about.

> (the CG approach should also be available to those who are more
> comfortable with it though, technical terms and everything. After all,
> some of us actually find those Easier to work with, since people like
> I actually have no idea what you're supposed to do with natural media.
> :P )

Oh, absolutely. I'm looking at how the interface could be best 
decluttered, and I guess debating to an extent where I think the various 
settings should live. But I never suggested the knobs shouldn't be 
*available* :-).

>> Speaking of easter eggs, did you know some version (95?) of MS Excel hid
>> a 3d terrain simulation?
> 
> Whoa, it did? Without getting into lawsuits?

I never heard about lawsuits, and I've seen the egg myself :-).

-- 
Matthew
I think I want my tombstone to read:
<name>
Process created <date of birth>
Signal 15 received <date of death>