brushes and brush engines

[Cyrille Berger]

On Tuesday 18 March 2008, Boudewijn Rempt wrote:
> On Tuesday 18 March 2008, Cyrille Berger wrote:
> > Well I vote for KisBrushStamp, KisBrushEngine and KisBrushSettings.
>
> I'd prefer KisTip myself -- to minimize the relation between the brush
> engines and the ex-KisBrush type of resource.

It might just be me, but if I read "Tip" I think more of the "daily tip" 
dialog that show at start of KDE applications that at what we are talking 
about. When choosing the final name, keep in mind " I'm getting tired of 
having to explain the different between KisBrush and KisPaintop." could 
become "I'm getting tired of having to explain what KisTip is" ;)

> KisBrushSettings might better be called KisBrushState since it contains
> more than settings, but also state kept during painting -- like active
> node, pointer event etc.
>
> I hadn't realized that doing this would also entail creating a whole new
> resource type, KisBrushEnginePreset (or, until the renaming is carried
> through, KisPaintOpPreset): that would be a serializible configuration
> containing a paintop id, the xml from KisPaintOpSettings and the xml from
> KisBrush -- if any.

Currently KisBrush's xml contains the name of the ressource, when it is is 
KisBrushImage, and the parameter of auto brush when a KisAutoBrush. Which 
reminds me of an other usuage of the auto brush, when unserializing a 
KisBrush in the action recorder, but using factories or something like that 
should solve that issue.

> > > * We want to have only one collection of brush tips shared by all
> > >   brush engines that use brush tips. Besides, the autobrush brush tip
> > > is used outside the brush engines, too.
> >
> > The only place it's use (outside autobrush) is for creating kernel for
> > convolution. And afaik, for this, it would be better to use something
> > else (like extending kernel to create those kernel), even if the math is
> > very similar (until now I was lazingly using the autobrush function, but
> > I am ready to make the needed changes to avoid that use).
>
> That should make life quite bit easier, especially because this way it
> becomes easier to make the various types of brushes, tips, stamps actual
> plugins.
>
> > > * We'll look more like Photoshop than like Corel Painter after this
> > > change.
> >
> > Is this a bad thing ?
> >
> :-P
> :
> > > Implementation:
> > >
> > > I'll have to make some changes in the canvas resource provider,
> > > the control box and add gui classes to implement the preset
> > > designer/manager. I've got already some code for that.
> >
> > I agree with Casper, it sounds ok. But it also sounds like a huge
> > undertaking, can it wait until after 2.0 ?
>
> It is quite a bit of work, but I'd really like to have it in place before
> the summer of code starts because it brings a lot of sense to our paintop
> interface. I would like to spend tonight and Thursday night on this and see
> how far along I manage to come: then I can decide how much more work it is
> than I'd thought it would be. (Western Easter weekend I intend to dedicate
> to the text shape.)
>
> > It's recreating a color transformation for each stroke, that would be the
> > explanation, but that shouldn't be that slow to look like a "hang".
>
> It's pretty bad, really. I'm fairly sure that this is the actual problem,
> though.



-- 
Cyrille Berger