[Kde-imaging] Some questions...

Jesper K. Pedersen blackie at blackie.dk
Fri Jun 18 15:02:51 CEST 2004


I'm very busy today, and I expect my girlfriend home in 4 hours (and she just 
got herself a job today, so I need a bit of planning)
So I will only answer a few of your questions now.

On Friday 18 June 2004 14:45, Craig Drummond wrote:
| Hi,
|
| I've just compiled kipi, and have a few questions:
|
| 1. Most (all?) kipi-plugins seem to create dialogs
| without specifying a parent. This causes the dialog to
| produce an entry in the taskbar - and, IMHO, doesn't
| look very professional. Would there be any objections
| if I went round and changed these to have parents?
|
| 2. Some of the plugins still reference "directories",
| whereas KDE uses the term "folder". Can I change these
| as well?
|
| 3. The jpeglossless plugin allows a user to convert an
| image to grayscale - and there is no way to undo! The
| attatched patch just adds a warning dialog before the
| operation. As the parent of this message box, I'm
| using "kapp->activeWindow()" - would this be OK for
| the parentless dialogs mentioned in 1 above?
|
| 4. Some plugins still have references to digikam - I
| assume these will be removed soon. However, some use
| the digikamrc file - is it intended that plugins each
| have their own config file, or will the usage of
| digikamrc be replaced with a kipirc?
|
| 5. I've noticed in Gwenview that when an image is
| altered via kipi, that the display is not updated. Is
| this a Gwenview error? Does kipi have a way of
| informing the host-app that an image has been changed?
KIPI::Interface::refreshImages() is the way the plugin informs the host app 
about a change.
|
| 6. I've created a small app for the removal of
| hot-pixels. This is a fairly simple wrapper around the
| jpegpixi program. I'd like to convert this to be a
| kipi-plugin. jpegpixi works on the raw-jpeg data, and
| avoids re-compressing the image when saving. Will kipi
| allow access to the raw image data? Or would my plugin
| have to re-read the file? If the plugin has to re-read
| the file, is there any point to having this as a
| plugin? What I'd really like is to be able to modify
| the raw data, inform the host-app of this (so the
| image can be updated), then the user can view the
| results before saving. So ideally I'd like the
| host-app to pass my plugin the raw data, and a QImage
| (so that I can check for the existance of hot-pixels
| on the real image).
We discussed this some time ago, but never got to a conclusion I think. 
Aurelien do you remember.
I think it stranded on digikam not using QImage.

| 7. I'm also writing a simple plugin to acquire images
| from a camera (either via KDE's camera:/ ioslave, or
| by mounting the device), and re-naming (based upon
| exif data) the images before saving to the target
| folder - i.e. all my photos are named "YYYY-MM-DD
| hh:mm:ss.jpg". Does this sound useful to anyone other
| than myself?
Indeed! I would love to see such a plugin for kimdaba.

Cheers
Jesper


More information about the Kde-imaging mailing list