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

[BERGER Cyrille]

> 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. 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).

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.

> > 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
the filter you have three undo actions in the history.

> 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.

--
Cyrille Berger