[Kde-imaging] Some questions...

[Renchi Raju]

On Fri, 18 Jun 2004, Jesper K. Pedersen wrote:

> On Friday 18 June 2004 14:45, Craig Drummond wrote:
> | 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?

no. go ahead.

> | 2. Some of the plugins still reference "directories",
> | whereas KDE uses the term "folder". Can I change these
> | as well?

sure.

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

sure.

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

we will have to discuss that. Aurelien, add this to the TODO list. does it
make sense to have app specific plugin configuration or should we use a
global config.(Note:i'm in favor of a global config)

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

if you want raw jpeg data, you will have to read the file itself. QImage
does not give you raw jpeg data, it gives you the decoded image. you will
have to implement the file open/save functions yourself in the plugin.

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

another plugin to put on the digikam ignore list :). but seriously, this
would be an useful plugin for other apps. also provide an option to
download the files with original names if requested by user.

regards,
renchi