API Evolution question about paintop, colorspace independent filter (or even tools for that matter) and filter transaction

[Boudewijn Rempt]

On Fri, 28 Apr 2006, BERGER Cyrille wrote:

> > 2) ...
> > Another possibility is making those filters only available when the mode
> > is LAB16 -- users can convert to lab and back themselves. That would
> > be a good possibility for specific filters. And, in fact, some
> > things can only be done in lab like sharpening just the L channel. (I was
> > working on extending the filter configuration with a channel selector
> > so that filtering on just one channel would become easy.)

> Bah we display a message when the filter convert the data to LAB and
> that it risk degrading the data.

In many cases that works fine. But: if the user wants to apply a couple
of those filters after each other, it is better if the conversion to
lab and back is done only once instead of for every filter.

> I think it's better (for the user
> experience) to have as few as possible disabled filter. Because, for
> instance, I have a filter that requires LMS, so with such a system it
> will be disabled except if CS==LMS, meaning that the user has to
> figure out which colorspace to use for a specific filter (through doc
> or a tool tip ? not very very userfriendly).

If I listen to Larry Marso then users don't have a lot of trouble with
learning they need to go to LAB for some cool effect. And for many
nice filters you need to show the channels.

But I agree that we need to augment our colorspaces with to/from lab, unless
Casper has an even better idea. (But Casper has been very silent recently --
has the transform code finally conquered him?)

> As for the channel selector, it's great, but shouldn't it be lower
> level ? (I don't know how, maybe we should seperate channels in
> different tiles ?, but that's lot of work, maybe not really worth it)
> It would be cool to be able to lock a channel.

No, we should keep the channels together, or so Pippin advised us :-). What
I'm thinking is to add a QList of bools as an argument to many of 
the colorspace methods, to bitBlt and to the process() method of the filter.
For now, I'm working on a widget to select channels, but that's a bit hard 
since not all colorspaces have a color associated with all channels, meaning
I need to work with abbreviations and so on. But a prototype implementation
should appear as soon as I've got some time to myself.

> 
> > > 3) In Filter manager, we create a KisTransaction, but in fact we would
> > > need to start a macro there, and the question is how do I cancel a
> > > macro ? (when the filter is interrupted)
> >
> > Why the need for a macro? Are you planning to allow people to select
> > a sequence of filters to apply at once?
> yeah, scripts/kross_macros do that (I need to check how I dit it, but
> I think use an undoMacro for that). But that's not the problem I
> discovered. If you use KisPaintDevice::changeColorspaceTo, then the
> function add his own transaction to the undo adapter, so at the end of

Okay, I see the problem now. I didn't think of it, because the operations
that need lab or something are so implemented that the colorspace converts
the bytes to lab and then do the operation. But if we need to show, for instance,
lab channels in the filter config widget that won't work.

> > Actually, to cancel a macro,
> > I think you need to unexecute all commands in the macro, backwards.
> > Doesn't the macro class already offer that functionality?
> Maybe, but the macro isn't accessible, it's hidden in KisDoc, maybe
> adding a function in KisUndoAdapter to either return the macro or
> cancel it would solve it.

Ah, I see. Well, this should be easily solvable. Put it on the 1.6 todo
list for me.

Boudewijn