[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-imaging
Subject:    Fwd: Re: [Kde-imaging] Manipulating image data from within a KIPI
From:       blackie () kde ! org (Jesper K !  Pedersen)
Date:       2004-05-20 13:10:30
Message-ID: 200405201309.59580.blackie () kde ! org
[Download RAW message or body]

On Sunday 16 May 2004 19:30, Aurelien Gateau wrote:
| > | I think you misunderstood me. I was thinking about plugins similar to
| > | GIMP filters: plugins which would alter the image data loaded by an
| > | host app. The host app would load the image in a QImage and let the
| > | plugin access it through the Interface::image() method. Whenever the
| > | plugin modifies the image, it calls Interface::setImageDirty() so that
| > | the host app can refresh its display. This will let you implement
| > | sharpen, blur or other nifty image fx as plugins.
| >
| > Ahhh now I understand you, but this requires a complete new set of
| > plugins doesn't it. And will adding an image() method be enough? I mean
| > that kind of plugins reacts to the user doing actions with the mouse on
| > an image, doesn't it? So we would need a way to allow mouse events in a
| > viewer of the image to get to the plugin, or do I still misunderstand
| > you?
|
| You're getting closer :-).
| If you look at the GIMP filters, they work with a dialog which displays a
| preview of the effect. So I think the image() method will be enough, maybe
| we can add a selection() method which would return a QRegion if we want to
| do more advanced stuff. I don't think we need mouse events.

OK, I think I'm almost there now ;-)
I could as easy as scratching my back return a QImage from say KimDaBa, but 
where should this image be displayed? Would a call to this QImage method 
indicate to the host application that it should display the image in a 
viewer?

Cheers
Jesper

PS: I work on KIPI today, so if you have time, please join me on #kimdaba at 
irc.kde.org
[prev in list] [next in list] [prev in thread] [next in thread]