User interaction from KImgIo

Michael Ritzert kde at ritzert.de
Mon May 30 12:18:39 BST 2005


On Mon, May 30, 2005 at 07:52:09AM +1000, Brad Hards wrote:
> On Mon, 30 May 2005 06:02 am, Michael Ritzert wrote:
> > Hi all,
> >
> > now that KDE 4 changes have started, I want to bring up and old thread
> > again: In http://lists.kde.org/?t=104220135500006&r=1&w=2 we discussed
> > how it could be possible to have KImgIO plugins interact with the user.
> > Everybody agreed that this would be nice to have, but the discussion how
> > to implement it given a fixed API in the pre-4 timeframe ended without a
> > conclusion.
> I guess there are two issues - what specific features do we need for the image 
> plugins, and do those features need a KimgIO class, or can they be done with 
> Qt4's QImageIOPlugin/QImageIOHandler?
> From what I've seen in Qt4, there may not be a lot more we need - there is now 
> support for multiple frames in an image, you can ask the ImageHandler to 
> provide a scaled image, a clipped image, a scaled&clipped image, save at a 
> specific image resolution and quality,  and save with big or little endian.

That's obviously better than what we currently have, but may not be enough in
the future. JPEG 2000 for example has the ability to define "regions of
interest" that are handled differently. I doubt that a generic class will be
able to provide these settings.

> > The implementation could be as simple as adding a QWidget* to be used as
> > the parent for dialogs and a bool to request action without user
> > interaction to the KImgIO interface.
> Michael - have you tried porting the JP2 plugin to Qt4? My experience with the 
> EXR plugin shows that there are a few things that I'd like to have added, but 
> they are probably too specific to EXR.

See above. I don't have plans to implement a GUI for these settings ATM. Still,
we should try to come up with a solution that can be extended to offer these
settings. After all Qt4/KDE4 will be around for quite a while.
(Disclaimer: I haven't looked in detail at Qt4's implementation!)

> If there are other things that are needed, we might be able to get the trolls 
> to add it. Its getting kinda late, but they can probably add in sooner or 
> later.

It was proposed once before to use Qt's image I/O functionality. See
http://lists.kde.org/?t=106544576600004&r=1&w=2
To quote Dirk Mueller:
> Qt plugins are worse than Kimgio plugins, because Qt loads all plugins it 
> finds as soon as ANY plugin is needed. This is not the case with Kimgio. 

Has this changed for Qt4?

Michael





More information about the kde-core-devel mailing list