Two Krita technical questions
pentalis at gmail.com
Tue Jun 22 17:22:28 CEST 2010
On Tue, Jun 22, 2010 at 9:39 AM, Boudewijn Rempt <boud at valdyas.org> wrote:
> On Tue, 22 Jun 2010, JL VT wrote:
>> First of all sorry if the questions had obvious answers, they're not
>> so obvious to me!.
>> Question(s) one, for the Scratch Off algorithm:
>> I have a paintop, and want to store image data in a place where: 1.-
>> it is invisible to the user 2.- survives the destruction and
>> reinvocation of the paintop.
>> std::clog tells me that paintops are created when the user presses
>> down the mouse button, and destroyed when he releases it. That leads
>> me to think that anything I create inside the paintop won't survive
>> till the next creation-destruction cycle, but maybe I'm missing
> Krita was designed to make strokes independent of each other, so that's hard.
> I'm not sure what you mean by image data, do you mean the temporary layer
> in wash mode?
> The only place where you can store data for the paintop is in the preset
> settings object. There's no guarantee that the user won't select another
> preset before he paints the next stroke, though. You _could_ (conceivably)
> put your data in a static object local to the paintop. That's quite
> hackish, though. Another option might be to create some data class and add
> that to the KisCanvasResourceProvider, then it would be analogous to the
> current background or foreground color.
>> I want to know: how can I achieve (1) and (2)?. If there's a place in
>> the code where someone does something similar, just point me to that
>> file, I can learn from it. Or tell me what classes to use or roughly
>> what's the principle of what to do with them (i.e.: if you use this,
>> it will survive the paintop destruction, just be sure to erase it when
>> you stop using it or it will leak memory).
>> If there's more than one way to do it(tm), please point me to the most
>> "orthodox" or most "desirable" way to do it. I already refactored my
>> code and prefer to keep it clean and shiny.
> Depending on what you mean by image data, there might actually be no nice way
> of doing this right now...
With image data I mean a bitmap. Though it seems there's no clean way
to do this. Which is good to know!, I'll think of a sinister plan to
come around this.
More information about the kimageshop